Traditional CMS – which one is right for you?

Headless CMS is a concept that has been steadily gaining traction over the last few years. An alternative to a traditional CMS, one of the key use cases for a headless CMS is the delivery of content to multiple channels. For example, a headless CMS can be a great way to centralise content destined for an app and a website, or multiple websites with common elements. There are other potential benefits to a headless CMS too.

However, headless is not the best solution for every organisation. There are many variables that go towards determining the best solution in a given set of circumstances. So it’s not a question of ‘Which is better, headless or traditional?’ but more a question of ‘Which is better for your organisation?’

To help people answer this question, on 30 March 2023, Luminary brought together a panel of CMS experts, comprising representatives from Contentstack, Kontent.ai, Optimizely, Sitecore and Umbraco – a mix of ‘pure’ headless providers and DXPs with a headless offering.

The video below is a recording of the presentation. The panelists were asked to provide responses to a mix of pre-determined questions as well as questions from the audience on the night. There wasn’t enough time during the event to put all of the questions to the panelists but you can find their responses to the additional questions below the video in this post.

The questions answered in the video were:

What are the pros and cons of headless? [@13.53m]
Other than the web, what channels are being used with headless CMSs? [@23.08m]
What kind of ‘heads’ are you seeing people implement? [@30.11m]
What is one really good use case for headless that you’ve seen? [@38.51m]
What is a good example of when an organisation should not be going headless? [@46.20m]
What is coming up in the pipeline for your platform? [@53.22m]
What does ‘composable’ mean to you? [@59.40m]
What are your thoughts on vendors offering the hosting of the head? [@1.09.00m]
Would you consider it more effort to build the same website as headless or traditional? [@1.13.38m]
Are there any industries that focus on your platform more than other industries? [@1.15.40m]
How does the editing experience compare between a more traditional and a headless approach to CMS? [@1.18.51m]
How can an organisation decide whether headless is a good fit for them? [@1.23.07m]

Additional Q&A

Here are the audience questions that we didn’t get time for…

With the ‘heads’, is anyone building tech to work directly with design tools like Figma to speed up time to market?

Deane: Yes. There’s a company called [A] that does a lot of Figma integration work. You can design something in Figma, then automatically bring content in from your CMS to populate the Figma frames and see how it looks with real content in it. I saw a demo. It’s neat.
Jake: Yes, Kontent.ai has had Figma integrations built. The API that Figma provides allows for headless CMS integrations and this is a great example of the way a micro-services architecture can be leveraged in a multitude of ways such as integrations with design tools. We have a great article written on the topic of integrating a headless CMS like Kontent.ai with Figma, for those who are interested – you can do a Google search for it: “why you should use Figma with a headless CMS”.
Mick: Sitecore’s hybrid and headless solution XM Cloud comes with a Front-End-as-a-Service capability called Components, which as part of its ongoing roadmap will look to have integration with design tool systems such as Figma.

Does anyone have an example of a client who chose a hybrid approach and how that worked? Decoupled e-commerce but traditional content for example?

Jerry: No. Projects should to be either headless or traditional (coupled). Hybrid approaches negate the benefits of headless architecture while requiring extra development work in the form of traditional server-side templating (.Net etc) and modern front-end development (in for example React/Vue).

How is AI and GPT4 (and 5, 6, etc.) going to change the headless and DXP market?

Jerry: API-first systems like Headless CMSs allow for easy integration into 3rd party services live ChatGPT and AI services. Contentstack for example has added ChatGPT to their editor for content recommendations within weeks of the release. See: https://www.contentstack.com/company/press/contentstack-adds-openai-chatgpt-integration-to-its-industry-leading-composable-digital-experience-platform/

As our VP of Product, Conor Egan, said: “AI fits hand-in-glove with headless CMS and more broadly with a modern Composable DXP stack. The ChatGPT integration is just the tip of the iceberg in terms of new AI-assisted functions and capabilities. Ultimately, we see AI and automation technologies touching virtually all facets of the digital experience stack, transforming content creation, code development, and asset creation forever.”
Mick: Looking at this from a content lens, AI such at ChatGPT is already proving useful in augmenting and streamlining content creation processes. It’s no secret that a big challenge for omni-channel content, including multiple audiences, is the generation of associated content. ChatGPT can be incredibly useful to support content creators is shaping relevant content and for that matter imagery based on specific channels and audiences, helping get to market more quickly.
Jake: I have two points to make on this:

The first point, I think we will see an increase in AI being leveraged in the overall CMS operations, though not necessarily via vendor-built functionality. A good CMS platform that makes integrations simpler, will make way for custom development of AI functionality to assist in content orchestration. For example, in Kontent.ai, we are seeing custom development where AI tools such as ChatGPT (and other players) are leveraged and integrated into the content model – such as fields that are automatically populated based on the content of other fields. An example might be a content body field on an article, where the summary/blurb field is auto populated by an AI tool that has been instructed to summarise into 1 paragraph (AI is excellent at summarising, by the way). Other examples are where AI is used to scaffold a content type where fields such as SEO, image, summary (as mentioned prior) are auto-populated and then either left as-is or edited further in the content production process. I think if a CMS offers a good integration platform experience (integration into the content model, CMS events and custom application development), it will bring about a lot of very interesting, organic, AI-based development.

