Need a partner to implement or migrate?
This page helps you decide between decoupling Drupal and replatforming. If you want a senior team to plan and run the move, with content, URLs, and SEO handled deliberately, see our website migration services.
What headless Drupal is, and why you’re probably here
Drupal is the open-source CMS with the most serious structured-content pedigree of its generation. Entities, fields, views, and granular permissions made it the default for governments, universities, and large organizations with complex publishing needs. Used headlessly (“decoupled,” in Drupal vocabulary), it keeps that backend and serves content to a modern front end over JSON:API or GraphQL, so editors keep their workflows while visitors get a fast, modern site.
Most visitors to a page like this are here because of a date: Drupal 7 is past end of life, and estates that deferred the question for years now face a migration-sized project no matter what they choose. Even the move from D7 to modern Drupal is a rebuild, not an upgrade: content model, theme, and custom modules all have to be redone, which reopens the platform decision entirely. That’s the honest framing this page uses.
Where decoupled Drupal holds up
Decoupling means keeping Drupal as the content backend and putting a modern front end over JSON:API or GraphQL. It’s a legitimate path when three things are true: the install is already on a modern Drupal version (or the organization is committed to getting there), the content model is genuinely complex and well built (Drupal’s entity system remains excellent at this), and there is Drupal capacity in-house or a trusted long-term partner. Government and university teams with deep workflow, permission, and accessibility requirements often land here, because the backend is doing real work that would be expensive to rebuild elsewhere.
Why teams replatform instead
- Drupal 7 end of life. The migration to modern Drupal is a rebuild anyway, so the “cheap” option doesn’t exist. Once rebuild money is on the table, the destination is an open question.
- Module debt. Years of contributed and custom modules encode business logic nobody fully owns, and each major version cycle repeats the pain.
- Operational surface. A PHP application, its hosting, and its security-update treadmill remain even after decoupling. The front end modernizes; the operational burden doesn’t.
- Specialist dependence. Strong Drupal developers are a shrinking, senior, expensive pool compared with the mainstream React and headless talent market.
Decouple or replatform?
| Choose decoupled Drupal when | Replatform when |
|---|---|
 You're already on modern Drupal, or committed to getting there |  You're on Drupal 7 and the upgrade is a rebuild anyway |
| The entity model and editorial workflows are genuinely load-bearing | The content model would come out cleaner rebuilt in an API-first CMS |
| You have Drupal capacity in-house or a trusted long-term partner | Every change already waits on a shrinking pool of specialists |
| Compliance or procurement favors self-hosted open source | Retiring the PHP hosting and security-update treadmill is part of the point |
| Budget only stretches to a front-end modernization this cycle | Module debt makes every major version cycle a project of its own |
The realistic paths off Drupal 7
Decouple: keep Drupal as the backend. Migrate to modern Drupal, expose content over JSON:API or GraphQL, and build a modern front end. This preserves the entity model and editorial workflows your teams rely on, but the Drupal operational burden (hosting, updates, module maintenance) stays.
Replatform to composable. Move content into a headless CMS and a modern framework. Since Drupal 7 forces a rebuild anyway, this path puts the effort into the destination rather than the treadmill: it ends the major-version cycle and the specialist bottleneck. Content, URLs, and SEO equity have to be mapped and migrated deliberately. That work is the project, not a footnote.
Pricing, in plain terms
Drupal itself is license-free, so the cost lives in operations: hosting a PHP application, security updates, and module maintenance. The biggest line is senior specialist time, whether in-house or through an agency. Decoupling adds a front-end hosting bill without retiring any of those costs. Replatforming trades them for a headless CMS subscription (free developer tiers, mid tiers from roughly a few hundred dollars a month, custom pricing once SSO, roles, and audit requirements enter) plus modern front-end hosting. For most estates the decisive number isn’t a license on either path. It’s how much specialist time each option consumes per year, multiplied by how hard those specialists are to hire.
The Bejamas take
Drupal 7’s end of life is the rare forcing function that makes this decision honest: both paths cost rebuild money, so compare destinations, not effort. Decoupled Drupal is right when the entity model and workflows are genuinely load-bearing and Drupal capacity is secure. A composable replatform is right when module debt and the operational surface are the real estate you’re paying for. In an audit we map the content model, the module inventory, and the team’s capacity, model both paths, and recommend one honestly. Then, if it’s a migration, we plan and run it with the redirect map, content migration, and SEO controls treated as first-class work.