Drupal 10 reaches end of life on December 9, 2026. If your company runs a large Drupal site, you are already planning a major-version project. That makes this the right moment to ask a bigger question: do we upgrade, or do we move?
For a growing number of enterprise teams, the answer is a headless content platform, and Sanity is one of the strongest options. But a migration is not automatically the right call, and a badly run one can cost you years of search traffic.
This post covers the short version: when a Drupal to Sanity migration makes sense, how Sanity works, and what the project involves for a site with 300+ pages in 8 languages. The full detail is in our free 64-page white paper.
Why teams leave Drupal
Drupal is a capable platform. The problem is what it costs to keep running at scale.
- The upgrade treadmill. Drupal ships a major version every two years. Each one means checking every contributed module, rewriting custom code, and updating PHP and hosting in step. Sites still on Drupal 7 have no upgrade path at all, only a rebuild.
- Module and custom-code debt. A typical enterprise site carries well over a hundred modules, plus custom code written by several agencies over a decade.
- Developer-dependent content. Routine changes to layouts and content types usually need a developer and a deployment.
- Hosting overhead. Someone has to own the servers, database, cache layers, and security patches.
- A shrinking talent pool. Senior Drupal developers are harder to find each year than React and TypeScript developers.
When you should stay on Drupal
We build Sanity sites, so take this section as the honest counterweight. Stay on Drupal, or upgrade to Drupal 11, if:
- You are already on Drupal 10 with clean custom code, and the upgrade is weeks of work.
- You depend on features Drupal bundles, such as user communities, complex gated content, or heavy transactional forms.
- Your data-residency rules prohibit storing content with a SaaS vendor.
- You have a strong Drupal team and no front-end engineering capacity.
- Your editors are productive and publishing speed is not holding the business back.
Sanity is a content backend, not a website. You still have to build the front end, search, and forms. And you trade hosting and upgrade costs for usage-based SaaS pricing, which can come out lower or higher depending on how well the site is engineered.
A simple rule: migrate when at least two of these are true. The next Drupal upgrade costs about as much as a rebuild. Editors wait on developers for routine changes. Translation speed is a business constraint. You need the same content in channels beyond the website.
How Sanity works
Sanity has two halves, and your website is a third, separate piece.
The Content Lake is the database. Sanity hosts it. Instead of relational tables, every piece of content is a JSON document: a page, a product, a press release, a person. Documents link to each other with references. Rich text is stored as structured data called Portable Text, not as HTML. You query it all with a language called GROQ.
Sanity Studio is the editor your team logs in to. It is a React app, and your content model is defined in code. That means a change to a content type goes through the same review and rollback process as any other code change.
Your website is a standard front-end app, usually Next.js, that reads from the Content Lake and serves pages from the edge.
| Drupal | Sanity |
|---|---|
| Content type | Document type, defined in code |
| Node | JSON document |
| Paragraphs | Array of section objects |
| Taxonomy term | Its own document, linked by reference |
| Body field (HTML) | Portable Text |
| Views | GROQ queries in the front end |
| Twig templates | React components |
How non-technical people update the site
This is where most teams feel the difference. Editors get two ways to work.
The Studio editor is a clean form built around your content. Fields are grouped, labeled, and validated as people type. Missing alt text or an overlong meta title blocks publishing before it reaches the live site. Several people can edit the same document at once, with comments and full revision history.
The visual editor, called the Presentation tool, shows the real website next to the form. An editor clicks a headline on the page, the right field opens, and the preview updates as they type. They can add and reorder page sections from an approved library, so pages stay on brand.
For launches, Content Releases bundle changes across many pages and languages, preview them together, and publish them on a schedule. A press release can go live in all 8 languages at 9:00 a.m. with one action.
How to migrate from Drupal to Sanity: seven steps
For a site of this size, plan on 6 to 9 months. That is a planning estimate, not a promise. A bundled redesign or a heavily customized Drupal 7 source will stretch it.
- Audit everything. Crawl every URL in every language, export the Drupal database, and pull 12 or more months of analytics and Search Console data. Expect to find far more than the 300 pages everyone quotes. Decide what to keep, merge, or retire.
- Model the content. Do not copy Drupal's paragraph types one for one. Model what things are (a product, a person, an office), not how they were laid out. This decision outlives the front end.
- Decide localization early. See the next section. Changing this later means rework across schema, queries, and migration scripts.
- Build the front end and the Studio. One React component per section type, visual editing on every template, and roles and validation set up for how your editors work.
- Script the migration. Extract from Drupal through JSON:API or the database, transform HTML into Portable Text, and load into a staging dataset. Scripts must be rerunnable, with predictable IDs, so you can run them dozens of times.
- Protect your SEO. Map a redirect for every legacy URL in every language. Match titles, descriptions, canonicals, structured data, and hreflang. Test the whole map automatically before launch.
- Launch in phases. Go live one market or one section at a time, keep Drupal running read-only for at least 30 days, and monitor rankings and errors daily.
The multi-language decision
Drupal has translation built into core. In Sanity, you choose a pattern.
- Document-level translation creates one document per language, linked together. Use it for pages and articles, where markets may need different content and independent publishing.
- Field-level translation keeps one document with a value per language in each field. Use it for short shared records such as product names and interface labels.
Most 8-language sites use both. You also need to build something Sanity does not give you by default: a signal that tells the French editor the English source changed.
Three mistakes that sink migrations
- Leaving redirects to the end. This is the most common cause of traffic loss. Start the redirect map during the audit.
- Underestimating rich text. A decade of WYSIWYG HTML is full of embedded media, tables, and one-off markup. Budget real engineering time for the converter.
- Bundling a redesign. It grows the scope and the SEO risk, and if traffic changes you will not know why.
Working on the site with the Sanity MCP server and Claude Code
Sanity runs an official MCP server that lets an AI coding agent such as Claude Code work directly with your project: read the schema, run queries, edit documents, and manage releases. Setup is one command:
npx sanity@latest mcp configure
In practice it turns slow audit and cleanup jobs into a prompt. For example:
In the staging dataset, find every published German and French page with an empty meta description. Output a CSV with ID, slug, and title.
It is also a write path into your content, so use guardrails. Point agents at a staging dataset by default. Send production changes into a Content Release that a person reviews and publishes. Never let an agent publish translations, legal text, or product claims without qualified review.
Questions to ask your agency before code handoff
If an agency builds your migration, the handoff decides whether you own the result. A few of the questions we would ask:
- Do we own the Sanity project, the repositories, the hosting account, and DNS, all under our organization?
- Can you show counts reconciling Drupal to Sanity for every content type and language?
- Is there a tested redirect for every legacy URL in every language?
- How does an editor know a translation is out of date?
- Has a backup restore actually been tested?
- Can a new developer run the project locally in under an hour from the README?
The white paper includes the full checklist: 47 questions across ownership, migration integrity, localization, SEO, security, documentation, and costs.
Frequently asked questions
How long does a Drupal to Sanity migration take?
For an enterprise site with 300+ pages in 8 languages, plan on 6 to 9 months from discovery through launch. Smaller single-language sites move much faster.
Will migrating from Drupal to Sanity hurt our SEO?
It does not have to. Traffic loss almost always traces to missing redirects, changed URLs, or lost metadata. A complete redirect map, metadata parity, and a phased launch keep rankings stable.
Is Sanity better than Drupal?
Neither is better in the abstract. Drupal is a complete, open-source platform with multilingual support built in. Sanity is a hosted content backend with a stronger editing experience and no servers to patch. The right choice depends on your team and your constraints.
Can non-technical editors use Sanity?
Yes. Editors work in a form-based Studio or click directly on a live preview of the site to edit it. Most can handle routine changes on day one with role-based training.
Does Sanity support multiple languages?
Yes, through official plugins and a modeling choice between document-level and field-level translation. It takes more deliberate setup than Drupal's built-in translation, but it handles large multi-language sites well.
What is the Sanity MCP server?
It is a hosted service from Sanity that connects AI tools such as Claude Code to your Sanity project, so an agent can query content, edit documents, and manage releases with your permissions.
Get the full white paper
This post is the summary. The white paper goes deep on all of it: the business case, the content model, localization for 8 languages, migration scripts, the cutover runbook, sample schemas and queries, and the complete agency handoff checklist.
RAWR is a web design, development, and AI studio in Plano, Texas. We build Sanity websites with Next.js front ends for teams that need structured content and multiple languages. If you are weighing a move off Drupal, get a free audit and we will tell you plainly whether a migration makes sense.