The second point, at a higher scope and at the micro-services architecture level, we see other AI-based platforms being used along-side a headless CMS to be part of the entire content life cycle. That is: in the content creation step, tools such as: Copy.ai, Copysmith, Rytr; in the content management step, tools such as: HubSpot, Conscia, Google AI, Einstein, MS Cognitive Services; in the content delivery step, tools such as: Recombee, Algolia, Dynamic yield, Lucidworks, Conscia, DeepL.

What do you think about Headless Commerce?

Deane: It’s a natural fit. Commerce UX tends to be very interactive – data going back and forth from browser to server. Additionally, purchase rates are inversely proportional to site performance. People buy from fast sites, and the interactivity of commerce UX threatens to slow things down.
Mick: There are so many valid approaches to commerce, and where we are seeing value drivers for headless commerce is customers that are looking to step up their commerce to the next level, or where unified experiences across B2C, B2B and B2X scenarios require a very flexible and API-first solution. Being headless also means the ability to transition over time is feasible with an existing front-end application. Where customers already have existing technology stacks for varying purposes, we see alignment in the headless space in being able to compose their ideal solution stack.
Jerry: Headless commerce is growing in popularity as the core product management and check-out is provided as a scalable and reliable service. The Headless CMS is then used to manage the content, campaigns and preview, Just like other tools in the headless category, a headless ecommerce solution is one in which the back-end codebase is decoupled from the front-end features with which workers and customers interact — think multi-channel storefronts, product information and inventory management tools, marketing and sales platforms, payment systems, and more.

APIs enable all of your various systems and services to work together without becoming fully entangled. This means functionality can be updated or swapped out to keep your tech up to date. At the same time, information flows seamlessly among apps so your content is always up to date across channels, your inventory is accurate, your payments clear quickly, and everything is generally running smoothly.

Read more about this here: https://www.contentstack.com/company/press/contentstack-adds-openai-chatgpt-integration-to-its-industry-leading-composable-digital-experience-platform/
Jake: Like headless content management – headless commerce is the separation of frontend from the backend application. This architecture offers brands freedom of expression to build whatever and however they want. Most importantly, it enables brands to enrich the customer experience. Much like a (content hub type) headless CMS, an e-commerce specific headless platform works in much the same way – excellent e-commerce functionality in the back end and flexibility to serve decoupled channels via APIs. An e-commerce platform can also be leveraged within a headless CMS such as Kontent.ai. We have a Shopify integration, for example, that provides a Shopify product selector into the Kontent.ai content model.

Are there techniques/strategies/tooling recommended for ensuring backward compatibility for heads?

Deane: Ha! I have to laugh because this is just another example of moving complexity around. There’s a lot of talk in the headless/decoupled space about safety in composability and just “plugging things in,” but it’s not that simple. Upgrade hassles still exist, they’re now just distributed.

On a less cynical note, I think GraphQL will make this better. We finally have a common standard to rally around. I think heads will certify to a GraphQL version.
Jake: Being on the traditional CMS/DXP side of the fence for most of my career, and now on the headless CMS side, I can say that like most development projects that comprises a database back-end, a front-end presentation layer, and business logic that mediates between the two, a development team must have processes in place to ensure data-related changes don’t break business logic and front-end applications. This is true for both tightly coupled DXP platforms and fully decoupled headless CMS platforms. A headless CMS that sits in a wider micro-services architecture should in theory support more channels so of course care needs to be taken when making content model changes – to ensure all channel specific codebases continue to function. This comes down to each development team having a set of practices they follow – irrespective of traditional or headless. I’ve seen websites built on a traditional DXP fall over because a content model update was made to a single database field and the business logic driving the presentation layer wasn’t updated. Coupled or decoupled, this will be down to a development team following internal best practices, in my view.
Mick: Looking at Sitecore XM Cloud as an example, we are committed to non-breaking changes, to support this type of concern with backward compatibility.

When designing for headless, is it important to have designed the heads so that the content/data accommodates all needs?

Jake: This is a great question and conversations about this sometimes border on the philosophical side. Pure content-first approach which is channel agnostic versus channel-specific approach to content modelling. This somewhat depends on the content maturity of the organisation and therefore also the market space we are talking about. What I have seen is that organisations that are smaller and have a less mature content strategy may tend to see their content in a web-specific context. This could be because they mainly propagate their content through a web channel. For organisations such as this, a content model that is more web-focused could be the way to go. However, content-mature organisations in the enterprise space do not generally look at their content in a channel-specific way. From my experience, these organisations are more likely to be concerned with the content orchestration within their organisation (collaboration, governance, etc.). For example, seeing the need to create and collaborate on a news article in a near-perfect way as an article and not as an article on a web page. These larger organisations will also generally be technically geared with (or will be partnered with) mature development teams that can execute a channel-specific development piece based on an agnostic content model. I think the question raises a relevant concern but also one that is less prominent as we approach the larger enterprise space.

Should we all just go back to Dreamweaver?

Mick: What’s old is new again seems to pop up in all industries lately!

