From Sitecore to Headless: Worth It or Not?

Alem Huseinspahic
October 07, 2021 10 min read

One of our clients recently underwent a merger and immense business growth, which resulted in the need to find a more flexible and efficient CMS solution than Sitecore, a CMS they’d been using for well over a decade.

The decision was to switch to headless architecture. But why? And was it worth it?

What is headless and why is it so popular? 

As we all know, everybody’s been talking about headless CMSs, especially in the last two years. According to Google Trends, this trend keeps rising, as you can see in the image below.

Most organisations and agencies are relying on traditional CMSs to build websites and create content dynamically with predefined templates. In addition, everything is localised (templates, web parts, content) in one place in a traditional CMS. What’s also interesting is that, according to w3techs, around 40.9% of websites are using WordPress, which is classified as a traditional CMS. Moreover, out of the top 1 million websites in the world, 840.000 are using mostly traditional CMSs, according to

So, why have headless CMSs been gaining so much momentum in the recent years? Well, headless is considered and introduced as a CaaS (content-as-a-service)/SaaS (software-as-a-service) model and mostly hosted in the cloud.

There are some self-hosted solutions out there on the market, but in this article, we focus on cloud-hosted solutions due to their high level of security, lower entry barrier, and the ability to solve most infrastructure problems easily. 

A cloud-hosted headless CMS handles the content and delivers it to a variety of apps, which is a process known as omnichannel content distribution. This means that you’re modelling and creating your content within the headless CMS and distributing it over the REST APIs where needed.

That is why the headless CMS is often called technology-agnostic – content can be distributed to different applications built with different technologies. 

However, it is important to understand that headless is not necessarily an ideal fit for everyone. Everything depends on your business needs. For instance, it’s excellent for larger teams that need the ability to properly collaborate on content or businesses that want to reach consumers on their smart devices. On the other hand, it isn’t necessarily the best option for small teams with insufficient in-house experience or resources.

In this article, I will try to explain how to decide whether to opt for a headless CMS or stick with the traditional model.

Is a headless CMS the right solution for you? 

Choosing your CMS is a huge decision, especially if we’re talking about migrating from a previous CMS to a new one. So, how do you make the final decision? What factors should you consider?

As mentioned in the beginning, one of our clients actually made the choice to switch to a headless CMS after 10 years of using Sitecore. Our client comes from the global production industry and branches into dozens of brands, with every brand encompassing numerous products and every product being divided by industry applications, categories and subcategories.

A decade ago, Sitecore was the perfect choice for our client, but moving forward, our client made some advancements in the business by merging with another giant in the industry two years ago, which made things more complicated for the developers.

Now, imagine handling 20+ sites in the single instance of Sitecore, with different languages – 120 languages, to be exact. While handling this in the Sitecore CMS is achievable, the contemporary circumstances, global digitalisation, and speed of technology evolvement have brought new requirements and business issues that ultimately required a more flexible and time- and cost-efficient CMS.

A growing business leads to growing demands on multiple levels, which in turn brings about the need for constant infrastructure upscaling. This is quite a lengthy, complex and costly process. In order to overcome the aforementioned issues, we started working on finding a solution together with our client.

We concluded that the most suitable option would be a headless SaaS model. This decision was backed by a number of reasons. Let us explore them below.

Content centralisation

Our client, like many other businesses, uses other e-commerce platforms where it would be possible to employ headless content based on the principle of “one source of truth”, which means changing the content in one place would change the content on all platforms. This is a process that saves a lot of time and money in the long run.

Omnichannel presence and a consistent user experience on all channels

This has become an indispensable part of business success. Headless architecture helps achieve a solid presence on all channels and provide users with a seamless experience on all. This is thanks to the use of APIs and the separation of the back end from the front end. A headless CMS allows businesses to automatically deliver content to e-commerce platforms, mobile apps, smart devices, VR, chatbots, etc. as soon as it’s created centrally in the CMS.

Faster development

Presently the development process takes a very long time, which ultimately leads to higher costs as well. We concluded that moving to a headless CMS would significantly reduce the time required for development thanks to the use of APIs and separation of back end and front end. Everything about the process would be focused on the front end and UI.

That way, the migration to headless would greatly contribute to the final product and add value to it, while allowing the client to save time and money. Developers also have more flexibility as they are free to choose the programming language and framework they want to work with, while traditional CMSs usually require a specific, fixed structure.

Cost reduction

