The Platform Migration Checklist (2026)

Migration failures are predictable. Across the postmortems I’ve read and the migrations I’ve overseen, virtually every visibility disaster traces back to a known checklist item that was skipped — usually because it didn’t block launch. This is the checklist, current for 2026, with each item mapped to the failure it prevents. It compresses the full arguments made in The Pre-Migration Baseline and Staged Rollouts for Platform Migrations into the operational sequence.

Reviewed and current for 2026. Re-reviewed annually; the updated date reflects the last review.

Phase 1 — Before Launch (starts 4–8 weeks out)

1. Build the complete URL inventory

Merge three sources: a full crawl of the live site, server logs (which surface URLs still receiving crawler traffic despite no internal links), and Search Console’s indexed-page data. The CMS page list alone is never complete. Prevents: the long tail of forgotten URLs — parameter pages, legacy paths, paginated archives — going 404 at cutover.

2. Capture the per-template baseline

Rendered HTML, internal-link counts, structured data payloads, field performance, and index coverage — captured per template group, stored outside the platform being replaced. The full seven-layer specification is in the baseline guide. Prevents: the post-launch debate that runs on memory instead of evidence.

3. Build and validate the redirect map

Old URL → new URL, one hop, semantically equivalent destinations. Validate the top URLs by organic value manually, the rest by automated crawl. Flatten existing redirect chains before layering new redirects on top — Google’s redirect documentation treats permanent server-side redirects as the strong signal, and chains add latency, fragility, and crawl cost. Prevents: the silent 4% mapping error rate that lands disproportionately on high-value URLs.

4. Verify rendering parity on the new stack

Fetch key templates from the new platform as a crawler would and diff the content, canonicals, meta directives, and navigation against the baseline. Google’s JavaScript SEO guidance is the reference for what must survive rendering. Prevents: the replatform that looks identical in a browser and empty to a crawler.

5. Plan sitemap and canonical continuity

New sitemaps per the sitemaps protocol ready at cutover; canonicals consistent across the seam; structured data carried over per template and validated. Prevents: mixed canonical signals and markup loss during the weeks search engines reprocess the site.

6. Write the rollback criteria — now, not later

Numeric thresholds tied to the baseline: redirect error tolerance, rendering divergence, index-coverage band, performance regression limit. Name who calls it and what “stop” concretely means. Prevents: the mid-incident negotiation where every threshold not written down gets argued past.

Phase 2 — Launch

7. Stage the cutover by section if the change permits

Modest section first, revenue sections last, each gated before the next ships. The full method — staging units, gates, and when big-bang is genuinely right — is in Staged Rollouts for Platform Migrations. Prevents: every defect shipping simultaneously with overlapping symptoms.

8. Verify redirects within 24 hours

Crawl the complete old URL inventory against the live mapping. Every old URL should answer with a single permanent redirect to its mapped destination. Prevents: mapping errors compounding for weeks before anyone re-checks.

9. Diff rendered output on day one

Same crawler-fetch, same templates, compared against the Phase 1 capture. Prevents: rendering regressions that functional QA cannot see.

10. Ship the new sitemaps and (for domain moves) the change signal

Submit updated sitemaps immediately; for domain-level moves, follow Google’s site move process so the engine receives one coherent signal. Prevents: discovery lag on the new URL space.

Phase 3 — After Launch (4–12 weeks)

11. Watch crawler behavior in the logs first

Crawl volume by section, response codes served to crawlers, fetch latency. This is the earliest external signal of how the change is being digested — it moves days to weeks before rankings do. Prevents: finding out from the traffic graph, at the most expensive possible moment.

12. Track index coverage against the baseline denominator

Per section, against the Phase 1 numbers, on the agreed thresholds. Prevents: slow-motion deindexation hiding inside normal-looking fluctuation.

13. Compare per-template performance against baseline

Field data — Core Web Vitals and server response — per template group, since new stacks routinely regress specific templates behind healthy averages. The redesign-specific patterns are catalogued in Core Web Vitals Regressions After Redesigns. Prevents: the performance regression that becomes a crawl and conversion problem by month two.

14. Hold the monitoring window to its full length

Crawler-facing effects surface on recrawl timescales — weeks, not sprint boundaries. A migration is not “done” at launch; it is done when the soft window closes clean against baseline. Prevents: declaring victory at the moment regressions are just becoming measurable.

How to Use This Checklist

Two rules make it work. Every skipped item is an accepted failure class — skipping is sometimes rational under real constraints, but the acceptance should be explicit and named, not discovered in a postmortem. And ownership must sit outside launch pressure: the items that prevent disasters are exactly the ones that never block launch, which is why they get cut. That structural role — owning preservation while the delivery team owns shipping — is what Migration & Redesign Oversight provides on consequential changes.

Next Step

The full problem domain lives in the Migrations & Redesign Risk hub. If a migration is on your roadmap and Phase 1 hasn’t started, the capture window is already shrinking — discuss the migration before the change ships.