Drupal migrations & version upgrades

Why sites get stuck

Drupal 7 reached end of life, and a lot of sites are still on it. The usual blockers are the same: a pile of contributed modules with no equivalent in current Drupal, custom code written against APIs that no longer exist, and content structured in ways that made sense a decade ago.

The migration is rarely the hard part. The audit before it is.

How I approach it

Audit first. Every contributed module gets checked for a current-version equivalent. Some have direct replacements, some are now in core, some have no successor and the functionality needs rebuilding or dropping. That list decides whether the project is three weeks or three months, and it's worth knowing before anyone commits to a date.

Migrate content and configuration separately. Drupal's Migrate API handles the content. Configuration usually wants rebuilding rather than migrating — the old structure often encodes workarounds for limitations that no longer exist.

Treat redirects as a deliverable. This is where migrations quietly destroy value. A site with years of accumulated search rankings can lose most of them if old URLs return 404s. Every old URL needs mapping to its new equivalent, with 301 redirects in place at launch. It's unglamorous work and it protects more commercial value than anything else in the project.

Rehearse. Run the migration repeatedly against a copy until it's reproducible, then do the real one. A migration you've only run once is a migration you don't yet understand.

What this covers

• Drupal 7, 9 and 10 → Drupal 11 and 12
• Contributed and custom module audits before commitment
• Content, taxonomy, users, files and media migration
• Configuration rebuilds
• URL and redirect mapping
• Post-migration verification against the source site