# Migration and relaunch checklist This exists because of a relaunch that went badly. Not catastrophically — nothing was down — which is precisely why it was expensive. Performance regressed, a portion of the old URL structure returned errors, redirects were partly wrong, and the search visibility the site had accumulated over years degraded quietly over the following weeks. None of it was hard to prevent. All of it was easy to miss, because a relaunch is judged on whether the new thing looks right, and every item below is about whether the old thing survived. ## Before: baselines you cannot capture later The single most common mistake is having no "before". Once the old system is gone, you cannot prove what changed, and every argument becomes opinion. ``` [ ] Server response time and page load, recorded for the main templates [ ] Core Web Vitals from field data, not just lab tests [ ] Full URL inventory of the current site — crawl it, do not rely on the CMS [ ] Current indexed page count and impressions from search console [ ] Top pages by traffic and by revenue, listed separately [ ] Existing redirect chains documented (you are about to inherit them) [ ] Analytics and tag inventory: what fires, where, on what event [ ] Structured data currently present, by template [ ] Backup verified by restoring it somewhere, not just taken ``` That last one deserves emphasis. An untested backup is a belief, not a backup. ## Mapping: the part that takes longest ``` [ ] Every old URL mapped to a new URL or an intentional 410 [ ] Redirects are single-hop — no chains through intermediate URLs [ ] Parameters, trailing slashes, uppercase variants and legacy patterns all covered [ ] Paginated and filtered URL patterns decided deliberately [ ] Canonical tags point at the new structure, not the old one [ ] Old sitemap kept temporarily so crawlers rediscover and follow redirects ``` Single-hop redirects sound pedantic until you have three migrations layered on one another and a request passes through four hops before returning content. ## Before go-live, on the staging environment ``` [ ] Response times measured against the recorded baseline, same conditions [ ] Redirect map tested automatically against the full old URL inventory, asserting status code and final destination [ ] Forms, authentication, payment and search paths tested end to end [ ] File uploads and media paths verified — including anything served from external storage [ ] Scheduled jobs and background workers verified as running [ ] Analytics and conversion tracking verified as firing correctly [ ] Error pages return the correct status codes, not 200 [ ] Robots directives and staging noindex removed for production, verified explicitly [ ] Caching behaviour confirmed at every layer [ ] Rollback rehearsed, not just documented ``` The redirect test has to be automated. A list of a few thousand URLs is not something anyone verifies by hand, and the ones that break are never the ones you would have spot-checked. ## Go-live ``` [ ] Low-traffic window chosen, with the people who can roll back available [ ] DNS or routing change made with a short TTL set in advance [ ] Certificate valid and covering every hostname in use [ ] Immediately: response times, error rates, a sample of redirects [ ] Sitemap submitted, indexing requested for the highest-value pages [ ] Stakeholders told it is live, and told what to watch for ``` ## After: the window where problems actually appear The temptation is to declare success on the day. Most migration damage becomes visible between day three and week four. ``` Day 1 [ ] Error logs reviewed for 404 patterns nobody predicted [ ] Conversion and revenue compared against the same weekday last week Week 1 [ ] Crawl the new site and compare against the inventory [ ] Search console coverage and indexing reviewed for new exclusions [ ] Any redirect the crawler resolved through more than one hop, fixed Week 2–4 [ ] Impressions and rankings for top pages compared against baseline [ ] Remaining 404s from real traffic mapped or deliberately closed [ ] Performance re-measured — caches are warm now, the honest number is this one, not day one ``` ## Two rules that prevent most of this **Nobody signs off on their own work.** The person who built the redirect map does not verify it. This is not distrust; it is that whoever built it knows the intent, and the intent is exactly what stops them seeing the gap. **The old site stays reachable somewhere.** For at least a few weeks, keep a way to inspect what the previous version actually returned. Half the arguments after a migration are about what the old behaviour was, and nobody remembers accurately.