When headless CMS architecture creates more risk than value

The build had been costed. A Next.js baseline was already in place. On paper, a headless Umbraco architecture looked like the progressive and defensible choice. Then the project team tested the proposed architecture against what the organisation expected the platform to do next.

That changed the conversation. The issue was no longer whether the technology could work, but whether it would make personalisation, experimentation and everyday operation unnecessarily difficult when those requirements moved from roadmap to reality.

A choice between different kinds of complexity

Headless architecture separates the content management system from the presentation layer. In this case, Umbraco would manage and deliver the content while a separate Next.js application rendered the public experience. The model offered real advantages: flexible caching, independent front-end releases and a site that could continue serving cached pages if the CMS became unavailable.

But separation does not remove complexity. It moves it into the joins between systems. Two applications can mean separate hosting environments, deployment pipelines, monitoring layers, software dependencies and upgrade paths. Preview, caching, security and incident ownership must also be designed across the two systems.

That overhead is justified when content must serve several channels, front ends need independent release cycles or the experience behaves more like a digital product than a website. This project centred on one principal website, while its future roadmap relied on capabilities closely tied to the CMS. The value of a fully headless architecture was therefore less clear.

The roadmap changed the risk

Analytics, A/B testing, audience segmentation and personalised experiences through Umbraco Engage were not required for launch. They were, however, part of the stated direction of travel. Once those ambitions entered the discussion, an architecture selected against the immediate brief began to carry the possibility of later rework, additional custom development and greater dependence on technical teams.

The product picture is not binary. Umbraco's Engage Headless package supports personalised content, A/B testing and segmentation through its Content Delivery API, but some Engage features are not supported in headless implementations. The required capabilities, Umbraco version, hosting model and implementation effort must therefore be verified before the architecture hardens into a costly assumption.

Product support also changes over time.

A limitation remembered from an earlier release may have been resolved; a capability described in broad terms may still carry important exceptions. In either case, architecture cannot be responsibly decided from reputation, habit or an outdated proof of concept.

Performance does not settle the argument

Next.js can deliver strong performance through caching, prerendering and client-side navigation. But headless is not inherently faster: an inefficient API, database query or thirdparty integration remains a bottleneck wherever the page is rendered.

As Bluegrass Digital technical director Simon Buerger observed, caching can reduce the pressure while hiding the underlying problem until traffic rises. “Anything you miss compounds when you have traffic,” he said. “Caching can help, but it can also hide the issue.”

A well-engineered server-rendered CMS can also perform strongly. Security offers no simpler verdict: decoupling can reduce direct exposure of the CMS, while a conventional build can keep credentials and integration logic on the server. In either case, disciplined implementation matters more than the architectural label.

The cost appears after launch

The build estimate captures only part of the cost. A headless CMS can add another runtime, hosting environment, deployment surface and security process, along with the need for people able to work across the CMS, API and front-end stack. That investment is justified only when the separation creates enough value to sustain it after launch.

None of this makes headless inherently wasteful, just as keeping presentation inside the CMS does not automatically make a platform simpler or cheaper. The calculation depends on what the separation enables, who will maintain it and whether the organisation’s governance and skills can support it long after the implementation team has left.

The less fashionable recommendation

The team ultimately recommended a conventional Umbraco architecture. It was not a retreat from modern development. Interactive search, filtering and other focused experiences could still use APIs and JavaScript without forcing the entire platform into a decoupled model.

The more significant decision was to resist treating architectural separation as evidence of digital maturity. In this project, cohesion offered more value: one operational stack, closer alignment with the planned marketing capabilities and fewer layers to govern.

The useful distinction is not between headless and traditional, or modern and old. It is between complexity that creates measurable value and complexity adopted because it signals progress.

The right CMS architecture is the one the organisation can use, evolve and govern without paying indefinitely for separation it does not need.

About Bluegrass Digital

Bluegrass Digital is a digital product and technology partner that helps organisations design, build and evolve digital experiences and platforms. With more than 17 years of experience and recognition as an Umbraco Gold Partner, Bluegrass combines deep CMS expertise with capabilities across digital strategy, web development, mobile applications and ongoing platform support. The team works with organisations to select, implement and evolve technology that meets their business needs, balancing technical capability with performance, scalability, maintainability and long-term value.
www.bluegrassdigital.com