Enterprise SEO Site Migration Playbook: From Planning to Post-Launch

Enterprise Site Migrations Are Where Organic Revenue Goes to Die

I'll be blunt: most enterprise site migrations lose traffic. Not because migration is inherently risky, but because the process is treated as a dev project with SEO bolted on at the end.

I've led migrations across sites with 100K+ URLs. The ones that succeed share one thing in common: SEO owns the migration checklist from day one, not day thirty.

This is the playbook I use. No theory. Just the process that protects organic revenue when you're moving at enterprise scale.

Why Enterprise Migrations Fail

Let's start with the failure modes I see repeatedly:

• No URL mapping. The old site has 200K URLs. The new site has 50K. Nobody mapped the gap.
• Redirect chains. Previous migrations left redirect layers. The new migration adds another. Googlebot hits 4-5 hops and gives up.
• Staging environment leaks. The staging site gets indexed because someone forgot a noindex or robots.txt rule.
• No rollback plan, When things go wrong at 2am on launch day, there's no defined path back.
• Post-launch silence. The team ships and moves on. Nobody monitors indexing for the next 90 days.

Every single one of these is preventable. Here's how.

Phase 1: Stakeholder Alignment and Scoping

Before you touch a single URL, you need alignment across engineering, product, marketing, and executive leadership.

I run a migration kickoff meeting that covers three things:

1. What's the business case? Platform change? Rebrand? Domain consolidation? Each type carries different SEO risk.
2. What does success look like? Define the acceptable traffic dip window. I typically set this at 10-15% for the first 4 weeks, with full recovery by week 12.
3. Who owns what? SEO owns the redirect map and monitoring. Dev owns implementation. QA owns testing. No ambiguity.

If you're building an enterprise SEO strategy, migration planning needs to be baked into your roadmap, not treated as a one-off project.

Phase 2: URL Mapping at Scale

This is where most migrations are won or lost.

For a site with 100K+ pages, you cannot manually map every URL. Here's the process I use:

Crawl Everything First

Run a full crawl of the existing site. Screaming Frog, Sitebulb, or your enterprise crawler of choice. You need every indexable URL, its status code, canonical, and internal link count.

Segment by Value

Not all pages are equal. I segment URLs into three tiers:

• Tier 1: Pages driving organic traffic and revenue. These get individual 1:1 redirect mapping.
• Tier 2: Pages with backlinks but low traffic. Map these with pattern-based rules.
• Tier 3: Thin, duplicate, or zero-value pages. Consolidate or let them 404 with intent.

For Tier 1, I export every URL with traffic from Google Search Console (last 16 months), cross-reference with Ahrefs or Semrush backlink data, and build a master spreadsheet. This is non-negotiable.

Pattern-Based Redirect Rules

For Tier 2 and 3, write regex-based redirect rules. Example: if your old blog structure is /blog/2024/01/post-title and the new structure is /insights/post-title, write a rule that strips the date segments.

Test every rule against a sample set. I've seen a single miswritten regex redirect an entire product catalogue to the homepage.

Phase 3: Redirect Chain Prevention

Enterprise sites accumulate redirect debt. Before adding new redirects, audit the existing redirect map.

Here's what you're looking for:

• Any chain longer than 1 hop
• Redirect loops
• Redirects pointing to non-200 destinations
• Mixed protocol redirects (HTTP to HTTPS to HTTP)

Your new redirect map should resolve every old URL to its final destination in a single hop. This means updating old redirect rules, not just layering new ones on top.

This is a core principle of enterprise technical SEO. Managing redirect architecture as infrastructure, not an afterthought.

Phase 4: Staging Environment SEO Testing

Your staging environment needs to be locked down and tested before anything goes live.

Staging Checklist

• Robots.txt: Block all crawlers on staging. Verify with robots.txt tester.
• Meta noindex: Add a global noindex as a safety net. Belt and braces.
• Password protection: If possible, put staging behind HTTP auth.
• Canonical tags: Ensure all staging pages don't canonical to themselves. They should either be noindexed or canonical to the production equivalent.

Pre-Launch Testing

On the staging environment, test:

1. Redirect map: Run every Tier 1 URL through the redirect rules. Verify destination and status code.
2. Rendering: Check that Google can render key page templates. Use the URL Inspection tool or a headless browser.
3. Structured data: Validate schema markup on all key templates.
4. Internal linking: Crawl the new site structure. Check for orphaned pages and broken links.
5. Page speed: Compare Core Web Vitals between old and new. Regressions here will compound traffic loss.

Phase 5: Launch Day War Room

On migration day, I run a war room. Not metaphorically. An actual room (or video call) with SEO, dev, QA, and a decision-maker all available for 4-6 hours.

The launch sequence:

1. Deploy the new site
2. Activate redirect rules
3. Remove staging blocks (noindex, robots.txt disallow)
4. Submit updated sitemaps to Google Search Console
5. Run a live crawl to verify redirects, status codes, and rendering
6. Monitor server logs for 4xx and 5xx spikes in real-time
7. Check Google Search Console URL Inspection for 10-20 high-priority URLs

Have a go/no-go decision point at the 2-hour mark. If critical issues are found, you need the authority to roll back immediately.

Phase 6: Post-Migration Monitoring

The migration isn't done when the site goes live. The real work starts now.

Monitoring Cadence

Track enterprise SEO KPIs religiously during this period. If you see a traffic dip beyond your defined threshold, investigate immediately. Don't wait for the monthly report.

Rollback Planning

Every enterprise migration needs a documented rollback plan. This includes:

• DNS rollback: How quickly can you point the domain back to the old infrastructure?
• Redirect reversal: Can you disable the new redirect rules without breaking the old site?
• Content database: Is the old CMS still running and accessible?
• Decision criteria: What specific metrics trigger a rollback? Define these before launch.

I've only had to execute a full rollback once in my career. But having the plan meant we were back to the old site within 45 minutes, not 45 hours.

The Bottom Line

Enterprise site migrations are high-stakes, high-complexity projects. But they're not unpredictable. Every failure mode I've seen was preventable with proper planning, cross-functional alignment, and disciplined post-launch monitoring.

If you're planning a migration and need an enterprise SEO consultant to lead the process, that's exactly what I do.

FAQs

How long does an enterprise site migration take?

Plan for 3-6 months minimum from scoping to post-launch stabilisation. The URL mapping and redirect testing alone can take 4-8 weeks for sites with 100K+ pages. Rushing this timeline is the single biggest risk factor.

What's an acceptable traffic loss during a site migration?

I set expectations at a 10-15% dip in the first 4 weeks, with full recovery by week 12. If you're seeing a 30%+ drop that persists beyond 6 weeks, something went wrong in the redirect mapping or technical implementation.

Should I change my URL structure during a migration?

Only if the new structure is meaningfully better for users and search engines. Changing URLs just because you're migrating doubles your risk. If the current structure works, keep it and reduce the redirect burden.

How do I handle pages that don't have a 1:1 equivalent on the new site?

Redirect to the closest topically relevant page. If there's no close match, redirect to the parent category. Never redirect everything to the homepage. Google treats mass homepage redirects as soft 404s.

When should I submit new sitemaps after migration?

Immediately after launch. Submit both the new sitemap (with all new URLs) and keep the old sitemap active for 6 months with the redirected URLs. This helps Google discover and process the redirects faster.