Pre-Launch Migration Parity Check

Migration losses are decided before launch and diagnosed weeks after it, by which point the old site is gone and the comparison that would have explained the drop cannot be made. Post-launch audits are recovery work, not prevention. This runs while both versions exist, and its output is a decision to launch or not, not a list of improvements for later.

The skill file

---
name: pre-launch-migration-parity-check
description: Use when a replatform, redesign or domain change is weeks from launch and both the staging environment and the current live site still exist.
---

# Pre-Launch Migration Parity Check

Migration losses are decided before launch and diagnosed weeks after it, by which point the old site is gone and the comparison that would have explained the drop cannot be made. Post-launch audits are recovery work, not prevention. This runs while both versions exist, and its output is a decision to launch or not, not a list of improvements for later.

## What you need first

- A complete crawl of the live site exporting URL, status, canonical, meta robots, title, H1, word count and internal link count
- Crawl access to staging behind HTTP authentication or an IP allowlist, never behind a robots.txt block
- Top URLs by traffic, by revenue and by referring domains, as three separate lists rather than one
- A launch date and the name of the person who is allowed to stop it

## Method

1. Freeze the live crawl as a dated file and store it outside the project. After launch the old URL set cannot be reproduced, and this file is the only proof of what existed.
2. Crawl staging with identical settings and diff the two URL lists. That diff is the redirect map; it is not a document to be written separately afterwards.
3. Confirm every URL on the traffic, revenue and backlink lists appears in the map with a one-to-one destination. Collapsing many old URLs onto a category or the homepage is where migrations lose the most, and it is always defended as tidying up.
4. Compare template to template rather than page to page: title pattern, canonical, meta robots, structured data, H1, main content word count and internal link count. A regression in a template multiplies across every URL that uses it.
5. Confirm staging is protected by authentication rather than by robots.txt or a site-wide noindex, then confirm separately that whatever protects it is removed at launch. Both of those failures have taken entire sites out of the index on launch day.
6. Test the redirect rules on staging against the full frozen list, not a sample: query strings, trailing slashes, uppercase paths, legacy patterns nobody remembers. Rules that pass on twenty hand-picked examples routinely fail on the long tail.
7. Agree the monitoring set before launch: which URLs are checked at hour one, day one, day seven and day thirty, which numbers are watched, and what value triggers a rollback. Deciding this afterwards means arguing about it during an incident.

## What this produces

A go or no-go parity report containing the frozen live inventory, the full redirect map with one-to-one coverage of every valuable URL, a per-template diff, and a dated monitoring and rollback plan.

## Where this goes wrong

- Protecting staging with robots.txt or a global noindex, either of which ships to production and deindexes the new site on day one
- Building the redirect map from the sitemap rather than from logs and backlink data, so URLs that were never in the sitemap but still carry links and traffic are silently dropped
- Shipping a replatform and a redesign in the same week, which makes any drop afterwards impossible to attribute to either
- Treating the map as finished once written, when an untested map is a spreadsheet rather than a migration

---

From the QuQi skill library - https://www.quqi.io/skills/pre-launch-migration-parity-check

What you need first

• A complete crawl of the live site exporting URL, status, canonical, meta robots, title, H1, word count and internal link count
• Crawl access to staging behind HTTP authentication or an IP allowlist, never behind a robots.txt block
• Top URLs by traffic, by revenue and by referring domains, as three separate lists rather than one
• A launch date and the name of the person who is allowed to stop it

Method

1. 01 Freeze the live crawl as a dated file and store it outside the project. After launch the old URL set cannot be reproduced, and this file is the only proof of what existed.
2. 02 Crawl staging with identical settings and diff the two URL lists. That diff is the redirect map; it is not a document to be written separately afterwards.
3. 03 Confirm every URL on the traffic, revenue and backlink lists appears in the map with a one-to-one destination. Collapsing many old URLs onto a category or the homepage is where migrations lose the most, and it is always defended as tidying up.
4. 04 Compare template to template rather than page to page: title pattern, canonical, meta robots, structured data, H1, main content word count and internal link count. A regression in a template multiplies across every URL that uses it.
5. 05 Confirm staging is protected by authentication rather than by robots.txt or a site-wide noindex, then confirm separately that whatever protects it is removed at launch. Both of those failures have taken entire sites out of the index on launch day.
6. 06 Test the redirect rules on staging against the full frozen list, not a sample: query strings, trailing slashes, uppercase paths, legacy patterns nobody remembers. Rules that pass on twenty hand-picked examples routinely fail on the long tail.
7. 07 Agree the monitoring set before launch: which URLs are checked at hour one, day one, day seven and day thirty, which numbers are watched, and what value triggers a rollback. Deciding this afterwards means arguing about it during an incident.

What this produces

A go or no-go parity report containing the frozen live inventory, the full redirect map with one-to-one coverage of every valuable URL, a per-template diff, and a dated monitoring and rollback plan.

Where this goes wrong

• Protecting staging with robots.txt or a global noindex, either of which ships to production and deindexes the new site on day one
• Building the redirect map from the sitemap rather than from logs and backlink data, so URLs that were never in the sitemap but still carry links and traffic are silently dropped
• Shipping a replatform and a redesign in the same week, which makes any drop afterwards impossible to attribute to either
• Treating the map as finished once written, when an untested map is a spreadsheet rather than a migration

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Technical SEO