Throughout the years, I have spent a lot of time conversing with CTOs, CIOs, CMOs, and Directors, helping them understand their choices when implementing their next major web initiative or rebranding. They often come to the table with questions on how to best build their website in an efficient and cost-effective way, maximizing their ROI.

The question of which platform, technology stack, or type of CMS to work with is usually the top question that I get asked. It is never an easy one to answer. I’d argue that in 2021, the decision on which platform to stay in or move to for that next digital project is harder than ever to decide. There are many valid options. Do you go with the traditional CMS that the organization has been in for years (and maybe struggling with)? Do you go with a new CMS (the grass is always greener, right)? Or is it time for something truly different, like a headless approach? The idea of Content-as-a-Service powered by a headless CMS is becoming more and more popular, especially in enterprise-sized organizations.

This is usually how the conversation starts:

“We are not sure if a headless CMS is the right fit for us versus a traditional CMS, how do we decide?” – CMO

This question is very common. I thought I would share my thoughts on this situation and how I help my clients choose between traditional CMS and headless CMS. This is basically the methodology I use for pitching headless CMS to my clients, which I thought could be equally helpful for others pitching, or those being pitched to!

Helping to Choose between Traditional CMS vs. Headless CMS

Below I am going to detail out the methodology that I use when entering a CMS selection process. While it is not exactly rocket science, I do believe it is essential to cover these primary steps.

1. Listen to the Client First

It would be an easy way out to go into a conversation with a favorite CMS solution in mind. I would try not to have a preconceived notion of what is best for the client before listening to them firsthand. Even if you have received a Request for Proposal (RFP) stating one specific solution is the best fit, I still would prefer to have the client give the background/context of why they feel that way. Let them explain their needs and describe the new project as detailed as they can.

It’s important to hear that need in the client’s own voice. You can pick up gems of information that an introduction email or RFP might not have included. For example, I was recently in a CMS selection process with a large enterprise organization, and I heard this:

“I want my team out of the business of maintaining and upgrading a CMS platform. I need them adding value to the application and ultimately the organization itself.” – CTO

That’s a pretty important talking point that wasn’t in the initial introduction email. That comment shows that this scenario should take immediate consideration into reducing the amount of time, resources, and cost around running and maintaining infrastructure and servers that a traditional CMS might require. Hearing this statement was a “tip.” I now saw one reason to adopt a SaaS-based solution (hello, headless CMS).

Listening to the whole story, noting the details, and adding those details to the RFP or original request can be quite helpful.

2. Get a Lay of the Land

If the project involves a migration from a legacy version of the application or platform, you have a chance to review what is working and what isn’t. I always try to get some sort of walkthrough of the existing application to compare what the application currently does versus how the new world needs to function for that application.

In fact, one of my clients called me out a few weeks back on loving the terms “old world” and “new world” and how I use them in pre-sales or discovery conversations. It made me smile, because she was totally correct; I do use those terms often.

Saying “old world” helps frame the conversation when reviewing a content model, screen layout, or third-party integration requirement. It also starts setting up how things could be different in a “new world.” Getting the lay of the land can help you catalog what features are most important. It can also identify reverse — what features are just “nice to have.” While learning the lay of the land, I’m also looking for pain points that editors have with publishing content or that developers have with making certain functionality work correctly.

Knowing that a project needs say, real-time information from a PIM or DAM as a priority requirement may allow you to scope out if the CMS media/asset library is robust enough to cover that need. Or, perhaps the client may require the site to have content available in different global regions and fully translatable into three or four cultures. This might clue you into looking for a CMS that has ways to group content and a default language fallback that makes it easy to manage such content.

Walking in the client’s shoes for even just an hour is hugely insightful.

3. Describe the Benefits of Both Options

Once you’ve listened and gotten up to speed on the project, it becomes time to map the client needs to what the CMS platforms can do best. It’s easy to start by mapping the top benefits to the client’s direct largest needs because this is basically the low-hanging fruit.

For instance, if the project is to build a B2B commerce site, then a traditional CMS is typically going to have some advantages. Things like user/customer management, eCommerce abilities (checkout, shopping cart, payment gateways), and email marketing (abandoned shopping cart processes) could all be “in the box.” It could be nice to have one CMS that does all those things well. Even smaller features, like a built-in search engine for the site, are included in about 99% of traditional CMS platforms. There are many good points to bring up about traditional CMS and the value that type of CMS can bring.

However, with headless, the benefits are not just about the features of the CMS. The benefits also extend to how you can now deal with the entire project as a whole. It is very freeing not to have to worry about maintenance and infrastructure over time. For instance, another contact I was talking to in a conversation like this mentioned:

“How can we do more with less. I really don’t want to run another CMS upgrade ever again.” – Application Development Manager

