Headless commerce is the default conversation in retail platform procurement at the moment. The great majority of projects I scope, in 2026 as in 2025, begin with some variation of “we want to go headless” — a phrase repeated with sufficient regularity that it has acquired the status of an unexamined assumption rather than a considered architectural decision. Sometimes the assumption is correct. Often, it is not. This post is an attempt to articulate the cases in which it is not, and to make a defence of an architecture — Umbraco running on .NET — that has fallen somewhat out of fashion despite remaining, on the merits, the right answer for a substantial fraction of the businesses I work with.
What headless gets you, when it gets you anything
The headless commerce thesis is, in its strongest form, a compelling one. By separating the content management layer from the presentation layer via a stable API contract, the architecture permits each layer to evolve independently; the front end can be rebuilt without touching the CMS, the CMS can be replaced without rebuilding the front end, and best-of-breed services for search, personalisation, recommendations and checkout can be composed together rather than constrained to whatever the monolith ships with. For a high-velocity team that ships ten experiments a month, this freedom is genuinely valuable; for a brand whose competitive position depends on a faster experimentation cadence than its competitors, the architecture can be the difference between shipping the experiment and not shipping it.
The headless thesis works particularly well in three identifiable circumstances. The first is where the brand operates across multiple presentation channels — web, native mobile applications, in-store kiosks, voice assistants — and requires a single content source to serve all of them. The second is where the engineering team is sufficiently large and sufficiently mature to absorb the additional architectural complexity that headless introduces, and to maintain the integration layer that headless requires. The third is where the brand’s product offering is unusual enough that the off-the-shelf storefronts shipped by traditional CMSes do not fit it without significant customisation; under those conditions, the customisation work required to fit a traditional CMS to the brand’s needs may exceed the integration work required to compose a headless stack from scratch.
For the brands that fall into one or more of these three circumstances, headless is generally the correct answer; my objection is not to headless commerce as such but to the proposition that headless commerce is the correct answer for every brand initiating a replatforming project, which is the proposition increasingly being advanced in the procurement conversations I am part of.
What headless costs you, which is rarely accounted for
Every headless project I have shipped has had the same conversation, at approximately the same point in the project’s lifecycle, with the same operational unease in the room. The conversation occurs around month four, after the editorial team has spent some weeks attempting to use the new system to update product pages, blog posts and category descriptions, and it consists of some variation of the question: “why can it not just drag the image into the page like the old system did?” The question is not, as it is sometimes received by engineering teams, a complaint born of unfamiliarity with the new tooling; it is a substantive observation about the loss of editorial flexibility that headless architectures, in their pursuit of separation of concerns, frequently introduce.
The traditional CMS — Umbraco, WordPress, Sitecore in its monolithic form, the older versions of Adobe Experience Manager — was built around the assumption that the editor and the page were closely coupled. The editor sees the page; the editor edits the page; the page reflects the edit immediately. The headless CMS, by contrast, is built around the assumption that the editor edits a content object, and the rendering of that object onto a page is the responsibility of a separate front-end application that the editor cannot directly inspect. This is, in architectural terms, a clean separation; in editorial terms, it is a substantial regression.
The headless community has spent some years closing the gap between the two paradigms via visual editing tools, live preview integrations, and component-level content schemas; the gap has, in the most recent generation of products, narrowed considerably. It has not, in my observation, closed. For an editor whose mental model of the website is page-based — that is, for the great majority of editors at the businesses I work with — the headless paradigm requires a substantial and ongoing cognitive cost. The cost is paid not in a single training session at launch but in every subsequent edit, in every new editor onboarded, and in every cross-functional conversation in which someone other than the editor needs to understand how the website’s content is structured.
The Umbraco case in particular
Umbraco occupies a position in the CMS market that is, in 2026, somewhat unfashionable but commercially robust. The platform has, since its inception, prioritised editor experience above almost every other consideration; the page tree is the canonical organising metaphor; the property editors are designed to feel familiar to editors with no engineering background; the content workflow tools are mature, reliable and built around the assumption that content moves through identifiable approval states rather than existing as undifferentiated objects in a database.
The platform’s principal disadvantages, relative to its more fashionable competitors, are real and worth acknowledging. Umbraco does not, out of the box, expose its content via a stable headless API in the way that Contentful or Sanity do; the .NET hosting requirement is more constrained than the Node-based alternatives that dominate the contemporary front-end ecosystem; the developer community is smaller than the WordPress community by approximately an order of magnitude, with corresponding implications for the availability of plugins, agency expertise and reference documentation.
None of these disadvantages are, in my experience, decisive for the kind of business I am addressing — the mid-market UK retailer with a catalogue in the low thousands of SKUs, an editorial team of fewer than ten people, and a content cadence dominated by category-page updates and blog posts rather than by twenty parallel A/B tests. For such a business, the editor-first design of Umbraco is a feature rather than a bug; the constrained hosting requirements are an acceptable cost for the operational maturity that comes with .NET; the smaller community is offset by the higher quality, on average, of the agencies that specialise in Umbraco delivery.
The middle path that most projects ought to be choosing
The architectural pattern that I have ended up recommending, more or less by default, for the brands that do not fall into the three identifiable headless-suitable circumstances above, is what I would describe as a thin headless veneer over a traditional CMS core. The CMS — Umbraco, in the .NET-flavoured version of the recommendation, or WordPress in the PHP-flavoured version — handles the page tree, the editorial workflow, the marketing pages, the blog, the category descriptions, the navigation, and the great majority of the content that the editorial team interacts with on a day-to-day basis. The headless services — search, recommendations, configurator, occasionally checkout — are composed alongside the CMS as separate services, exposed to the front end via API contracts, and integrated into the page templates rendered by the CMS.
This pattern preserves the editorial experience that traditional CMSes are good at, while permitting the brand to compose best-of-breed services for the parts of the experience that the traditional CMS is bad at. It does not provide all of the architectural benefits that a fully headless stack would; it provides considerably more of those benefits than the editorial team would lose if the CMS were replaced wholesale, which is the trade-off that the brands I work with have, almost without exception, preferred when the trade-off has been articulated clearly.
The pattern’s principal limitation is that it constrains the velocity of front-end experimentation; for brands whose competitive position depends on shipping front-end experiments faster than the page-template architecture permits, the constraint is a binding one and the headless thesis re-emerges as the correct answer. For most of the brands that initiate the procurement conversation with the assumption that they are such a brand, the assumption is, on closer inspection, an inherited piece of vendor marketing rather than a substantive observation about the brand’s own competitive position.
An advisory close
It would be apt to say, in summary, that the question of headless versus traditional CMS architecture is rarely the question that the procurement conversation is treating it as. The substantive question is whether the editorial team’s working model is page-based or component-based, and whether the brand’s experimentation cadence is constrained by its current platform or by some other consideration. Where the editorial team is page-based and the experimentation cadence is not platform-constrained, Umbraco and .NET, in 2026 as in 2018, remain a sound recommendation; the architecture is not fashionable, but the brands using it are, on the whole, not paying a premium for fashion either. (For the related question of how this thinking applies to performance work specifically, see A Core Web Vitals diary: what actually moves the needle.)