Step 1 - URL inventory. Nothing moves until the map exists. We crawl every URL on the old site and record what each one is worth: its rankings, its backlinks, its traffic. This inventory does three jobs at once - it fixes the scope and timeline of the migration, it decides the redirect map, and it becomes the checklist the live site is verified against after launch. It’s also where data integrity starts: if a page, a title or an image is in the inventory, it can’t be silently lost, because the inventory is what the finished site is checked against.
Step 2 - Rebuild, mirrored. The new site is built on staging while the old one carries on trading, untouched. Content, titles, meta descriptions and structured data are carried over one to one - carried, not regenerated - so what Google reads after the move is what it already trusts. The design can be rebuilt faithfully or sharpened while it’s open on the bench; the crawlable structure underneath stays deliberate either way. Before anything goes live, staging is verified page by page against the inventory from step one.
Step 3 - Redirects, one to one. Every old URL gets a 301 redirect to its exact successor - the page that answers the same question, not the homepage, not a category page that vaguely relates. No wildcard shortcuts, because a wildcard sends hundreds of distinct pages to one address and throws their individual equity away. No redirect chains, because every hop leaks signal and slows the crawl. No orphaned pages, because the inventory says exactly what exists.
Step 4 - Crawl re-test, after launch. Launch isn’t the end of the migration; it’s the start of the verification. The live site is re-crawled against the original inventory: every redirect followed, every page confirmed indexed, every 404 investigated. Search Console is watched through the handover weeks, so a wobble gets caught while it’s still a wobble.
And if something does look wrong, the way back is short. The old site stays live until the new one has passed its checks - launch is a DNS switch, not a demolition, and a switch can be reversed. On the new site, every deploy is versioned in Git, so rolling back a change means redeploying the previous version, not reconstructing it from memory. Migrations go wrong when they’re built as one-way doors. Ours aren’t.
The working version of this process - every check, in order, with the reasoning - is published as our website migration checklist. It’s the same list we run internally, so you can use it to hold us to account, or to hold anyone else to account.