Drupal to Contentful Migration: A Grounded Case Study

Context

Migrations from Drupal to Contentful keep showing up in public write-ups for a consistent reason: teams reach a point where a monolithic, template-driven CMS no longer matches how they want to build and reuse content. As Contentful frames it in its own guidance, moving from Drupal to Contentful can be "a huge leap forward, especially for websites in need of an overhaul or upgrade" (Contentful blog). The draw is structured, decoupled content that can be delivered across multiple front ends rather than locked into one theme.

The publicly documented examples vary in scale but rhyme in shape. The Comic Relief engineering team described moving to a decoupled stack and migrating the majority of their content using contentful-migration, working with more than 3,000 pages and an initial build time of around ten minutes (Comic Relief on Medium). Sparkbox, meanwhile, documented a project where the migration itself expanded into a series of minimum viable products, because different stakeholders owned different content sections with different needs (Sparkbox case study).

The common starting point: a Drupal site rich in nodes, taxonomy, fields, and embedded media, and a goal to land all of it in Contentful's content-model paradigm without losing structure or breaking the live site.

What broke

The sources don't publish failure metrics, so we'll stay honest about what they actually surface — and it's instructive.

Content model mismatch is the core friction

Drupal and Contentful model content differently, and the gap is where most work hides. The Contentful Migration module on Drupal.org exists precisely to handle "the parts a YAML-only migration can't: Rich Text, embedded entries and assets, media, and cross-references." That list is effectively a warning label. Rich text, embedded entries, linked assets, and cross-references are exactly the elements that a naive field-to-field mapping mangles. A Drupal body field full of inline images, embedded nodes, and internal links does not map cleanly to a Contentful Rich Text field without deliberate transformation.

One model can't serve every stakeholder

Sparkbox's experience shows the organizational version of the same problem. They found they had to run a mini "discovery" on each content section because "we were dealing with different stakeholders and different needs." A single migration plan assumed uniformity that didn't exist. Sections that looked similar in Drupal turned out to need different models, workflows, and delivery once teams were consulted.

Scale turns small problems into slow ones

Comic Relief's note about a ~10-minute initial build time on 3,000+ pages is a reminder that volume changes the calculus. At that scale, every transformation edge case multiplies, and iteration cycles get expensive if you discover mapping errors late.

The signals the sources imply

Because these write-ups focus on content and architecture, they don't quantify SEO or redirect losses — so we won't invent numbers. But the risks are inherent to the pattern: Drupal's URL aliases, taxonomy-driven paths, and node IDs rarely survive a move to a headless model unless redirects and slugs are planned as first-class migration artifacts. Cross-references and embedded entries that break also break internal linking, which is an SEO and answer-engine (AEO) signal, not just a content nicety.

What worked

Three patterns recur across the grounded sources.

Scripted, repeatable migration. Comic Relief leaned on contentful-migration to move the bulk of content programmatically. A scripted approach makes the process re-runnable — critical when you'll discover model corrections and need to migrate again without hand-editing thousands of entries.

Purpose-built tooling for the hard parts. The Drupal.org module's focus on Rich Text, embedded entries, assets, media, and cross-references reflects where teams concentrate effort. These aren't afterthoughts; they're the substance of the migration.

Phased, MVP-driven delivery. Sparkbox "triaged sections and pages" and iterated through multiple MVPs rather than attempting a single big-bang cutover. Contentful's own planning guidance echoes this, emphasizing structured content models and phased migration strategies (Contentful planning guide). Phasing let teams learn from early sections and apply those lessons to later ones.

Lessons

• Model before you migrate. The mapping from Drupal fields to Contentful content types is the project. Design content types deliberately instead of mirroring Drupal's node structure one-to-one.
• Treat Rich Text as a migration risk, not a copy-paste. Embedded entries, inline assets, media, and internal links need explicit transformation logic — the reason dedicated tooling exists.
• Run discovery per content section. Sparkbox's mini-discoveries prevented a single assumed model from failing multiple stakeholder teams.
• Script migrations so they're repeatable. You will migrate more than once. Comic Relief's use of contentful-migration made iteration feasible at 3,000+ pages.
• Phase and triage. Ship MVPs by section; let early sections teach you before you touch the harder ones.
• Protect linking and URLs. Cross-references and internal links carry SEO/AEO weight. Plan redirects and slugs as deliverables, not cleanup.

Before you make this move

1. Inventory your Drupal content: node types, fields, taxonomy, URL aliases, and every place Rich Text embeds media or other nodes.
2. Draft the target Contentful content model and map each Drupal field to it explicitly — flag anything that doesn't map cleanly.
3. Interview the stakeholders who own each content section; don't assume one model fits all.
4. Prototype the Rich Text, embedded-entry, and asset transformation on a small sample before scaling.
5. Script the migration with contentful-migration or equivalent so it can be re-run as the model evolves.
6. Build a redirect map from old Drupal URLs to new paths, and validate internal links post-migration.
7. Sequence delivery into MVPs by section, and define what "done" means for each.

Auditing content models, taxonomy, and URL/link structure before cutover is exactly the pre-migration intelligence work Replatform Radar focuses on — because, as these public cases show, the expensive surprises live in the content model, not the CMS logo. The sources here are thin on metrics but consistent on shape: plan the model, script the move, phase the delivery, and guard your links.