Site Migration That Does Not Cost You Your SEO

I have watched five-figure migrations turn into six-figure SEO disasters because the team treated migration as a technical problem instead of a continuity problem. The pattern is always the same. Build the new site. Throw a switch. Watch organic traffic drop forty to seventy percent over the next eight weeks. Spend the next quarter trying to recover what was lost on the cutover day.

The technical move is rarely what kills you. Redirect maps that are eighty percent complete kill you. Canonical tags pointing at staging domains kill you. Internal links that still point at the old structure kill you. URL changes done "while we are at it" kill you. The build itself is the easy bit; the continuity work is where every migration I have shipped at scale lives or dies.

Five things, learned the hard way over twelve thousand sites at Seahawk Media. Each is non-negotiable on every migration we ship.

First, the redirect map gets built before any code. Every old URL gets a 301 to its new counterpart. We export the source URL list from Search Console, Ahrefs, and the existing sitemap, then build the mapping in a spreadsheet that becomes the source of truth for the cutover. The build linter fails the deploy if any pre-migration URL is missing from the map.

Second, URL structure is preserved wherever the new platform allows it. Every URL change is a ranking risk. We change URLs only when there is a real content reason — a duplicate, a typo, a canonical we are consolidating — never because the new platform suggests a different convention. The temptation to "tidy up while we are at it" has cost more rankings than any other decision in our migration practice.

Third, sites over ten thousand pages get a phased rollout. Migrate the lowest-traffic content first, validate that rankings hold, then expand. A staged migration limits the blast radius if something goes wrong on a particular template or content type, and gives the team a chance to fix the issue before the high-traffic pages are affected.

Fourth, a parallel-run period. The old site stays live in read-only mode for thirty days post-launch. If the new site has an issue, traffic gets re-routed back instantly. The cost of running two stacks for a month is small compared to the cost of a four-week traffic recovery cycle.

Fifth, ninety days of post-launch monitoring. Search Console crawl stats, indexation coverage, impressions, log file analysis, schema validator, Core Web Vitals field data. Fix regressions in days, not quarters. By day ninety the site is stable and we either hand off cleanly or move into an ongoing care plan.

A handful of migration shapes account for almost all of our project work. Each one has its own playbook and its own usual failure modes.

WordPress to Next.js or Astro is the most common engagement. The brief is usually a marketing or content site that has hit the performance ceiling on classic WordPress and a team that wants modern front-end DX without losing wp-admin for the editorial team. Headless WordPress with WPGraphQL plus a Next.js or Astro front-end satisfies both sides.

Drupal, Sitecore, or Typo3 to WordPress is the second pattern. Moving off legacy enterprise CMS without breaking the SEO rankings the legacy team built up over a decade. Slower migrations, more complex content modelling, but the playbook is the same — full redirect map, preserved URLs where possible, parallel-run, phased rollout.

Shopify to headless commerce is the third. Shopify Plus storefront with a Next.js or Hydrogen front-end, full custom design, faster Core Web Vitals, kept commerce engine. Shopify keeps being the source of truth for catalogue, inventory, and checkout; the front-end goes custom.

The other patterns we see regularly are domain consolidation (multiple legacy domains merging into one with proper canonical and redirect strategy), subdomain to subdirectory consolidation (moving blog.example.com to example.com/blog/ to consolidate link equity), and hosting and platform migrations (moving managed WordPress between Kinsta, WP Engine, Pressable, or to bare-metal infrastructure).

Sites under one thousand pages run four to eight weeks end-to-end including planning, redirect mapping, content migration, QA, and post-launch monitoring. Sites of ten thousand to twenty thousand pages run twelve to twenty weeks. Enterprise migrations of fifty thousand pages or more run six to nine months minimum, with phased rollouts and parallel-run periods built into the timeline.

The biggest variable is content quality at the source. Messy taxonomies, duplicate URLs, and inconsistent metadata add weeks to the planning phase. We will tell you honestly during the audit whether your source site is migration-ready or whether it needs a content cleanup pass first. Pretending the source is clean when it is not is how migrations slip from a quarter into half a year.

Honest ranges from real recent engagements. A small business migration under five hundred pages runs four thousand to twelve thousand pounds. A mid-market migration of one to ten thousand pages runs fifteen thousand to sixty thousand. An enterprise migration of ten to one hundred thousand pages runs sixty thousand to three hundred thousand pounds, including ongoing post-launch SEO support for the first quarter.

About thirty to forty percent of the cost goes to planning and QA, not the technical build. The teams that quote you cheap are the ones who skip the planning. You pay for it later in lost rankings, and the cost of rebuilding rankings is always higher than the cost of preserving them in the first place.