seo migration process
How the engagement runs
Five phases in a fixed order, each with a gate. The order is not a preference — a benchmark taken after launch proves nothing, and a redirect map written after the URL structure is locked is a much harder document to produce.
- Definition
- A phase-gated migration process — A phase-gated migration process orders SEO work by dependency and defines an exit condition for each phase. Work does not advance until the gate is demonstrably met, which surfaces problems while they are still cheap to fix rather than on launch day when the only available response is to proceed anyway.
The process below is the same one used on every engagement, whether it runs end to end or picks up partway through. It is published in full rather than described in a proposal, so you can assess it before talking to anyone — and use it to hold any other provider to the same standard.
Why gates rather than a task list
A flat checklist lets you tick off launch-day tasks while the redirect map is still incomplete. It gives no signal that you are about to ship something expensive, because every item looks equally weighted.
A gate is a single condition that has to be demonstrably true before the next phase starts. It converts "are we ready?" from a judgment call into a question with an answer. The full checklist sets out every step inside each phase, with owners and outputs.
What happens when a gate is not met
Either the gate moves or the date moves, and both are business decisions rather than SEO ones. The job here is to make sure the decision is informed: what percentage of traffic-carrying URLs are unmapped, and what that exposure is worth.
In practice most gates are met late rather than missed. The value of writing them down is that "late" becomes visible in week six instead of week nine.
What we need from you
Read-only access to Search Console and analytics, permission to crawl the site, the proposed new URL structure if it exists, and the launch date. Server log access is valuable where available but is not required to start.
Beyond access, the thing that matters most is a named person who can make content decisions. Every migration surfaces pages with no clean equivalent on the new site, and those decisions need someone who knows the business rather than the crawler.
| Phase | When | Main activity | Gate |
|---|---|---|---|
| Discovery and benchmarking | 6–10 weeks out | Freeze what you currently have, in numbers | Dated benchmark, crawl and URL inventory all exist |
| Crawl parity and mapping | 4–8 weeks out | Decide where every URL goes | Zero unmapped URLs in the priority tiers |
| Staging QA | 1–3 weeks out | Diff the new site against the old one | Every unexplained difference fixed or accepted in writing |
| Launch day | Cutover window | Verify what shipped matches what was approved | Redirects verified live; no accidental noindex in production |
| Recovery tracking | 30 / 60 / 90 days | Measure against benchmark on a matched cohort | Crawler traffic on new URLs; cohort back in range |
What this process handles well
- Migrations with a fixed launch date and a build already underway.
- Situations where an engineering team implements and someone external specifies.
- Sites large enough that redirect mapping needs a document rather than a memory.
What it is not built for
- Ongoing SEO growth work outside a migration window.
- Sites that have not decided whether to migrate at all.
- Emergency response where the site has already launched — that starts with diagnosis instead.
Questions people ask before starting
How long does the whole engagement take?
Roughly ten weeks before launch and ninety days after it, though the shape varies with the build timeline. The work is front-loaded: discovery and mapping are the heaviest phases, and launch day itself is mostly verification of decisions already made.
What if we are already past the first two phases?
Then the engagement starts where you are. Coming in at staging QA is common and still valuable — the parity diff and launch verification are the highest-yield steps. What is lost is the ability to influence the structure, which is worth knowing rather than glossing over.
Can phases overlap?
Mapping and staging QA routinely overlap, because staging builds land in stages. Discovery cannot overlap with anything, since everything else compares against it. Recovery tracking obviously follows launch. The gates are what stop overlap becoming a compression.
Who runs the launch-day work?
Your engineering team executes the cutover. We verify: redirects on the live host, production directives, sitemaps and the Change of Address filing where one applies. The runbook names an owner for every step so nothing falls between the two groups.
Start with the launch date
Tell us what is changing and when. We will tell you what is realistic in the time available before anyone discusses scope.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.