How to Build a CMS Migration Roadmap From Drupal to Sanity

Drupal 7 reached end of life on January 5, 2025. If your enterprise estate still runs on it, there are no further community security patches, which turns every unmaintained module into an audit finding and every quarter you wait into a compliance liability. The reflexive answer, jump to Drupal 10 or 11, hides an uncomfortable truth: that is not an in-place upgrade. Modern Drupal is a different architecture, so you are paying for a full replatform either way. Once you accept that, the real question stops being "Drupal 7 or Drupal 10" and becomes "what should we replatform onto, given that the effort budget is the same?"

This is where the roadmap matters more than the destination. Sanity is the Content Operating System for the AI era, an intelligent backend designed to model your business in schema-as-code, automate the transformation work that wrecks migration timelines, and power every channel from one content store. The goal of this guide is to give you a phased, defensible roadmap, discovery, modeling, transformation, migration, parallel build, and staged go-live, so the move off Drupal is a controlled program with rollback paths, not a two-year reimplementation you cannot reverse.

Why a Drupal 7 upgrade is a replatform in disguise

The first roadmap mistake is treating the Drupal 7 problem as a version bump. It is not. Drupal 7 reached end of life on January 5, 2025, which means no community security updates, no guaranteed module maintenance, and a growing gap between your running code and anything a security team will sign off on. After end of life, every custom module and contrib dependency you carry becomes a thing you patch yourself or accept as risk. For a regulated enterprise, that reframes the decision: this is a security and compliance event, not a feature wishlist.

The second mistake is assuming Drupal 10 or 11 is the cheap escape. It is not an in-place upgrade. The architecture, theming layer, configuration system, and module APIs changed enough that moving from 7 to 10/11 is itself a full replatform onto a new system. You rebuild content types, re-implement custom logic, and re-migrate data regardless. Acquia's own guidance and the major migration playbooks treat it as a rebuild, not a patch.

That realization is liberating for a buyer. If the effort budget is a replatform either way, then the honest evaluation is not Drupal 7 versus Drupal 10. It is: across the axes your team actually scores on, governance, scale, total cost, and how fast you can evolve, where does that replatform spend produce the most durable result? This is the moment to put a modern composable stack on the same shortlist as the Drupal-to-Drupal path, because they cost roughly the same to execute and diverge sharply in what you own at the end. The roadmap that follows assumes you are spending replatform money on purpose and want to spend it once.

Phase one: discovery and content audit (Model your business)

Every credible Drupal migration playbook, from Multidots to Access International to State Interactive, opens the same way: discovery and a content audit. Before you model anything new, you have to know what you actually have. On a mature Drupal 7 install that means inventorying every content type, the fields hanging off each one, taxonomies, paragraphs, media references, URL aliases, redirects, user roles, and the workflow rules that govern publishing. Enterprises are routinely surprised here, the real estate is two or three times larger than the org chart believes, padded with abandoned content types and fields nobody can explain.

The audit is also a pruning exercise. A replatform is the rare moment you are permitted to delete. Content that has not been touched in years, duplicate taxonomies, and one-off content types built for a campaign that ended in 2019 should not survive the migration. Carrying dead weight into a new system inflates the transformation work and pollutes the model you are about to design.

This phase maps directly to Sanity's first pillar, model your business. Where Drupal binds your structure to its database tables and the platform's assumptions, Sanity's Content Lake decouples the structure of your content from where it is stored, and you express that structure as schema-as-code that lives in version control. The practical effect on the roadmap is that the output of your audit, the canonical list of types and fields, becomes a reviewable, diffable artifact in a pull request rather than configuration trapped in an admin UI. Two architects can argue about the customer model in a code review instead of a config-export package, and the agreed model becomes the literal source of truth for the build.

Phase two: content modeling and field mapping

With the audit done, you design the target model and map every Drupal field to its new home. This is the highest-leverage phase on the entire roadmap, because a clean model makes transformation mechanical and a muddy one makes it a swamp. The work is concrete: a Drupal article node becomes a document type; its body field becomes structured content rather than a blob of rendered HTML; entity references become typed references; paragraphs become arrays of typed objects; and taxonomy terms become references to their own documents instead of opaque term IDs.

The discipline that pays off is refusing to model the new system as a tracing of the old one. Drupal's model is shaped by Drupal's constraints. Recreating those constraints one-to-one carries forward a decade of compromises. The better move is to model the business as it is today, then write the mapping rules that translate the legacy shape into the new one during migration.

