When starting a new project, decision makers are faced with the dilemma of choosing a content management system (CMS). Sometimes, it’s not that simple and they must choose whether to go with a traditional CMS or a headless CMS. Both offer unique benefits and cater to different needs, making it crucial to understand when each makes sense for your project. Let’s take a look at some considerations that can help you make the right decision.

What is a Traditional CMS?

Traditional CMS’s – like Craft CMS, WordPress, and Drupal – offer a pre-packaged solution for content creation, management, and delivery. They include powerful interfaces with content editing capabilities and templating out of the box, enabling you to create sites with ease. A traditional CMS can be monolithic because the back-end and front-end are tightly coupled. Using a traditional CMS typically means you are using all of the tools included to achieve your goal.

What is a Headless CMS?

A Headless CMS is like a Traditional CMS in that it includes content creation and management tools. But it differs in the fact that the back-end content management system is decoupled from the front-end (presentation layer), allowing developers to use any technology stack they prefer for building the front-end of the site. The back-end acts as an API with its only purpose being to serve content from the database. There are CMS options like Contentful, Payload, and Strapi that are built to be headless. Popular traditional CMS’s like Craft CMS and WordPress also offer headless variants.

The Restaurant Analogy

Let’s simplify things a bit more and look at the decision using an analogy; a restaurant.

Traditional Restaurant (Traditional CMS)

Imagine a restaurant where the kitchen and dining room are connected. The chefs cook the food, and the waitstaff serve it directly to the customers in the same building. This setup means that everything is closely integrated, and the kitchen (back-end) is tightly coupled to the dining experience (front-end). Picture a scenario where the restaurant decides to change from table service to buffet style. The food now needs to be prepared in advance and delivered to the front of house in a different way, potentially even requiring new equipment. The restaurant needs to be reconfigured to not only accommodate the buffet but also to interface with the kitchen differently. Because the restaurant and kitchen are coupled, both sides would require work in order to accommodate a shift in strategy. 

Ghost Kitchen (Headless CMS)

Now, think of a ghost (or cloud) kitchen where food is prepared centrally but can be delivered to various locations or dining experiences. The kitchen (back-end) focuses solely on cooking (content creation and management) and doesn't worry about where the food is served. Instead, the meals (content) can be delivered to different endpoints like food trucks, home deliveries, or partner restaurants (or in our case websites, mobile apps, etc.). This separation allows more flexibility in how and where the content is delivered without changing the core cooking process. If a new experience requires new equipment or processes, the kitchen can be expanded without affecting the front-end experience.

When to Use a Headless CMS

Omni-Channel Content Delivery 

If you consistently need to deliver content across multiple platforms (websites, mobile apps, IoT devices), a headless CMS is ideal because it can serve the same content through APIs to any front-end. The front-end can be swapped out without any need for development to the back-end.

Scalability and Flexibility

If you want the ability to keep your content management system up-to-date independently of the presentation layer, a headless CMS can allow for more agile and scalable development. This could be especially useful if you anticipate needing to redesign or update parts of the front-end frequently without affecting the back-end content.

Front-end Framework Preferences

Maybe your team has developers who are very proficient in a particular JavaScript framework, like Next.js, SvelteKit, or Astro. The time needed to learn a new templating language could push you past your deadline. Maybe you have some cool interactive interface in mind? A headless CMS can provide the raw content for your developers to build highly custom, tailor-made front-ends in whatever language or framework they please.

Security

Going headless can offer security advantages due to its decoupled nature. By communicating via API to the front-end, data access can be controlled more granularly. Because the back-end is only responsible for content management and delivery, fewer plugins are typically used which means a smaller chance of vulnerabilities due to third-party software.

Hosting & Infrastructure

A cloud-based headless CMS offers additional advantages over a self-hosted headless CMS. It can simplify maintenance and operating costs since the cloud provider is responsible for updates and security of the platform. Cloud-based solutions like Strapi Cloud often come with integrated security features, automatic backups, and disaster recovery options.

Which will you choose?

While the flexibility and security a headless CMS offers may be great benefits, it may not be necessary for every project and could even introduce complexity. It’s important to consider the long-term purpose of the project and who will be responsible for maintaining it as well as authoring content. If your primary focus is on managing and delivering content in a structured manner with rapid development, a traditional CMS can be an excellent choice. But if you feel any of the examples I’ve laid out above align with your project’s requirements then a headless CMS may be right for you! 