Is headless/traditional an all or nothing decision?

Filip: No. Lots of hybrids out there. Probably the most frequent use case is exactly what the question says… Choose a CMS that doesn’t force you to make a hard choice, but gives you the flexibility.
Jake: It’s not an all or nothing decision. The flexibility of headless systems is that they can integrate with any other system that has API layers including traditional CMS.
Mick: Definitely not. Each play a part. Don’t forget that hybrid solutions such as Sitecore XM Cloud support the best of both worlds. You have the ability to consume content from any channel application through native and performance GraphQL APIs, or create web applications with tools like as NextJS that support native WYSIWYG for dynamic layout and editing for the authors. The most important part of making any of these decisions is understanding the problems and challenges that need to be addressed, and formulating the best solution to support driving value.

Is the future of CMS/DXP (headless or otherwise) completely SaaS?

Mick: Only time will tell. PaaS/IaaS is still seen as preferred in some industries due to strict security requirements, however in the current climate, organisations are looking at ways to reduce infrastructure spend and gain additional efficiencies. A key benefit to SaaS is the ability to offer continued value realisation, as customers do not have to plan, budget or execute on upgrades. Customers are increasingly wanting to shift the burden of managing infrastructure, hosting, DevOps, SecOps etc, which opens up the ability to focus more on feature delivery at a speed and scale that has ever been available before.
Filip: “I don’t think so. I think the market for customisations is still big, growing and will stay around. But that doesn’t mean SaaS won’t also grow. But there are many use cases for custom code on the CMS/DXP space! It will become more and more important that deep integrations are available between platforms.”
Deane: Not completely, but probably mostly. Opti is going to offer a SaaS version soon. I still like PaaS for it’s deeper integration capabilities – it’s tough to write in-process code against SaaS, but we’re even working on ways to split the programming experience into two levels – “root” level, which for us would be in-process C#, and a “higher” level, which would be some sandboxed scripting language. I hope the industry will solve issues around what I’m calling “programmable SaaS.” Then we’d have the best of both worlds.

What is the lifetime of a website?

Filip: “I think it varies a lot. 10 months is probably to the short side yes, but lots of website are made for occasions, events, campaigns etc and only last a lot shorter. Of cause the bigger digital experiences should probably last more than 10 months if the investment should have a return…”

With the front end fracturing as Deane mentioned, are CMS/DXP vendors going to help solve that or leave it to the market?

Jake: Fractured is a strong-term and is not an accurate representation of the dynamic between headless CMS and front-end channel. A pure decoupling of the front-end offers freedom for channel development, where previously development teams were bogged down not only by a specific technology stack, but by in-CMS presentation templating tools. In several cases, I was involved in projects where for enterprise level clients who were locked into their traditional DXP, it was necessary to painstakingly decouple the DXP from its native presentation layer and plug-in a custom front-end. The market began demanding this a while ago. It’s a contributing factor to the advent of the headless CMS and one of the reasons why traditional CMS/DXP platforms are providing headless capabilities via APIs.

However, to the point of the question, headless CMS vendors and more specifically Kontent.ai, are providing a rich channel-specific editor experience via tools such as Kontent.ai Web Spotlight, which offers excellent web-centric content editor experience with page preview, on-page editing and multi-site support.

I would say the dynamic of headless CMS and front-end therefore is not at all fractured but offers a choice of web-centric editor experience much like your traditional CMS, a fully decoupled form-based editor experience to allow for a content-first approach without channel-specific bias in the content creation, and any combination of the tow. The key take-away here is that headless offers you a choice and therefore freedom and empowerment.
Mick: We’re starting to see the rise of Front-End-as-a-Service solutions in market, which Sitecore XM Cloud is providing as part of its Components capability currently in Early Access. Being able to define brand styling, e.g. colours, typography and spacings, through visual UI in a low/no-code way to build out component collections in React or native JS is a very disruptive opportunity. It’s a very exciting time for FEaaS, which provides speed-to-market and self-service capabilities which customers are increasingly prioritising.

How do you make sure human content editors are doing a good job reworking content to make sure omnichannel messages are appropriate for each endpoint?

Deane: I always say this: experiment. If your editors are forced to write multiple headlines, for example, and run experiments, they will give a much, much better effort at it. At its core, experimentation is just interesting. It really gets editors to take a more active role in what they do.
Mick: Ideally need to delve into this question in more detail. What constitutes an appropriate message for a channel? This is potentially where AI is going to support and help content editors in adapting content for varying endpoints, which can be easily coupled into workflow processes to ensure adequate human governance is still firmly in play.
Jake: Content Model design is key when planning for the overall content strategy that may include multiple and varying channels. A good content strategy should ensure that the content model agnostic of any specific channel so as not to introduce channel bias in the content production process. The advantage of a decoupled front-end separates these concerns of content creation vs. content propagation. It frees up the content editor to focus on producing great content in a pure form, free from having to think about channel-specific nuances that would otherwise detract from the experience of simply writing good content. And a well-designed content model allows development teams to focus on creating well-crafted channel applications. A content creator shouldn’t have to be thinking about manipulating their content to fit a particular channel or channels.