Headless AEM is an architecture decision, not a feature toggle
I have seen the headless conversation play out the same way in multiple organisations. A development team wants to use a modern front-end framework. A product owner wants content available via API. A CMS vendor demonstrates headless capabilities. And suddenly, going headless is on the roadmap, without anyone having a serious conversation about what that actually means for AEM as a platform.
Headless AEM is not a feature you enable on a Tuesday afternoon. It is a fundamental architectural shift that changes how content is modelled, how authoring teams work, how the platform is governed, and how the total cost of ownership is calculated. Treating it as a toggle is how organisations end up with expensive hybrid messes that deliver neither the authoring experience of traditional AEM nor the flexibility of a genuinely headless architecture.
What changes when you go headless
Content modelling becomes the critical discipline. In traditional AEM, content structure is often implicit in the page and component design. Headless requires explicit content modelling: structured content fragments with clearly defined fields, relationships, and governance. Poor content models are painful in traditional AEM. In a headless architecture, they are catastrophic, because every consuming application depends on them.
The authoring experience must be deliberately designed. Authors lose the visual context that page-based authoring provides. They are editing structured content without seeing how it will be rendered. The content editor experience in headless AEM requires deliberate investment in tooling, in training, and in content governance processes. This is often underestimated in the headless business case.
Front-end and back-end governance must be separate and coordinated. Headless creates a clear separation between the content layer (AEM) and the presentation layer (whatever your front-end technology is). That separation is the point. But it also creates governance complexity: who is responsible for the content model? Who approves changes to the API schema? How do front-end teams signal that they need a content structure that does not yet exist?
When headless is the right answer
Headless AEM makes sense when you have multiple consuming channels (web, mobile, digital signage, third-party applications) that all need the same content delivered in structurally different ways. It makes sense when your front-end teams have strong opinions about their technology stack and those opinions have genuine merit. It makes sense when your content governance is mature enough to manage structured content without the visual scaffolding of a page-based editor.
It is not the right answer simply because it is the current architectural fashion. Evaluate it as an architecture decision: with a clear problem statement, a genuine alternative, and an honest assessment of the organisational readiness required to operate it well.