Headless or headful? A practical framework for your CMS replatform

Frame the decision clearly

If you're planning a CMS replatform, you're likely choosing between two architectures: headless and headful. It’s likely you’ve also been told that headless is the future-facing option, the one that brings flexibility, scalability and multi-channel reach by separating your content from how it's presented.

There's real merit in that, but headless is one good option, not the only one: a well-chosen headful platform can serve you just as well. Both are legitimate, and the right choice depends on your context: your team's size and skills, the complexity of your digital estate, your budget, and where you want to spend your ongoing resources.

A more practical way to look at this is: where should the complexity live, and is it worth the trade-off?

Understand how each approach works

A traditional, or "headful," CMS does two jobs at once: it manages your content and builds your website. You publish a page, and the same system delivers it to your visitors.

A headless CMS splits those jobs. Content lives in the back end and travels through an API (a connection that lets one system request content from another) to a separate front end, which might be a website, a mobile app, or any other channel.

The two aren't really opposites, though. They sit on a spectrum, from fully integrated at one end to fully decoupled at the other, with plenty of hybrid positions in between. This is the point that tends to reframe the whole decision: a well-built headful CMS with a strong content API can syndicate your content to mobile apps, partner systems and other channels just as a headless platform would, while still rendering your own website. Multi-channel reach comes from the quality of your content API, not from the architecture you choose.

Choose headless when it earns its place

Headless brings real benefits, and there are clear situations where it's the best choice:

• You have a specialist front-end team. Decoupling lets that team deploy as often as they need, control their own tooling, and evolve the front end without being tied to the CMS. That autonomy reduces cross-team dependency and creates clearer ownership.
• You need a strict security boundary. Some organisations want the public-facing front end kept separate from the back end that holds their content and sensitive data. An API boundary between them can simplify security, especially under strict compliance requirements.
• You need independent scaling. Each site or app can scale to its own traffic without scaling everything else.
• Content is your product. If your main job is producing structured content for several external systems, such as a media company feeding partner apps or a product-data provider serving hundreds of retail front ends, then the CMS is really a content store, and headless fits that job well.

Adobe's own guidance suggests weighing six questions before you commit: the role of your content, the size of your developer pool, affordability, whether your use cases are defined, your digital maturity, and the state of your current CMS. If you can answer those confidently in favour of headless, it's a sound choice.

Choose headful when it keeps things simple

For many organisations, especially those whose main deliverable is a website with some multi-channel needs, a headful CMS with good API capabilities is often the better fit, and it can cost less to host, maintain and develop.

Fewer moving parts mean faster delivery and less maintenance. A headful CMS is one application: a single codebase, one deployment pipeline, one set of logs to debug. A headless setup is at least two systems joined by an API, each with its own deployment process and failure points. As one Optimizely developer noted, going headless means owning routing and URLs, on-page editing and preview, build-and-release across two applications, and login security. None of that is impossible to manage, but it all adds work, ongoing cost and maintenance that an integrated system avoids.

A few other things tend to be simpler in a headful setup:

• Analytics, consent and tag management, because pages and navigation follow familiar patterns and marketing tools fit naturally into server-built templates.
• Integrations with CRM, marketing automation and donation platforms, managed within one system and more opportunity for using the same integrations in both the public facing site and the CMS administrative / editing interface.
• Login areas and personalised content, which happen inside a single request and response rather than across several coordinated services.

A headless build can handle all of this too, though it tends to need more deliberate engineering and governance, and can add latency if it isn't managed carefully. For organisations where every pound spent on infrastructure is a pound not spent on the mission, less complexity frees up budget for what matters most.

Look past the common assumptions

A few assumptions tend to drive these conversations, and they're worth examining before you decide.

"Headful can't do anything dynamic." A CMS like Wagtail or Drupal can deliver logged-in dashboards, personalised content, calculators, countdown timers, real-time data and conditional journeys. The same client-side tools that power headless front ends, such as JavaScript, React and Vue, work within headful templates too. The rendering approach doesn't limit what you can build; it simply means one system to manage rather than two. And performance-wise, caching is the single biggest lever for both approaches.

