How long should an SEO migration take from kickoff to launch?

For a mid-sized B2B tech site (200 to 1,000 pages), we plan eight to twelve weeks from migration kickoff to launch, with another four weeks of post-launch monitoring. Smaller sites can compress to six weeks. Enterprise migrations with thousands of URLs, multiple subdomains and complex redirect logic can stretch to four months. The tempting compression to four weeks is where damage gets done, because the redirect mapping work alone needs three to four weeks for a properly inventoried site.

Should we keep the old site running in parallel with the new one?

Briefly, yes. We typically run both sites on staging URLs for two weeks of QA, then cut over to the new site at the production domain in a single move. Parallel running on production indefinitely creates duplicate content problems, splits link equity and confuses Google. Use the staging window to validate redirects, schema, sitemaps and analytics. Once the new site is live, the old site should only exist as the source of historical data, not as a serving system.

How much organic traffic loss is normal after a migration?

A well-executed migration sees zero to 10% temporary dip in the first four to six weeks, recovering to baseline by week eight and continuing to grow. A 15 to 25% dip is salvageable but indicates redirect or rendering issues. A 30%-plus drop suggests something fundamental went wrong, usually broken redirect chains, missing canonical tags or large blocks of content lost without one-to-one mapping. We check Search Console daily for the first month and address any pattern of lost rankings within 48 hours.

SEO migrations: protecting rankings during a replatform

We’ve migrated dozens of B2B tech sites over the past few years. Some have come through with their organic traffic intact, occasionally up. Others have lost 30-50% of their organic visibility and taken six months to claw it back. The difference is almost always in the planning, not the execution.

Here’s the migration playbook we run and the specific places where projects go wrong if you skip steps.

What “migration” actually means

We use “migration” loosely to cover any of:

Replatforming (WordPress to headless, Webflow to custom build, HubSpot CMS to WordPress, etc.)
Redesigning with new URLs and IA
Domain change or consolidation (subdomain.com → main.com/section)
HTTPS migration (still occasionally relevant)
Moving to a new CMS but keeping URLs

The risk profile differs but the discipline is the same. Every URL change is a redirect decision. Every redirect decision is a chance to lose traffic.

Phase 1: pre-migration audit

Before anything moves, we build a complete inventory. Not “the pages we know about”, a complete inventory.

Sources:

A full crawl of the current site (Screaming Frog or Sitebulb).
Search Console performance data for the past 16 months, exported.
GA4 landing page report for the past 12 months.
Ahrefs or Semrush for any URLs with backlinks.
The XML sitemap (if accurate, which it often isn’t).

We deduplicate, then build a single spreadsheet of every URL with three fields:

Last 12 months organic clicks
Total inbound external links
Whether it’s currently in the sitemap and indexed

This becomes the priority list for redirect mapping. Any URL with material clicks or backlinks must have a thoughtful redirect plan. URLs with neither can often be allowed to 404, but verify first.

Phase 2: redirect mapping

This is where most migrations fail. The team responsible for the redirects is usually rushed, doesn’t have the SEO context and ends up either redirecting everything to the homepage or missing a chunk of URLs entirely.

Our rules:

One-to-one redirects wherever possible. Old URL to its new equivalent.
One-to-best-match where exact equivalents don’t exist. Not the homepage. The closest topical match.
Avoid redirect chains. Old → New, not Old → Intermediate → New.
Test the redirect map before launch. We use a script that takes the old URL list and the redirect rules, simulates the destination and flags anything ending up on the homepage or 404ing.

For a recent migration of an enterprise software site, we mapped 1,200 redirects manually with the marketing team. It took two weeks. The site retained 96% of its organic traffic the month after launch. The team that wanted to “let the homepage catch the orphans” would have lost 30%.

Phase 3: technical preparation on the new site

Before launch, the new site needs:

robots.txt that allows crawling of the live site (and ideally blocks the staging site).
A clean XML sitemap with only canonical, indexable URLs.
Self-referencing canonical tags on every page.
The same hreflang setup if the old site had multilingual or regional variants.
Schema markup matching or improving on the old site.
Equivalent or better internal linking. We always check that the new IA preserves the link equity flow.

Speed must not regress. If the old site had passing Core Web Vitals and the new one doesn’t, you’ve done damage that no amount of redirect mapping will fix. Our Core Web Vitals 2026 post covers the metrics we test against.

Phase 4: launch

The launch itself is the most over-prepared and under-executed step.

What we do on launch day:

