Headless or Headful? A practical framework for your CMS replatform

Choosing with confidence, not convention

If you are currently evaluating Content Management System (CMS) options for a website replatform, you have almost certainly encountered the recommendation to “go headless.” Headless CMS platforms have been positioned as the modern, future-facing choice for the best part of a decade. The narrative is familiar: decouple your content from your presentation layer and you gain flexibility, scalability, and multi-channel reach.

That narrative is not wrong, but it is incomplete. This article is not about picking a winner between headless and headful architecture. Both are legitimate approaches. The right answer depends entirely on context: the size and skills of your team, the complexity of your digital estate, your budget, and where you want to invest your ongoing resources.

What this article does argue is that the question too often asked in procurement conversations is “which is more modern?” when it should be “where do we want complexity to live, and will that complexity earn its keep?” The aim here is to give decision makers a practical framework for answering that question with confidence.

What headless really means

In a traditional (or “headful”) CMS, the system that manages your content also renders your website. You create a page, hit publish, and the same server that serves the CMS serves the finished HTML to website visitors. A headless CMS separates these two jobs. Content is managed in the backend and delivered via an Application Programming Interface (API) to a completely separate frontend application, which could be a website, a mobile app, or any other digital channel.

A crucial point that often gets lost: headless and headful are not binary opposites. The spectrum runs from fully integrated (CMS renders the website) to fully decoupled (CMS is purely an API, frontend is a separate application), with hybrid positions in between. A well-architected headful CMS with a good API can serve content to multiple channels exactly as a headless platform does, while also rendering its own website. The multi-channel capability is an API feature, not an architecture-exclusive one. This distinction matters enormously for the decision.

When headless is the right call

Headless architecture has clear, defensible value, and it is important to be specific about when and why.

Organisations with specialist frontend engineering teams can benefit from the separation headless provides. The advantage is organisational and architectural: frontend teams can deploy as frequently as they need to, they have greater control over their tooling and release processes, and the freedom to evolve the presentation layer without being tightly coupled to the CMS runtime. Where teams need that autonomy, and where changes can be managed through a stable API contract, decoupling the frontend from the CMS can reduce cross-team dependency and create clearer ownership boundaries.

There can also be security benefits. Some organisations need a clean separation between the frontend (which faces the public internet) and the backend (which holds content and potentially sensitive data). Keeping these in entirely separate applications with an API boundary between them can simplify security architecture, particularly in environments with strict compliance requirements.

Performance matters too. With a headless setup, each website/app can scale independently to handle varying levels of traffic without scaling everything else (i.e. the backend) at the same time.

For organisations whose primary function is producing structured content consumed by several external systems, headless is a natural fit. Think of a media company whose content feeds multiple partner applications, or a product data provider serving hundreds of retail frontends. In these cases, the CMS is fundamentally a content store, and a platform designed around that use case makes sense.

Adobe’s own assessment of headless architecture recommends honestly assessing six questions before committing, covering the role of your content, the size of your developer pool, affordability, defined use cases, digital maturity, and the status of your current CMS. Organisations that can answer those questions confidently in favour of headless should feel good about the choice.

When headful makes more sense

For most organisations, particularly those whose primary deliverable is a website (or a family of websites) with some multi-channel needs, a headful CMS with good API capabilities will deliver a better outcome at a lower cost.

Fewer moving parts mean faster delivery and lower maintenance. A headful CMS is a single application: one codebase, one deployment pipeline, one set of logs to debug. A headless setup involves at minimum two separately maintained systems connected by an API layer, each with its own deployment process and potential failure modes. As one Optimizely developer wrote after completing a headless build, teams going headless take on full responsibility for routing and URL management, on-page editing and preview, CI/CD (Continuous Integration/Continuous Deployment) complexity across two separate applications, and authentication. None of these are insurmountable, but they all represent work, cost, and ongoing maintenance that does not exist in an integrated system.

Analytics, consent management, and tag governance can be simpler to implement in a headful CMS because page rendering and navigation usually follow more conventional patterns, and marketing tooling often fits naturally into server-rendered templates. Integrations with CRM, marketing automation, and donation platforms may also be easier to manage within a single platform runtime. A headless architecture can offer greater control and flexibility in these areas - but usually requires more deliberate frontend engineering and governance.

Features like login areas or personalised content are significantly easier to deliver in a headful setup, where everything happens within a single request/response cycle. Because the CMS, templates, and user sessions live within the same system, personalisation is straightforward. In a headless architecture, this often involves coordinating multiple APIs and services, adding complexity and potentially introducing latency if not carefully managed.

For organisations where every pound spent on technical infrastructure is a pound not spent on mission delivery, reducing complexity frees up budget for the things that matter most.

Three myths worth challenging

“Headful is outdated.”

This is one of the most persistent misconceptions in the CMS conversation.

A modern CMS like Wagtail or Drupal can deliver dynamic, interactive user experiences including logged-in dashboards, personalised content, calculators, countdown timers, real-time data displays, and conditional user journeys. The same client-side languages and frameworks (JavaScript, React, Vue) that power headless frontends can be used within headful templates. The rendering approach does not limit what you can build; it simply means you have one system to manage rather than two.

“Headless is more flexible.”

The myth persists that for example, if you need your CMS to drive multiple websites or applications / content delivery methods you need a headless solution.