If a headless CMS vendor handles the service availability for you, there is a world where CMS upgrades are a thing of the past. Your team just doesn’t have that responsibility any longer.

I also educate my clients on how the project schedule and project phases can be sped up. Content modeling can occur right away instead of waiting for the traditional CMS to be provisioned, installed, and configured. Content can be created and collaborated on from day one. It’s just a bit different.

Then there are the technical benefits around the freedom of developing a site or application in any technology that the dev team wants. You are not tied to any one single technology stack. As long as your project can consume an API, you can deliver on any channel you need (web, mobile, smartwatch, ad, display board, etc.)

My goal is to match as much low-hanging fruit as possible to see if there is a natural edge to one style versus the other.

4. Provide a Comparison Matrix (Headless vs. Traditional)

After the low-hanging fruit is out of the way (which is the easy part), it’s time to dive into the next comparison level. I am a big fan of Pro vs. Con matrixes when it comes to comparing software platforms. I like to summarize the biggest Pros and Cons for each side of a comparison and then dive into the details and document those details (instead of just talking about them in theory).

In fact, I couldn’t resist. Below is a template that can be used to compare different CMS platforms. I have stubbed out the example comparison to look at Kentico Xperience on the traditional CMS side and Kentico Kontent on the headless CMS side. This isn’t just another CMS comparison matrix checking boxes for this feature or that feature. It is intended to compare the “types” of CMSs and different approaches — an all-in-one monolithic traditional CMS platform versus a microservices and Content-as-a-Service.

The comparison itself is broken up into three main sections. The first is a summary of annual cost (trying to get to the estimated total cost of ownership). The second section is a top-level summary of overall strengths and weaknesses of traditional and headless CMS platforms. Finally, the spreadsheet ends with a deep dive into a feature-by-feature comparison broken up into the categories of:

• Content related features
• Technical related features
• Infrastructure related features
• Security related features
• Digital Marketing related features
• eCommerce related features
• Your Project Specific related features

It adds a comparison of over 60 different features and notes which platform has a strong case for that feature. Also, to be clear, the last section of your project-specific related features should always be considered and added to the list if you want to make it a fair comparison.

I would encourage you to modify the tool to represent your scenario as well. For instance, if you are using microservice architecture and have a service that handles your PIM needs or your email marketing needs, then delete that section out of the comparison as it shouldn’t count. If you find something that is missing, add it.

5. Be Clear on What Could Go Wrong with Headless CMS

It’s not all perfect, and no solution is for every scenario. The API-first approach makes developers happy but is typically challenging for the marketing/business side of the project team.

Some marketing teams still expect and desire to use a WYSIWYG text editor with an immediate preview capability. Even though many of us wish that WYSIWYG could be killed off forever, I still hear this:

“Why doesn’t my embed HTML work and I’m still having issues with this thing right here in the CMS and how it goes to that thing [on the design]?” – Marketing Director

If you are not used to structured content, then let’s not sugarcoat it. There is a learning curve. The WYSIWYG text conversation is best approached by showing the value of a content model and what structured content can allow you to do, which is to write and manage content in one spot, and use it everywhere on your site.

The preview point does have a very valid argument. To enable a preview ability, you need a developer to tie the headless CMS to a presentation layer or “head.” It is fair to say that there is a high dependency on having a development team in headless. Most times, you need them for every step of the way. In contrast, most marketing teams are very savvy in a traditional CMS and can produce quality work without the need for a development team.

Then there is the next challenge — integration. The “wait there’s no out-of-the-box integration for XYZ third-party platform or tool?” question inevitability comes up. Yes, this is said often in a headless project solutioning session. Third-party integrations are again up to you to provide in a headless world. A quality headless CMS will have source plugins for static site generators like GatsbyJS, or Statiq in the .NET world, making this somewhat easier. But chances are you will be rolling your own integrations and migration tools, which will impact the implementation fee of a project. You may find yourself often reminding the client or dev team that “…remember, there is no A/B testing module, you will need another tool for that”.

Basically, to provide a fair comparison, you should alert the client to both sides of the story.

6. Paint a Vision of the Future

Once there is a clear understanding of the project needs, a comparison has been created, and the winner is starting to become clear, I like to paint the picture of what the future will look like. To do this, I create a diagram of the solution and review it with the client to make sure they understand the big puzzle pieces of the system and how they will ultimately fit together.

The diagram above helps show the connections between systems, where integration points are, and where failure points could be. It even typically goes into which resources have which costs associated with them. It can also be useful to contrast the “old world” with this “new world” and allow everyone on the team to critique the new plan if needed visually. This is a good way to make sure nothing was forgotten in the new solution. Typically I use free tools like diagrams.net, or lucidchart.com to do the diagramming. Heck, I’ve even been known to fire up a quick excel diagram when the situation calls for it. My PMs love that one, by the way ;)