"Only headless can drive multiple channels." Multi-channel delivery has little to do with being headless. A CMS like Wagtail can run any number of sites from one instance through built-in multisite support, as can Drupal, Umbraco and Craft. It can serve its main website through server-built templates while exposing the same content through APIs to mobile apps, digital signage or any other channel. The NHS and Caltech both run major web estates on Wagtail, including multisite and multi-channel setups.

"Headless is always overkill." This goes too far in the other direction, and it's just as unhelpful. As the earlier section sets out, there are clear cases where headless is the best approach: large specialist teams, strict security separation, content-as-a-service models, and organisations with the maturity and budget to sustain the extra operational work. Dismissing it outright is as reductive as defaulting to it.

Weigh cost, sovereignty and sustainability together

In practice, headless decisions are often driven by SaaS content platforms such as Contentful, Contentstack, and Sanity, which bundle API-first delivery with managed hosting. Headful systems, by contrast, are often open-source and self-hosted.

The distinction matters for cost: both approaches cost money, they just structure it differently. An open-source CMS has no licence fees, no per-seat charges and no API limits, but you (or your agency partner) take on hosting, infrastructure, security patching and upgrades. A headless SaaS platform hands much of that load to the vendor, which is a real benefit. It also adds licensing fees, often significant ones at enterprise scale, plus the cost of a separate front end to build, host and maintain. Neither model is better by default; the question is which is better value for your project.

A further consideration for public sector and regulated organisations is data sovereignty. A SaaS content platform means your content data lives on infrastructure you do not control, subject to the laws of the jurisdiction where your vendor is incorporated. For some organisations that is an acceptable trade-off; for others, particularly in healthcare, government and financial services, it is not. The French government's central digital authority made exactly this calculation when it chose Wagtail as the foundation for its shared government website platform: open source and self-hosted, keeping content data under national jurisdiction.

A headless setup is, at its core, a distributed system: two or more applications communicating over a network rather than running as one. The software industry has been rethinking the cost of that approach more broadly. Thoughtworks notes that distributed services need extra infrastructure to connect and manage them, which adds expense, especially early on. Amazon's Prime Video team consolidated a monitoring tool from a distributed setup into a single application and cut infrastructure costs by over 90%. And the Cloud Native Computing Foundation's annual survey suggests around 42% of organisations that adopted microservices are now consolidating them back into larger units. None of this makes distributed architecture wrong; it means the costs are real and worth weighing case by case.

Sustainability deserves a place in the decision too. Running two applications, two pipelines and two hosting environments uses significantly more energy than running one well-optimised system, which adds to your digital carbon footprint. For organisations with sustainability criteria or environmental commitments, that's a measurable difference rather than a footnote. As with cost, it doesn't rule out headless where the use case justifies it, but it does belong in the conversation.

Start simple, and extend when you're ready

The practical takeaway is this: you don't have to take on maximum complexity upfront to keep your options open.

A platform like Wagtail or Drupal works across the whole spectrum, from headful to fully headless. It can render your main website with full editorial preview and live editing, while exposing the same content through APIs for any channel that needs it. You can start headful and add decoupled delivery later, for a mobile app, a partner integration or digital signage, as soon as a real use case appears. There's no need to replatform to do it - the architecture can grow with you.

Build API-first thinking into your content model from day one, structure your content for reuse, and you'll be ready to extend into headless delivery without paying to run two systems from the start. When we built Nesta's website on Wagtail, we designed the content model to support both the main site and Nesta's in-house data science team, who use Python to build interactive data visualisations into the site. The architecture was headful but API-ready, so when new channels or integrations come along, the foundation is already there.

Keep your mission in focus

Which approach lets you move faster, learn more and deliver more value for the people you serve?

For some organisations, headless is the answer: the team has the skills, the channels demand it, and the security model requires it. When that's true, headless isn't an indulgence. It's what lets the organisation move fastest and deliver most.

For many others, the best architecture is the simplest one that meets the real requirements, with room to extend through APIs as needs arise. This is where our deepest experience lies, with charities, non-profits and public sector teams. The value of a replatform isn't in the architecture diagram, it's in what the team can do once it's built: measuring reach, improving journeys, testing what works, and improving a site that serves its users.

Either way, you don't have to decide everything on day one. If you'd like a clearer view of the trade-offs for your context, we'd be happy to talk it through. It's often a discovery phase that shows which approach is right for you.