Should a Drupal site go headless with Drupal or move to another CMS?

What does going headless with Drupal involve?

Going headless with Drupal means running two systems: Drupal stays as the back end that stores and serves content, and you build and host a separate JavaScript front end that renders it.

• The Drupal half. It keeps Drupal's release cadence, a new major version every two years, in even years (Drupal.org release process, October 2026). Whether to upgrade Drupal 10 or leave Drupal is a decision of its own.
• The front-end half. It is a new JavaScript codebase with its own hosting, framework upgrades and developers, so the headless stack costs more to staff than a coupled Drupal site.
• The editors. They keep working in Drupal's back office, and the front end fetches their content through Drupal's application programming interface (API).

Whether any organization should go headless is the headless versus traditional content management system (CMS) question; the choice here starts once a Drupal team has settled on a decoupled front end.

How does a headless Drupal back end serve content to the front end?

A headless Drupal back end serves content through Drupal core's JSON:API module or a contributed GraphQL module, each an application programming interface (API), and a front-end toolkit such as Next.js for Drupal reads it. Four pieces do the work, as of October 2026:

• JSON:API, in core. Drupal.org calls it "zero-configuration required" and opinionated, and it handles create, read, update and delete (CRUD) operations on a site's content (Drupal.org, JSON:API module, October 2026). Business rules such as account creation and login are not part of it.
• GraphQL, contributed. The GraphQL module lets you "craft and expose a GraphQL schema for Drupal 10 and 11" (Drupal.org, GraphQL, October 2026).
• JSON:API Views. It creates a JSON:API resource for each Views display, so existing listings reach the front end (Drupal.org, JSON:API Views, October 2026).
• Next.js for Drupal. A Kanopi Studios project listed on drupal.org that works with Drupal 10 and 11, previews drafts and revisions in an iframe, and offers multi-site preview for "write once, publish everywhere" (Drupal.org, Next.js, October 2026).

Next.js for Drupal is a Kanopi Studios project, not a Drupal Association or Vercel product; the Sanity and Next.js integration is Sanity's own toolkit for the same job.

What do you keep, and what do you rebuild, when Drupal goes headless?

Headless Drupal keeps the back office and rebuilds everything a visitor sees, which the front end fetches through Drupal's application programming interface (API). Our view of Drupal rests on its documentation and public sources, so kept rows rest on drupal.org and the Next.js for Drupal guides, and rebuilt rows are Deploi's judgment.

Each kept integration needs an extra module: Webform REST (representational state transfer) for forms and JSON:API Search API for search (Next.js for Drupal, Webform; Search API, October 2026).

When is a new CMS a better move than headless Drupal?

A new content management system (CMS) beats headless Drupal when the Drupal back office isn't the reason you stay: on Drupal 7, when content must serve several channels, or when nobody wants to run PHP beside JavaScript. Drupal 7 is the clearest case: drupal.org says "an update can't simply be applied to an existing Drupal 6/7 site", content migrates into a new site, and the theme must be rebuilt (Drupal.org migration overview, October 2026). A headless Drupal 11 build is a rebuild either way, so the back end is open.

• Content serves several channels. Drupal stores rich text as HTML; Sanity stores it as Portable Text, a JSON rich text format that apps and other sites render without parsing HTML (Sanity's Drupal guide, October 2026).
• One language for the whole stack. Headless Drupal keeps a PHP back end beside a JavaScript front end. Sanity hosts the content store, and Sanity Studio is an open-source React application (Sanity Docs, Hosting and deployment, October 2026), so one JavaScript team covers both halves.
• Editors want to work together. Sanity's guide says Studio gives "real-time collaborative editing out of the box" (Sanity's Drupal guide, October 2026).

The Drupal to Sanity playbook covers the move itself.

Which options belong on the shortlist for a Drupal site going headless?

Four options belong on the shortlist: Drupal 11 coupled, headless Drupal 11, Sanity and Strapi Community. Each wins one condition, shown in the fit row. Every cell except the fit row, which is Deploi's judgment, rests on vendor pages read 24 October 2026. The two Drupal columns share a back end and differ only in who renders pages. Sanity and Strapi both replace the back end, and differ on who hosts the database: Sanity hosts it, and Strapi runs on yours. Read the fit row first, because it decides.

What does each option cost to license and to keep current?

Drupal and Strapi Community charge no license fees, Sanity charges per seat on its paid plans, and every option except Sanity leaves back-end upgrades to you. Drupal core has no license fees and is distributed under the General Public License (GPL) (Drupal.org, About, October 2026). Strapi Community is free under the permissive MIT (Massachusetts Institute of Technology) License, which covers its Community Edition code outside the ee/ directory (Strapi pricing; Strapi license, October 2026). Sanity's Free plan is $0 and Growth is $15 per seat a month, billed monthly, as of October 2026 (Sanity pricing; Sanity for Startups, October 2026).

Which shortlisted options give editors per-content-type permissions and moderation?

Drupal gives editors per-content-type permissions and a moderation workflow in core, Strapi Community gives the permissions free but not the workflow, and Sanity reserves custom roles for its Enterprise plan, as of October 2026. Drupal's user guide lists node permissions per content type, such as "Recipe: Create new content" (Drupal.org user guide, October 2026). Strapi's role-based access control is a "Free feature" with create, read, update, delete and publish rights for each content type, while Review Workflows is an Enterprise feature (Strapi Docs, role-based access control; Strapi pricing, October 2026). Sanity's Growth plan gives five fixed roles that reach every dataset, so none stops at a content type (Sanity Docs, Roles; Sanity pricing, October 2026).

Roles and permissions in Sanity explains what the five fixed roles can and cannot do.

Where is Sanity not the pick for a Drupal team?

Sanity is not the pick for a Drupal team going headless when policy requires a self-hosted content database, when editors need per-content-type permissions without an Enterprise budget, or when nobody will own a JavaScript codebase. Sanity hosts the Content Lake, and only Sanity Studio can be self-hosted (Sanity's Drupal guide, October 2026; Sanity Docs, Studio development, October 2026), so a self-hosting rule takes Sanity off the list before features matter.

For a feature-by-feature view, see Sanity against Drupal, row by row, Sanity against Strapi, and whether to pick an open-source or a hosted headless content management system (CMS).