And speaking of costs…

7. Review the Costs

The solution that you end up choosing could be the best technical solution in the world with the most ultimate level of performance and scalability. It could be a lean, mean content generating and personalization machine. It could include the fanciest of add-ons and the best bells and whistles. But if it costs as much as this year’s NASA budget to get some astronauts to the moon in 2024… then none of the technical ability matters. Budget is always a consideration, even when someone says it is not. In fact, it’s often more than just a single number. Another comment I have heard recently:

“I need to be able to calculate my CapEx vs OpEx costs for budgeting purposes.” – CTO

Larger organizations need to know a fine level of details on costs. I know it is quite a bit of work, but breaking apart a project into small chunks and estimating each chunk has been a successful technique for me to show clear and transparent pricing to my clients. There’s no reason to hide any costs, in my opinion.

In these breakdowns, I’ve been asked to represent the CapEx vs. OpEx amounts. This is a grey area to divide up completely and does depend on the organization. Generally, initial spin-up and configuration of the CMS can be broken down into CapEx costs, licensing falls into OpEx, and the main implementation of the site I’ve seen placed in both categories (depending really on how the CFO sees that organizations website as a pure expense or as a tool to generate ROI).

8. Pitch It

That’s it. Time to pitch it! You have covered the primary steps for building a recommendation. Again these steps mimic my methodology for building a solution for a client. Take all the knowledge you have learned, and hopefully documented, and walk into that pitch meeting knowing that you have more than just a feeling on what the client should do. Also, the steps are not written in stone; skip some, add some, make it your own process.

Common Headless CMS Concerns / Discussion Points

I also thought it was appropriate to state a few common questions, and my responses, that come up in these conversations:

Q: Where Does my Data Live / What about Data Sovereignty?

This depends on the vendor, but most modern headless CMS options can give you a choice of where your data resides. They have setup the CMS so that the data is bound to that data center. Kentico Kontent, for example, has the ability to choose between 3 different global regions for your project data: North America, Europe, and Australia. Any personal data is also handled with GDPR compliance as a nice bonus.

Q: Can I Bring the CMS On-Premise if I Want to?

Short answer here, most of the time, no. We have touched on many benefits of a headless SaaS-based CMS. There are a few headless CMS out there that you can run on-premise, but at that point, maybe traditional CMS is a better fit if you really want to run it on-premise.

Q: What about Search / How do I Provide Search Results of My Content?

Search is always a fun one. Again, a short answer, Search is on you as the developer/owner of the website. Most headless CMS offerings will not include this out of the box. You will likely be looking into external Search-as-a-Service options like Azure Cognitive Search, Algolia, or ElasticSearch and using your CMS’s API to index the content into those Search services.

However, I do not see this as a downside. These Search services have come a long way and provide excellent search experiences. In fact, even if we have a traditional CMS project these days, we almost always connect it to a Search service like Azure Cognitive Search anyways.

Q: What are the SLAs Like?

Most headless CMS come with a Service Level Agreement (SLA). The various pricing tiers might include higher or lower SLA options based on where you buy into the product at. However, most of these are run in Azure, AWS, Fastly, or other cloud-powered CDN. In my experience, they are all pretty good. Guaranteed SLAs and options for different infrastructure support with most likely put you into an Enterprise pricing tier, though. It is something to keep an eye on for sure when looking at signing up for a subscription to a headless CMS.

Q: What about data for my Store Locator, Mortgage Rate Calculator, or Student Application Form?

These are all examples of tabular data requirements. Honestly, this is one not-so-nice part about headless CMS that defines everything as a content type; there really isn’t just a database like with traditional CMS. Therefore, you might need to get creative with pitching solutions that require this type of tabular data. There are options out there like serverless functions to connect to data, external storage of JSON data, or other APIs from other services that can return to your app what it needs to make that Store Locator show location-based results.

Q: It Seems like a Somewhat Expensive Monthly Subscription Cost?

At first calculation, yes, it can seem like an expensive subscription. However, when you add up the alternative traditional CMS costs (hosting, maintenance, patching, upgrading, etc.) with the team’s services and support, the costs start to become pretty compelling. Overall, in my experience, because of the benefits of headless CMS, the development team and marketing team can be able to execute faster than in a traditional CMS sense (again given the right type of conditions) which makes the major work, the implementation, cost less. All of this, including training, services, and support options, should be considered a holistic view before just thinking of the one number without the full context.

Conclusion

If you are considering the question of traditional CMS vs. headless CMS, then hopefully, this post has helped. If you love the CMS comparison matrix I have created for Kentico Xperience and Kentico Kontent let me know via email or on Twitter via @mcbeev.