This is not true. A CMS like Wagtail can power any number of websites from a single instance through built-in multisite capability (as can solutions like Drupal, Umbraco and Craft CMS). It can simultaneously serve its primary website through server-rendered templates and expose the same content via APIs to mobile apps, digital signage, or any other channel. The British NHS, and Caltech both run major web presences on Wagtail CMS, including multi-channel and multisite configurations.

“Headless is always overkill.”

This myth runs in the opposite direction, and it is equally unhelpful. As the previous section on when headless is the right call makes clear, there are well-defined scenarios where the separation headless provides 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 operational overhead. Dismissing headless wholesale is just as reductive as defaulting to it.

The cost and sustainability reality

Both approaches carry costs; they are just structured differently. A modern open-source CMS has no licensing fees, no per-seat charges, and no API call limits, but the organisation (or its agency partner) takes on hosting, infrastructure management, security patching, and upgrades. A headless SaaS CMS offloads much of that operational burden to the vendor, which is a benefit, but it comes with platform licensing (which for enterprise providers typically runs into tens of thousands of pounds per year), plus the cost of building and maintaining a separate frontend application. Industry benchmarks commonly cite implementation and onboarding timelines of 8 to 16 weeks for headless setups, with custom integration costs typically ranging from £5,000 to £50,000 or more. Neither cost model is inherently better; the question is which represents better value for the specific project.

The wider software industry has been reassessing the complexity costs of distributed systems for several years. Thoughtworks notes that microservices need extra infrastructure such as API gateways, load balancing, and service discovery, making them more expensive especially in the early stages. The Amazon Prime Video engineering team famously consolidated a monitoring tool from a distributed architecture to a single application and cut infrastructure costs by over 90%. And according to the Cloud Native Computing Foundation’s (CNCF) annual survey, approximately 42% of organisations that initially adopted microservices are now consolidating services back into larger deployable units. None of this means distributed architecture is wrong; it means the costs are real and should be weighed against the benefits for each specific situation.

There is also a sustainability dimension that deserves direct attention. Running two applications, two deployment pipelines, and two hosting environments consumes more energy than running one well-optimised system. Every additional build process, every redundant server, and every duplicated CI/CD pipeline adds to an organisation’s digital carbon footprint. For organisations with procurement sustainability criteria, or those publishing environmental commitments alongside their annual reports, this is not a marginal concern. It is a measurable difference in infrastructure impact. As with cost, this does not rule out headless where the use case justifies it, but it is a trade-off that belongs in the decision, not an afterthought.

Start simple, extend when the need is real

If there is one strategic message in this article, it is this: you do not have to choose maximum complexity upfront to keep your options open.

A platform like Wagtail operates across the full spectrum from headful to fully headless. It renders your primary website through Django templates, with full editorial preview, live editing, and all the benefits of an integrated CMS. At the same time, it exposes the same content via REST and GraphQL APIs, ready for any channel that needs it. This means you can start headful and introduce decoupled delivery for specific channels, a mobile app, a partner integration, an in-store display, when a use case materialises. You do not need to re-platform to do it.

A modern open-source CMS platform like Wagtail or Drupal operates across the full spectrum from headful to fully headless. The CMS platform can take care of rendering your content, with full editorial preview, live editing, and all the benefits of an integrated CMS. At the same time, it exposes the same content via APIs, ready for any channel that needs it. This means you can start headful and introduce decoupled delivery for specific channels, a mobile app, a partner integration, digital signage within a building etc when a use case materialises. You do not need to re-platform to do it.

This is not about deferring ambition. It is about proportionate architecture that can grow with you. Build API-first thinking into your content model from day one, structure your content for reuse, and you will be ready to extend into headless delivery without having paid the operational overhead of running two systems from the start. When Torchbox built Nesta's website on Wagtail, for example, the content model was designed from the outset to support both the main website and Nesta's in-house data science team, who use Python to produce interactive data visualisations integrated directly into the site. The architecture was headful, but API-ready, meaning that when new channels or integrations are needed in the future, the foundation is already there with no re-platforming required.

The question that actually matters

Rather than “which is more modern?”, decision makers should ask: “which approach lets us move faster, learn more, and deliver greater impact for the people we serve?”

For some organisations, the answer will be headless, and rightly so. The team has the skills, the channels demand it, and the security model requires it. When that is the case, headless is not an indulgence; it is the architecture that lets the organisation move fastest and deliver most effectively.

For most others, particularly charities, non-profits, and public sector organisations where Torchbox has its deepest expertise, the best architecture is often the simplest one that meets the actual requirements, with the ability to extend via APIs when needs arise. These are organisations where the real value of a replatform lies not in the architecture diagram but in what the team can do with the platform once it is built: measuring reach, improving user journeys, testing what works, and continuously optimising a website that serves its users and advances the organisation’s mission.

Either way, you do not have to bet everything on one approach from day one. Start with the architecture that fits your current reality, design your content model for flexibility, and extend when the need is real. That is the approach that keeps the most options open while delivering value from the start.

In the end, the best CMS architecture is the one that fits your organisation, your team and your long-term goals and it is often in a discovery phase where you figure out which is right for your context but if you are weighing up headless and headful and want a clearer view of the trade-offs, we would be happy to talk it through with you.