As suggested previously, migrating to headless reduces all costs related to infrastructure, backups, development, licencing, maintenance and content creation. This is because the only cost would be the subscription to a headless vendor, who typically carries the responsibility of maintenance, security, upscaling, etc.

High level of security

Cloud-hosted headless CMSs are immensely secure. Unlike traditional CMSs, they aren’t code- and file-heavy, so there is little material vulnerable to cyberattacks. Moreover, headless CMSs typically use read-only APIs, and there’s even an option to apply an additional protective layer of code to the API. 


Because of its support of omnichannel publishing, its high level of protection, flexibility for developers and other benefits we mentioned, a headless CMS makes it easier to keep up with future technological innovations. It’s easier to adapt to new demands and make modifications, which means your CMS is future-proof.


Headless is flexible and can easily fit with everything JS, .Net, PHP, Java, Ruby etc., unlike the traditional CMS approach, where you’re tied to a specific technology and additional time is needed for developers to be trained for the specific CMS. Naturally, that’s a long-term process and usually quite costly.

So, with headless, the technology stack is the last thing to worry about, because it only requires front end developers who will be able to put the content pieces together and make them visually appealing. 

Improved speed of delivery

Another key factor in our client’s migration to headless was the speed of delivery. It initially takes some time to set up a headless CMS, but after doing this, everything is set and ready to take off. Then your developers can fully focus on building the front end as the content is available via automatically scalable delivery API that is proxied through a CDN

Various content editing features

Adopting headless doesn’t mean losing the collaboration features, editing workflow, roles, or even preview APIs (which mean that the content can be previewed before publishing). All those fancy features are there, including multilingual support.

Migration results

Once our client switched to headless, the results were mesmerising. All the goals were achieved and costs were reduced considerably.

So, imagine the current infrastructure with 10+ servers, licencing, backup and failover solutions, third-party integrations, and maintaining and securing all of this. This is what it looks like:

Current CMS infrastructure

Moving from a traditional CMS to headless would lead us to something like this:

Infrastructure after moving to headless

The diagrams above showcase how much headless simplifies things in regard to infrastructure and how much flexibility it gives us developers. With its prebuilt Management API, we can migrate the content and extend the headless interface with existing third-party tools such as external DAMs so we can pick our assets directly from the headless without even changing the interface. And on top of that, Delivery APIs are used to distribute the content where needed. 

Introducing the headless CMS Kontent

I will briefly walk you through the Kentico Kontent interface, which is currently in the top 10 headless vendors on the market. What distinguishes Kontent from its competitors is a great user interface, which is intuitive and nicely done – everything you need is exactly where it should be. Plus, it is a great fit for larger teams thanks to advanced collaboration features. 

In the image below you can see what your homepage looks like in Kentico Kontent. You’re able to see your recent edits, creations, content assigned to you, tasks assigned to you, etc.

Also, you can create your content item right from this page in any language version you want. There are features such as Project overview and Editorial calendar so you and your team can stay on track with ongoing work. Tasks can be assigned to collaborators, which they will be notified about via e-mail and upon their login to Kontent.

( – settings related to Homepage of the Project)


This is what content item editing looks like with all options mentioned above.

( – settings related to Editing content item and its features)


In the Editorial calendar, for example, you can see content scheduled for publishing, published content, delayed content and content on track (due date is less than today). See the image below.

( – settings related to Editing content item and its features)


In the image below, you can see Workflow related settings. Here you can configure your workflows, assign certain steps with a certain role, create or delete steps, and much more.

Kentico Kontent Workflow( – settings related to Workflow)


Below we can see how easy it is to add languages and set up localisations within Kentico’s headless CMS Kontent.

Kentico Kontent - Localization( – settings related to Localization)


More information about the features can be found on the Kontent website and in relevant documentation.

The bottom line

Based on all the features mentioned in this article, it’s possible to conclude that headless eliminates the need for additional resources, maintenance, and licences, development-wise. Going headless means rolling out new changes fairly quickly when it comes to content, but new sites as well; instead of months, it takes weeks.

Both the developers and the marketers/content creators get to make the most of the CMS and finish their tasks faster, so the workload is ultimately reduced and both teams can focus on doing what they do best without becoming frustrated or losing time.

In sum, headless (and Kentico Kontent specifically) is an excellent choice for companies looking to achieve seamless omnichannel marketing, facilitate the workflow for their large development & marketing teams, have a high level of protection, and run an overall future-proof CMS.

Keep in mind, though, what I mentioned earlier: While headless brings a myriad of benefits, it’s not the best choice for every business. So, make sure to carefully evaluate your business needs and resources before migrating to headless.