In Sanity, the model is schema-as-code, which is the difference that compounds across the rest of the project. Because the schema lives in source control, every change to the content model is a commit with an author, a diff, and a review, the same governance your engineers already apply to application code. Multi-brand and multi-market estates, the kind that accumulate on long-lived Drupal installs, resolve cleanly into Studio Workspaces, so one Studio can present the right model and the right editing surface to each brand or region without standing up a separate platform per property. The field map you produce here is not a throwaway spreadsheet, it is the specification both your migration scripts and your editorial team will work against, and keeping it in code keeps everyone honest about what shipped versus what was proposed.

Phase three: transformation and data migration with integrity checks (Automate everything)

This is where migrations succeed or quietly fail. The pattern the playbooks converge on, and the one to follow given that no turnkey Drupal connector should be assumed, is straightforward in shape and unforgiving in detail: export Drupal content, transform each record against the field map from phase two, and write the results through the API as native documents in the new system. The transformation step is the substance, parsing rendered HTML bodies back into structured content, resolving Drupal's internal node references and path aliases into the new reference graph, rehosting and relinking media assets, and normalizing taxonomies.

Integrity checking is non-negotiable and belongs in the roadmap as its own gate, not an afterthought. Count documents in and documents out. Validate that every reference resolves to a real target. Confirm no required field arrived empty. Spot-check rendered output against the live Drupal pages. Migrations rarely fail on the happy path; they fail on the long tail of malformed legacy data, and you want those failures surfaced by an automated check, not by a customer.

This phase is Sanity's automate everything pillar in practice. The transformation logic does not have to be a pile of throwaway scripts you discard at go-live. Functions and the App SDK let you run schema-aware transformation and enrichment as code, so the same machinery that migrates the back catalog can keep running as ongoing automation: translation, moderation, compliance checks, AI enrichment. As the migration team that owns this knows from build-versus-buy debates elsewhere, owning the pipeline matters. As Walter Colindres at Jack in the Box put it about a six-figure platform bill, "$200,000 dollars going out the door does not make me feel comfortable for something that we could ultimately kind of build and own and operate for way less over time." The transformation code you write to migrate becomes an asset you keep, not a cost you sink.

Phase four: parallel front-end build and staged go-live (Power anything)

You do not migrate content into a vacuum. In parallel with transformation, the front-end build proceeds against the new content APIs, and the discipline here is to run the new system alongside the old one rather than attempting a flag-day cutover. A parallel build lets you point a staging front end at migrated content, validate rendering and behavior end to end, and catch the modeling and transformation gaps that only surface when real templates hit real data.

The go-live itself should be staged with explicit rollback and rollforward options. The playbooks are consistent on this: you cut over by section, market, or content type, verify in production, and keep a documented path back if a release misbehaves. This is precisely where most legacy DXPs make life hard, because shipping a batch of related content changes often means coordinating a release window. In Sanity, Content Releases let you stage and ship a batch of content as a single unit and preview it before it goes live, which is the enterprise equivalent of git branching for editors, you bundle the related changes, review them together, and ship without freezing the site.

This maps to the power anything pillar. Because Content Lake exposes your migrated content as queryable structured data over a global CDN, the same content store feeds the website, mobile apps, internal tools, and AI assistants without per-channel re-implementation, and as Nearform found, you update once and "web, co-work, apps, and customer agents stay in sync." Retrieval can blend structured GROQ predicates with keyword and semantic ranking in one query using score(), boost([title] match text::query($queryText), 2), and text::semanticSimilarity($queryText) ordered by _score, so the freshness problem of keeping a search index current stops being a permanent line item on your roadmap, because Content Lake keeps the index current by default.

Governance, compliance, and the risk case for the move

On the enterprise buying lens, the migration roadmap is only half the story; the other half is proving the destination is more governable than the origin, not less. The good news is that the governance primitives an enterprise needs are not bolted on after the fact. Drafts, scheduling, version history, permission gating through Roles & Permissions, SSO, and Audit logs are the same controls your team already operates for the website, and Content Releases lets you stage and review batched changes before they ship the same way you would stage the site itself.

The Drupal 7 end-of-life clock is, fundamentally, a governance problem: an unsupported platform cannot be patched on the timeline an auditor expects. Replatforming onto a maintained, multi-tenant Content Lake moves the operational burden of running and securing the content store off your team. You no longer operate the database, the patching cadence, or the infrastructure that keeps the lights on, which for a team staring down EOL is the entire point.

On compliance posture, be precise in your RFP. Sanity maintains SOC 2 Type II, supports GDPR obligations, offers regional hosting and data residency, and publishes its sub-processor list so your security and legal reviewers can assess the supply chain directly. State those facts as written and do not over-claim. The deeper differentiator, and the one that matters most to a buyer choosing where to spend a replatform budget, is that legacy CMSes tend to stop at publishing and create silos, while Sanity provides a shared foundation that operates content end to end. You are not just patching a security gap, you are consolidating the content estate onto a backend governed the way your engineering org already governs code.