Replatform and Domain Migration Plan with Rollback Gates

The deliverable is a dated runbook with a named owner on every line and two numeric rollback triggers agreed before anyone writes a redirect rule. The usual shape: redirect map frozen ten working days before cutover, cutover on a Tuesday morning, and a defined drop in Search Console impressions per template at day 14 that triggers a decision meeting rather than an argument. A migration plan without a stated condition for reversal is a hope with dates on it. The URL inventory comes from four sources, not one: A rendered crawl of the current site catches what is linked. Sixteen months of Search Console URLs catch what earns impressions, including pages nobody on your team remembers shipping. Ninety days of access logs catch what Googlebot still requests but nothing links to any more, which on older estates is routinely thousands of URLs with live equity. A link index export catches URLs with referring domains but no traffic, and those are the ones that hurt most when they 404, because you cannot win them back. The union of the four is the map's input. Three of the four are usually skipped, and the skipped ones are where the losses come from. Redirect rules I hold to: One hop, 301, no chains, and no regex catch-all pointing at the homepage. Per-URL mapping for the top set by clicks and by referring domains; pattern rules for the tail, each pattern tested against a sample drawn from the inventory before it is accepted. The whole map is validated by crawling the old URL list against staging before cutover, not by spot-checking twenty URLs in a browser the morning after. Cutover: Staging noindex removal appears on the runbook as its own line with a named owner and a verification step, because leaving it in place is the single most common way a technically sound migration fails, and it fails silently for a week. DNS TTL is lowered 48 hours ahead so a reversal is measured in minutes rather than propagation days. The old sitemaps stay submitted deliberately for a period after launch so Google recrawls the old URLs and meets the redirects, rather than discovering them slowly through organic recrawl. After launch: Checkpoints at day 1, 3, 7, 14, 28 and 56, each stating in advance what is expected to be wrong at that point. Impressions falling in week one is normal; the same fall at day 28 is not, and the plan says so beforehand so nobody has to litigate it in the moment. Every checkpoint compares against a per-template baseline captured before the freeze rather than reconstructed afterwards from memory. Not included: Content rewriting, information architecture design, and the redesign itself. I do not implement redirects; your platform team does, and I verify the map against a crawl. No paid media continuity planning. No analytics reimplementation, though I will tell you when the proposed tracking plan will make the post-launch read impossible. Who this is not for: Anyone with an immovable marketing launch date inside four weeks. The freeze alone consumes two of those weeks and the plan loses its rollback triggers, at which point you are buying reassurance rather than protection. Teams with no staging environment that mirrors production routing. And anyone combining a replatform, a redesign, a rebrand and a CMS change in one release. I will ask you to sequence them, and if you cannot, I will say plainly that no plan can attribute a post-launch drop to any one of the four, and that you should hire me after that decision rather than to bless it.