Headless vs traditional CMS

A traditional CMS and a headless CMS both manage content. The difference is what happens after the content is written. A traditional CMS renders the finished web pages itself, using themes and templates that come with it. A headless CMS stores the content and delivers it over an API, leaving a separate application, the front end, to decide how it looks. The choice between them is really a choice about where the presentation lives.

The traditional model

In a traditional CMS, content and presentation are one system. You write a page, the CMS applies a theme, and it serves the finished page to a visitor. WordPress, Drupal, and Sitecore in their classic form all work this way. The advantage is that a website comes out of the box: pick a theme, add content, publish. For a single content-simple site run by non-engineers, that is often all that is needed.

The limit shows up when the content has to appear somewhere other than that one website, or when a team wants to structure content more rigidly than the templates allow. Because presentation is baked in, reaching a mobile app or a second site usually means bolting on plugins or re-entering content.

The headless model

In a headless CMS, content and presentation are separate. The CMS manages structured content and serves it over an API; a front end your team builds reads that content and renders it. The same content can feed a website, an app, and other destinations because none of them is baked into the CMS. The cost is that the front end has to be built and maintained rather than coming ready-made.

How to tell which one fits

The honest test is not which model is more modern but which matches the requirement in front of you.

• A traditional CMS fits when the need is one website, the people running it are not engineers, and a theme plus plugins covers the job. Moving off it adds cost and engineering the situation does not call for.
• A headless CMS fits when content has to reach more than one destination, when a team wants content in a structured, version-controllable form it can build against, or when the templating of a traditional system has become something to fight rather than use.

Many teams sit on a traditional CMS for years and are right to. The case for moving usually appears when the team is already working against the tool rather than with it. For related concepts, see content platform and MACH. For what a move between specific systems involves, the migration guides cover individual platforms.