Senior Product Marketing Manager, Drupal Acquia
Collection
What Your CMS Was Doing All Along: The Hidden Costs of Going Headless
Collection :
Then the first post-launch campaign arrives. A marketer needs a new landing page layout, and the request goes into the engineering backlog. An SEO audit turns up a batch of old URLs that now return 404 errors. Someone fixes a typo, and the change takes an hour to appear because the whole site has to rebuild.
None of these are edge cases. They happen because a traditional CMS quietly handles a long list of jobs: building pages, managing URLs and redirects, keeping caches fresh, processing forms, and deciding who sees what. Going headless does not remove that work. It moves it across a network boundary and onto your team.
We think headless is often the right call. But teams should go in knowing what they are taking on.
Where headless migrations get into trouble
Editors lose the ability to see their work
In a traditional CMS, an editor can preview a draft in place, drag a component into a new spot, and check how a headline wraps on a phone before publishing.
Many headless setups replace that with a set of form fields that feed an API. Previewing an unpublished draft now depends on custom middleware, authentication tokens, and a separate preview server. Page layouts live in frontend code, so every new arrangement needs a developer and a deployment. Campaigns slow down, and the frontend team becomes the bottleneck nobody planned for.
URLs and redirects split in two
A coupled CMS owns its URLs. Change a page path, and it creates the redirect for you.
In a decoupled stack, the CMS keeps the content hierarchy while the frontend app runs its own router. The frontend has to ask the backend which content lives at which URL, and it frequently has no idea that a redirect exists. After a site restructure, that gap shows up as broken links and lost search rankings. Sites that rely on client-side rendering take on extra indexing risk as well.
Performance can get worse
A single page might need body copy, images, an author bio, related articles, and a navigation menu. If the frontend fetches each of those with its own API call, the page sits waiting on a chain of requests.
Edge caching helps until content changes. Then the question becomes which cached pages to clear. Without a precise answer, teams either rebuild the whole site on every save or set short cache lifetimes and live with stale pages and traffic spikes on the backend.
SaaS pricing tracks your growth
Proprietary headless platforms take hosting off your plate, which is a real benefit early on. Growth exposes the limits. Plans often cap content types, languages, or user roles. Usage-based pricing can count every preview and cache refresh as a billable request. Approval workflows and detailed permissions tend to sit in the top tier.
Forms and operations become custom builds
A contact form looks simple. Separate it from the CMS, though, and your team has to rebuild validation, spam protection, file handling, and email notifications.
You also now run two applications with two hosting environments and two deployment pipelines. Rename a field in the CMS without updating the frontend, and pages break. Backend and frontend developers can end up spending their time negotiating API contracts instead of shipping features.
How Drupal handles the hard parts
Drupal is an open source, API-first CMS, and the Drupal community has spent years working through these exact problems. That work is available to any team that builds on it:
Integrations such as Next.js for Drupal let editors preview unpublished drafts from inside the CMS. Drupal Canvas adds visual page building with components from your design system, so a new layout does not have to wait for a code release.
Drupal can tell a frontend app which content belongs at a given URL, and whether that URL now redirects. Editors keep managing paths in one place, and search engines get the correct response.
Drupal records which pages use which content. When an article changes, it can tell the frontend to refresh only the pages that include it.
JSON:API ships with Drupal core. Developers request only the fields a component needs and pull related content in the same call. GraphQL is available for teams that have standardized on it.
Content moderation, custom workflows, revisions, and field-level permissions are built in. Because Drupal is open source, there is no license tier that limits your content types, roles, or languages.
Drupal Webform can share form definitions with a decoupled frontend while Drupal handles validation, spam filtering, storage, and CRM integrations on the server.
Drupal also lets you choose how far to decouple. Some teams go fully headless to power apps and multiple channels. Others keep Drupal rendering most pages and embed JavaScript components where they need rich interactivity. Plenty of organizations run a hybrid, with coupled marketing pages and APIs for everything else.
Start with SaaS, keep the option to go further
Most teams want two things that usually pull against each other. They want to launch without standing up infrastructure, and they want the freedom to take the site anywhere later. Proprietary SaaS covers the first. Open source covers the second.
Acquia Source CMS gives you both. It is a SaaS CMS with integrated AI, built on Drupal and part of Acquia Source. Your team can build pages from a prompt or with drag-and-drop tools, and Acquia handles hosting, security, and updates. Editors get visual page building from the start.
The difference shows up later. Say your team needs a custom integration, a specialized content model, or a decoupled frontend. With a proprietary platform, that can mean a migration project. With Source CMS, you export the site to a standard Drupal application and keep building with full code-level control. Your content, structure, and editorial workflows come with you. You can run the exported site on Acquia Cloud Platform, the managed hosting environment built for enterprise Drupal.
That path does not lock you in. You start small, and you can move to a full open source architecture once your needs call for it.
Questions to ask before you decouple
Do we need it? Decoupling pays off when one content hub feeds several channels, or when you have a JavaScript team ready to run its own release cycle. If the goal is a faster website, a well-tuned Drupal site with modern components and edge caching may get you there with much less overhead.
How will editors preview and build pages? Design this into the architecture from day one. Retrofitting it after launch costs more.
Where do URLs and redirects live? The CMS should stay the single source of truth, and the frontend should respect it.
How will caches stay current? Plan for targeted refreshes rather than full rebuilds or short cache lifetimes.
What happens when we outgrow the platform? Choose a path that does not end in a replatform.
A headless architecture can deliver what it promises. Make sure you know which jobs your CMS was doing before you take them away from it.
