A Drupal migration rarely fails on launch day. It fails three weeks later, when organic traffic has quietly dropped 40% and nobody can say exactly why.
That's the part most web design agencies skip. Moving a Drupal site, whether you're changing hosts or rebuilding off Drupal 7, is a solved technical problem. Keeping the rankings, redirects, and pipeline you spent years building is the hard part, and it's where most redesigns bleed traffic.
We're Takeoff, a website-first marketing agency for established B2B companies with long sales cycles. We've run dozens of redesigns and replatforms where SEO and development sit on one plan instead of in separate silos. On FiscalNote's redesign, that integrated approach grew SEO-sourced demo requests 57.1% and organic search traffic 35.66%, instead of the drop most teams brace for.
This guide covers what a Drupal migration actually involves, the different projects people call "migration," the step-by-step process, and the specific SEO pitfalls that sink these projects, with the fix for each one.
A Drupal website migration is the process of moving a Drupal site to a new environment or a new version of Drupal while preserving its content, functionality, and search visibility.
The word "migration" hides a trap, because people use it for three very different projects. One is a straightforward server move on the same Drupal version. One is a full rebuild from a legacy version like Drupal 7 onto Drupal 10 or 11. And one is leaving Drupal for a different CMS entirely. Knowing which one you're facing determines your effort, your tooling, and, for the purposes of this guide, your SEO risk.
Before anything else, figure out which of the three moves you're making. Budget, timeline, and risk all flow from that one answer.
It matters more now because Drupal 7 reached end of life on January 5, 2025, so a lot of teams still running it are being pushed onto a harder path whether they planned for it or not.
This is the server-to-server case. Your site already runs a modern Drupal version and you're only changing hosts. The work is mechanical: back up the database and files, provision a matching environment, transfer files, import the database, update settings.php, clear cache, then test thoroughly before you switch DNS.
The SEO stakes here are lower, but don't assume they're zero. A host change can quietly shift your protocol (http vs https), www vs non-www handling, or trailing slashes, and none of those throw an error while they silently create duplicate or alternate URLs. Run a pre- and post-move crawl diff to confirm your URLs stay one-to-one before you call the risk low.
A major-version upgrade is a rebuild, not a file transfer. Drupal 8 moved to a Symfony-based, object-oriented architecture, so there's no in-place upgrade path from Drupal 6 or 7. You stand up a fresh Drupal 10 or 11 site and migrate content into it through an Extract, Transform, Load (ETL) pipeline.
This is where SEO risk gets high. A rebuild almost always changes URLs, templates, metadata, and internal linking, which is exactly the set of things your rankings depend on. The SEO section below is built around this scenario.
Some teams use the rebuild as the moment to leave Drupal altogether, moving to Webflow, WordPress, or another platform. This is the highest-risk path of the three. There's no shared Drupal tooling to lean on (the Migrate API has nothing to connect to on the destination side), you remap the entire content model by hand, and you carry the greatest odds of losing URL structure, metadata, and schema along the way.
The tradeoff is that you're rebuilding content types, templates, and every SEO signal from scratch, so the URL and redirect discipline in the SEO section below matters even more here than on a Drupal-to-Drupal upgrade.
One note on scope: the step-by-step process that follows is written for a Drupal-to-Drupal upgrade and leans on Drupal's own Migrate API. A cross-CMS move follows the same SEO principles (audit, parity, redirects, monitoring) but uses the destination platform's import tooling instead of the Drupal-specific steps below.
Migration Path Matrix
A migration runs in sequence, and most failures trace back to skipping the audit or rushing content mapping. Do the phases in order and the SEO risks below become manageable instead of surprises.
Set timeline expectations up front. A simple site runs about 4 to 6 weeks, a mid-complexity site 2 to 3 months, and an enterprise or multi-site build 4 to 6 months or more.
Start with an honest inventory of the old site: content types, fields, taxonomies, views, user roles, and every integration. The bigger job is usually the modules. Many contributed modules built for Drupal 7 are deprecated or fully rewritten for Drupal 10 and 11, so each one has to be mapped to a modern equivalent, folded into a core feature, or flagged for a custom rebuild. The Upgrade Status module and Drupal Rector surface deprecated code and readiness gaps so you're not guessing.
This is also where the SEO audit happens, and it's more than exporting your top pages. Pull every URL that receives traffic from multiple sources (a full crawl, GA4, Search Console, and third-party backlink data) into one master inventory. Top performers aren't the only pages that matter: a low-traffic page can still hold backlinks or AI citations worth preserving.
Then enrich each URL with its organic and non-organic traffic, conversions, backlinks, and AI-citation status, and run a semantic similarity check to flag cannibalized or duplicate content. That inventory is what drives a deliberate keep, merge, redirect, or retire decision for every URL, which is a very different thing from a generic "export your top pages" audit. On Takeoff projects this is a required first phase, and the SEO section below covers why.
For an upgrade, you spin up a clean Drupal 10 or 11 instance (local tooling like DDEV or Lando, with Composer managing dependencies) and rebuild your content types, fields, and taxonomies to mirror where the old data will land.
Treat this as the chance to fix legacy technical debt instead of carrying it forward, the rare moment you can correct a messy content model without breaking a live site.
Now the ETL execution. Enable the core migration modules (Migrate, Migrate Drupal, and Migrate Drupal UI), connect the legacy database with read-only credentials, and run the import. The Migrate API is the framework that understands Drupal entities, fields, and configuration. The Migrate Drupal module is the piece that reads an older Drupal source and maps it into the new version.
Migrations run in batches through Drush (for example, drush migrate:import), and they can be rolled back and re-run, which matters when the first pass gets a field mapping wrong. Migrate Plus and custom YAML configs handle field transformations and data sanitization. You don't need to run these commands yourself to plan the project, but you do need to know your developer has a rollback path.
Before launch, run functional and content QA on a staging environment: confirm every content type migrated, user permissions work, and layouts render. Automated testing with Behat and PHPUnit catches regressions at scale, but pair it with manual QA on your highest-value pages.
Run the technical SEO audit on staging in parallel, not after. Verify that every URL from the live site resolves as planned, implement and test your redirects, put schema in place, and clear the critical crawlability and indexability issues before anything ships. This is the pre-launch gate that keeps a clean-looking launch from quietly breaking rankings.
Then verify again the moment you go live. Staging and production don't always behave the same, so some issues only surface once the site is real: redirects that resolve differently, a staging robots.txt that shipped by accident, DNS and protocol edge cases. Confirm all of it in production before you call the launch done.
This is the part almost every other Drupal migration guide waves at and moves past. A migration can succeed technically and still tank your SEO, and when it does, the damage shows up in pipeline, not in an error log. The good news is that these pitfalls are predictable, which makes them preventable with a documented process.
Here's each one, paired with the fix.
A rebuild changes path aliases and routing. Without a complete redirect map (a 301 from every old URL to its new equivalent), you hand crawlers and users a wall of 404s and throw away the link equity those pages earned.
The fix is a full URL inventory and a one-to-one redirect strategy built before launch, not after. Every old URL either maps to a new one or is a deliberate decision, never an accident.
Title tags, meta descriptions, canonical tags, and structured data routinely get dropped or reset to template defaults during a migration. Losing the title tags and canonicals means Google loses the on-page signals it used to rank the page. Losing the schema is a separate hit: your rich results (the review stars, FAQ dropdowns, and other SERP enhancements) stop showing, even when rankings hold.
The fix is to export and preserve your existing metadata (or deliberately improve it), then re-implement schema on the new templates before go-live.
It's easy to quietly drop content, trim copy, or change heading structure while rebuilding, and every one of those edits erodes the on-page signals a page ranked on. A page that lost half its body copy in the move will usually lose rankings with it.
The fix is to run content parity checks that confirm your high-value pages carried over with their ranking-relevant elements intact, headings and body included.
The classic launch-day disaster is pushing a staging site live with a noindex tag or a blocking robots.txt still in place from the staging environment. Add a stale or missing XML sitemap and you've made your new site hard for search engines to find at exactly the wrong moment.
The fix is a pre-launch crawlability checklist and a fresh XML sitemap submitted the moment you go live.
A new theme and unoptimized assets can leave the rebuilt site slower than the one it replaced, which hurts both rankings and the experience of the buyer you worked to attract.
The fix is to turn on Drupal's caching layers (BigPipe, internal page cache), add Redis or Memcached and a CDN, and optimize images. Validate with Lighthouse and PageSpeed before launch, but treat those lab scores as a sanity check, not proof. What actually confirms success is field data, the Core Web Vitals Google collects from real users. Baseline the current live site's field data before launch, then compare once the new site has gathered its own 28-day window.
Even a clean migration needs a watch period. Traffic and ranking drops often surface days after launch, not on day one, so a site that looks fine at go-live can still be losing ground.
The fix is two scheduled reviews, not a single glance at the dashboard. A 30-day technical review catches regressions in indexing, redirects, and crawl errors once Google has recrawled the new structure. A 45-day SEO and AEO performance review looks at the slower signals: traffic trends, ranking movement, and AI citations. Booking both means a regression gets caught in days, not the following quarter. [SME — Max to confirm the 30/45-day framing before publish, since he owns the 45-day checks.]
If you can't afford a traffic drop, the answer isn't a better checklist. It's running the migration as one integrated project instead of two disconnected ones.
Takeoff is a website-first B2B agency that treats a redesign or migration as a single plan where SEO and development run together from day one. Most agencies lose traffic in a migration because SEO gets handed off after the build, once the URLs and templates are already locked. We run it the other way around.
What that looks like in practice:
The proof is in what happens to traffic after launch. Following a redesign and integrated SEO engagement, Menlo Ventures saw organic search traffic rise 38.55%, search impressions climb 743.69%, and LLM/AI-sourced traffic grow 923.48%. Their CMO, Tiffany Spencer, put it plainly: "Your team is the first SEO group we've met that aligned strategy with our actual business goals. That's what's been missing from other agencies."
That's the opposite of the post-launch traffic cliff most teams expect from a migration.
If you're planning a Drupal migration and rankings and pipeline are on the line, let's talk. Get a quote.
Request a Quote or email lenny@takeoffnyc.com to start the conversation.
.avif)
