If your site is still running Drupal 7, 8, or 9, the decision isn’t really “should we migrate” anymore — it’s “how do we migrate without breaking what already works.”
Drupal 7 is past end of life. Drupal 9 reached end of life in late 2023. Every month you stay on an unsupported version, you’re running a public website with no security patches. Here’s how a migration actually works, what it costs, and how to protect your rankings and data along the way.
Why Migrate Now Instead of Waiting?
Unsupported Drupal versions accumulate risk quietly. No new vulnerabilities get patched, hosting providers eventually stop supporting old PHP versions your Drupal instance depends on, and the pool of developers willing to touch a Drupal 7 codebase shrinks every year — which means emergency fixes get more expensive, not less.
Migrating on your own schedule, with a real testing window, is always cheaper than migrating after a security incident forces your hand.
What Actually Changes Between Drupal Versions?
Drupal 8 introduced a full architecture rewrite built on Symfony components — this is the version boundary that matters most. Drupal 7 to 10/11 is effectively a rebuild, not an upgrade. Drupal 9 to 10/11 is a much smaller step, mostly dependency and deprecated-code cleanup.
| From | To | Effort |
|---|---|---|
| Drupal 7 | Drupal 10/11 | Full rebuild — treat as a new build with content migration |
| Drupal 8/9 | Drupal 10/11 | Moderate — deprecated code cleanup, module updates |
| Drupal 10 | Drupal 11 | Light — mostly compatibility fixes |
How Do You Protect SEO During a Drupal Migration?
This is where most migrations lose value that took years to build.
- Map every URL. Export your full URL list before touching anything and build a 301 redirect map from old paths to new ones.
- Preserve metadata. Titles, meta descriptions, canonical tags, and structured data (schema.org markup) need to carry over exactly, not “close enough.”
- Match or beat page speed. A slower new site after migration is a common, avoidable ranking hit — test Core Web Vitals before launch, not after.
- Stage and diff. Run the new site in staging and compare indexed pages against the old sitemap before cutover.
What Does a Realistic Migration Process Look Like?
- Audit — inventory content types, custom modules, integrations, and traffic-driving pages.
- Plan the data model — Drupal 10/11 handles content types and fields differently in places; map old to new before writing code.
- Rebuild custom modules — this is usually the largest technical task and the one most agencies underestimate.
- Migrate content — using Drupal’s Migrate API for structured, repeatable transfers rather than manual copy-paste.
- Test in staging — including redirects, forms, search, and any third-party integrations.
- Cut over with monitoring — watch crawl errors and server logs closely for the first two weeks post-launch.
Is a Migration the Right Call, or Is It Time to Rebuild Custom?
Not every Drupal site should stay on Drupal. If your team’s content needs are genuinely complex — multi-site, granular permissions, structured content reused across channels — Drupal’s data modeling is still hard to beat, and universities and large institutions lean on it for exactly this reason (more on that in the next article).
But if you’re maintaining Drupal’s overhead for what’s really a marketing site or a simple content hub, it’s worth comparing against a custom build. Do You Really Need a Custom Web App — Or Is WordPress Enough? walks through that decision from the other direction.
Migrations are where legacy technical debt either gets fixed or gets carried forward for another five years. If you’re sitting on a Drupal 7 or 8 site and need a straight answer on scope and cost, let’s talk — I’ll tell you honestly whether it’s a migration or a rebuild.