Nick QuirkMigrations are the highest-variance projects an SEO agency takes on. Done well, nobody notices — traffic dips 8% for three weeks and comes back stronger. Done badly, you lose 40% of a client's organic revenue and spend the next quarter unpaid, fixing it.
The difference is almost never SEO knowledge. Every SEO on your team knows redirects matter. The difference is project structure: who owns what, when the redirect map gets built relative to the build, and whether anyone actually crawls staging before launch day.
Here's a website migration project plan that has survived contact with real clients, real deadlines, and real developers who deployed on a Friday afternoon.
Scope the migration type before you quote anything
"Website migration" covers at least six different projects with wildly different risk profiles. Nail this down in the first call, because it drives everything — hours, timeline, and how hard you push back on the launch date.
- Domain change (brand.com → newbrand.com) — highest risk, longest recovery. Budget 90-180 days for full authority transfer.
- Platform/CMS change with URLs preserved — moderate risk, mostly technical parity issues.
- URL structure change / IA restructure — high risk, redirect-map heavy.
- Protocol or subdomain consolidation — low risk if executed cleanly.
- Design/template refresh on the same URLs — low SEO risk, high content-parity risk (people quietly delete 400 words of body copy per page).
- Site consolidation (merging two domains) — highest complexity, requires content-level decisions on every duplicate.
Most real projects are two or three of these at once, which is where scope explodes. A CMS change plus URL restructure plus template redesign isn't three times the work — it's the compounding of three failure modes that you can't isolate when traffic drops.
The number that sets your scope
Crawl the site before you quote. Not Search Console — a full crawl plus GSC export plus GA4 landing pages plus a backlink export. Then answer one question: how many URLs have received at least one organic session or one external link in the last 12 months?
A 40,000-page e-commerce site might have 3,200 URLs that actually matter. That number, not total page count, determines your redirect mapping hours. On the projects I've scoped, redirect mapping runs roughly 1 hour per 100 URLs for manual review after pattern-based matching handles the bulk — so 3,200 meaningful URLs is around 32 hours of focused work, not a Friday afternoon task.
Phase structure: five phases, hard gates between them
Migrations fail when phases overlap. The design team is still moving nav items while you're building the redirect map against a URL structure that no longer exists. Use gates — nothing moves forward until the previous phase is signed off.
Phase 1: Benchmark and inventory (weeks 1-2)
You cannot prove a migration succeeded without a pre-migration baseline. Capture and archive, with dates:
- Full crawl of the live site (URLs, status codes, titles, H1s, meta descriptions, canonicals, word counts, internal link counts)
- GSC performance export — 16 months, by page and by query
- GA4 landing page sessions and conversions, 13 months
- Backlink export with referring domain counts per target URL
- Top 200 tracked keyword positions, screenshotted
- Core Web Vitals field data per template
Gate: the client signs off on the "protected pages" list — typically the top 100-300 URLs by traffic, links, and revenue. These get manual attention at every subsequent stage.
Phase 2: Redirect map and pre-build requirements (weeks 2-5)
This phase runs parallel to the build, not after it. The moment the new IA is approved — before templates are coded — the redirect map starts.
Structure the map as one spreadsheet with columns for old URL, new URL, match confidence, organic sessions (12mo), referring domains, and reviewer initials. Auto-match by pattern where you can, then manually review anything with traffic or links. Redirect to the closest equivalent page; never bulk-redirect to the homepage. On a recent consolidation, 340 of 1,900 URLs had no obvious equivalent — those got a documented decision each: redirect to category, redirect to a new merged page, or 410.
Also in this phase: hand developers a technical requirements doc covering robots.txt, XML sitemaps (old and new), canonical logic, hreflang, structured data per template, pagination, and 404 handling. If it isn't written down before the build, it won't exist in staging.
Phase 3: Staging QA (weeks 5-8)
Get crawl access to staging. Password-protect it, whitelist your crawler IP, and crawl it exactly as Googlebot would. What you're comparing:
- Content parity — word count per page, old vs new. Flag anything that lost more than 20%.
- Metadata parity — titles and H1s carried over, not replaced with template defaults.
- Internal linking — count inbound internal links per protected page. Redesigns routinely strip footer and sidebar links, and a page that had 120 internal links dropping to 8 will lose rankings even with a perfect redirect.
- Redirect testing — run the full old-URL list against staging and check each returns a 301 to the mapped target, not a chain or a 404.
- Rendering — if the new build is JS-heavy, verify content appears in the rendered DOM.
Gate: zero 404s on protected pages, zero redirect chains longer than one hop, content parity above 80% on every protected page. This is exactly the kind of repetitive comparison work worth systematising — our notes on AI-assisted QA for catching errors before clients do cover how to script the diff rather than eyeball 300 pages.
Phase 4: Launch (one day, planned to the hour)
Launch Tuesday or Wednesday morning. Never Thursday, never Friday, never before a holiday. You need two full working days with the whole team available.
Write a runbook with named owners and timestamps: DNS/deploy, robots.txt unblocked, XML sitemaps submitted, GSC change-of-address filed (domain moves only), analytics tags verified firing, live crawl of top 300 URLs, spot-check 50 redirects manually. Assign a rollback decision-maker and a rollback trigger — for example, "if more than 5% of protected URLs return non-200 or non-301 status after two hours, we roll back."
Phase 5: 90-day monitoring (post-launch)
Migrations aren't done at launch; they're done when traffic recovers. Structure this as a retainer add-on, not free goodwill:
- Days 1-7 — daily crawl of the 404 log and GSC Coverage report. Fix new 404s within 24 hours.
- Days 8-30 — weekly comparison of GSC clicks and impressions vs the pre-launch baseline, segmented by template and by protected-page list.
- Days 31-90 — fortnightly. Focus shifts to outreach on high-value broken backlinks and reclaiming pages that haven't recovered.
Where migrations actually break as projects
Three patterns account for most of the disasters I've seen:
Split ownership of the redirect map. Three people edit the sheet, nobody signs off, and the version the dev implements is four days old. Assign one named owner with veto power over the launch date.
The build changes after the map is built. The client renames "Services" to "What We Do" in week 7 and every service URL shifts. Freeze the URL structure at the end of Phase 2 in writing, and treat post-freeze changes as scope changes with a re-mapping cost.
Nobody tracked the hours. Migrations quoted as fixed-fee, at 60 hours, that actually consume 140. Log time against phases from day one so your next migration quote is based on data. This is why migration projects need proper phase and time structure rather than a flat task list — a point worth weighing when you compare project management tools for agencies, since generic boards don't map hours to phases in a way that improves your next estimate.
Client communication during the dip
Tell the client before launch that a 5-15% dip in weeks 2-4 is normal and expected. If you say it after the dip happens, it sounds like an excuse. Put the expected recovery curve in the SOW with a date by which you'd escalate.
During the monitoring window, send a short weekly note with three lines: sessions vs baseline, iss