Whatever route you take, remember that both Craft CMS and WordPress can be used in traditional or headless applications and are a fine choice either way! Now you know the differences between a traditional and headless CMS, and an informed decision can be made. If you have more questions or a project you think could benefit from a traditional or headless CMS, we’d love to help!

If you’re like us, you’ve likely built ‘page builder’ fields in Craft CMS using Matrix. But sometimes you need more than a block. We use Super Table to create ‘page sections’ that include some extra settings (like background color, controls for width, etc.). We can then nest a Matrix field to control page blocks within the Page Section (Super Table). This has worked well for us in the past but there's a new, simpler way to achieve this starting in Craft 5.

Upgrading a site from Craft 4 to Craft 5 can seem intimidating. Even more so when your site relies on complex content models like the one I described above. You might think, okay I'll upgrade to Craft 5 and then look into migrating to the newer method in the future. Well, now is the time. Verbb has announced that Super Table has reached end-of-life.  While there is a Craft 5 compatible version available, it won't receive updates. That means now is the perfect time to migrate your Super Table fields to native Matrix fields.

Craft 5 makes the process easy by converting Matrix blocks to entry types automatically during the upgrade. This guide will walk you through the process. We'll cover preparation, the upgrades themselves, and steps to clean up afterward. As you’ll see below, the process is actually quite simple and nothing to stress over!

Preparing for the Upgrade

The first step in any upgrade is preparation. Start by backing up your site’s database. This ensures that you can restore your site to its previous state if anything goes wrong during the upgrade process. We use (and love) DDEV here at Viget, so this guide will be leveraging it. But you can easily adapt the commands if you are not. To create a database backup, run:

It's also essential to familiarize yourself with the Craft 5 Upgrade Guide. This guide provides detailed information on the changes, new features, and potential breaking changes in Craft 5, helping you understand what to expect. It serves as a fantastic set of instructions to get your site upgraded.

The Upgrade Process

Once you're prepared, you can begin the upgrade process. Per the Craft Upgrade Guide, we will update Craft and plugins at the same time. Open your editor and modify your composer.json with the new versions of your plugins. The two for sure we will need to modify are:

Updating Super Table Fields and Templates

With the Matrix blocks converted to entry types, you need to reconfigure any Super Table fields to be Matrix fields.

Update Super Table Fields:

• Browse to Settings > Fields and edit any Super Table fields
• Change the field type from Super Table to Matrix (there will be no content loss when switching from Super Table to Matrix)
• Select the entry type to use (Craft has already created one for you)
• Save the field
• That's it!

At this point, you have removed your dependency on Super Table and have a page builder entirely built with Matrix fields. What were previously Super Table blocks are now a custom Entry Type and what were Matrix blocks are now also Entry Types. This allows you to have nested Matrix within Matrix thanks to Craft’s Entrification plan.

Cleaning Up After the Upgrade

After updating your fields and templates, it's time to clean up. First, uninstall the Super Table plugin. Navigate to Settings > Plugins in the Control Panel to uninstall the plugin. Then remove it from your project by running:

Thoroughly test your site to ensure everything is functioning correctly. Pay close attention to the entry types where you used Super Table fields, confirming that authoring and your front-end work as expected.

Additionally, you can also take this opportunity to clean up your fields and entry types. Craft 5’s reusable fields and entry types give you ample opportunity to consolidate and Craft 5 provides new utilities to make this process as simple as possible.

• fields/auto-merge — Automatically discovers functionally identical fields and merges their uses together.
• fields/merge — Manually merge one field into another of the same type and update uses of the merged field.
• entry-types/merge — Merge one entry type into another and update uses of the merged entry type.

That’s it!

Upgrading from Craft 4 to Craft 5 and transitioning from Super Table is incredibly simple, thanks to Craft 5’s automatic conversion of Matrix blocks to entry types. Super Table will no longer be maintained moving forward, and it's better to switch to the native Craft solution for better long-term support. By following these steps, you can quickly tackle the change and take advantage of the new features and improvements in Craft 5. With careful planning, thorough testing, and a few commands, you’ll have your page builder working again in Craft 5 in no time. Happy upgrading!