Deploy at low-traffic time (for B2B tech, that usually means a weekday morning when sales activity is light, not a Friday evening when nobody is around to firefight).
Verify the new site is crawlable with a Googlebot user-agent.
Submit the new sitemap to Search Console.
Test 20+ random old URLs to confirm redirects work and land on appropriate pages.
Monitor server logs for crawl behaviour over the first 48 hours.
Watch for unexpected 404s in Search Console.

The first 72 hours after a migration are when subtle issues surface. Have someone monitoring, not just hoping.

Common failure patterns

A few specific things we see on migrations that haven’t worked.

The “redirect everything to the homepage” pattern

Easy to implement, devastating to traffic. Google interprets a homepage redirect from a content URL as a soft 404. The original page’s authority isn’t passed. We’ve seen this lose 40%+ of organic traffic.

The staging-site-indexed pattern

The new site was prepared on staging.client.com. Robots.txt was updated… after launch. By then, Google had indexed thousands of staging URLs and the duplicate content issue cost weeks to resolve.

The “we forgot the old blog” pattern

Migration scope was the marketing site. The blog was on a subdomain or in a separate CMS. Nobody remapped its URLs. The blog’s organic traffic, often 60% of the site’s total, evaporated.

The internal links that point to old URLs

The CMS migration moved the content but didn’t update internal links in the body copy. The site is full of links to redirected URLs. Crawl efficiency suffers and the redirect chains slowly build up. We always include an internal-link rewrite step in the migration.

Our internal linking strategies for large tech websites post covers the broader linking discipline that should survive a migration intact.

The schema regression

The old site had FAQ schema, Article schema and Product schema, all properly implemented. The new site has none of it because the developer “didn’t have time” and “we can add it later”. Rich results disappear from the SERP. Our schema markup for SaaS websites and structured data for AI search posts both cover what to preserve.

Phase 5: post-launch monitoring

The first 30 days are critical. We monitor:

Indexation in Search Console. New URLs being discovered, old URLs being deprecated. There should be a clear handover within two weeks.
Organic traffic in GA4. A small dip in the first 1-3 weeks is normal. A sustained drop after week 4 is a problem.
Crawl stats in Search Console. Crawl rate should remain steady. A drop usually indicates a robots.txt or technical issue.
Coverage report. Watch for spikes in “Crawled, not indexed” or “Discovered, not indexed”.
Server logs for Googlebot. Are the new URLs being crawled? Are the redirects being followed correctly?

A 2-3 week dip is normal. A 6-week dip is a problem requiring root-cause investigation.

When the migration is also a redesign

The hardest migrations are the ones bundled with significant IA changes. New URLs, new page templates, fewer or more pages overall. The redirect mapping is harder because there isn’t always a one-to-one match.

For these projects, we plan the IA in the SEO audit phase, not the design phase. Our topic clusters for technology companies approach gives a good starting framework. The IA should make organic search sense first, then be refined by UX requirements.

For a related view on how the wider web project should handle SEO continuity, see our piece on the B2B website migration guide in our web design pillar, which covers the project management side as well as the SEO.

Tools we use

Screaming Frog for crawls and redirect testing.
Ahrefs for backlink inventory and identifying URLs we can’t afford to lose.
Search Console for performance data, coverage tracking and post-launch monitoring.
A custom script for redirect map validation. The single most useful tool we have on migration projects.
GA4 for traffic monitoring, with proper cross-domain tracking if the migration crosses domains.

A timeline that works

For a typical mid-sized B2B tech site (200-1,000 pages), our migration timeline:

Weeks -8 to -6: Pre-migration audit and inventory.
Weeks -6 to -3: Redirect mapping, IA finalisation, schema planning.
Weeks -3 to -1: New site QA, redirect testing on staging, sitemap preparation.
Week 0: Launch.
Weeks +1 to +4: Active monitoring and remediation.
Weeks +4 to +12: Ongoing performance tracking, reporting against pre-migration baseline.

Compressing this timeline is the most common cause of migration disasters.

A reality check

Even well-executed migrations sometimes lose 5-10% of organic traffic temporarily. Google takes time to consolidate signals across redirected URLs. Backlink equity transfer isn’t instant. New URL structures take time to settle. For rebrand-driven migrations specifically, we’ve documented the recurring traps in SEO mistakes during a SaaS rebrand.

Setting that expectation with stakeholders before launch is essential. The migration is a success if the site recovers to baseline within 4-8 weeks and exceeds it within 3-6 months.

If you’ve got a migration on the horizon and want a second opinion on the plan before kick-off, tell us about it. We’re usually able to spot a few quick wins (or a few looming problems) in a 30-minute call. Our web design service and SEO service pages cover how we work on these projects together.