Why migrations fail
When a migration costs a site its visibility, the post-mortem almost always finds one of three mechanical causes:
- Old URLs return 404 because nobody built the redirect map. Equity flows to an error page.
- Content silently disappeared — pages that earned rankings were not carried over, and nobody noticed because nobody had the inventory.
- New pages are thin or empty at launch — technically a 200 status, practically a different page. Search engines re-evaluate, and the old relevance is gone.
None of these are exotic. All of them are preventable with a method that fits on one page and an afternoon of discipline before launch.
Step 1 — Inventory everything you own
Crawl the current site and produce the full URL list: every indexable page, its title, its traffic (from analytics), its inbound links (from any link tool you have), and its role (landing page, resource, blog post, utility). Export it to a spreadsheet. This file is the single source of truth for the rest of the migration.
If the site has never been crawled before, expect surprises: forgotten subdomains, staging pages that are indexed, an old blog at a different path. Better to find them now than after cutover.
Step 2 — Triage: keep, merge, retire
Decide page by page:
- Keep — earns traffic or serves the buyer journey. Migrates 1:1.
- Merge — multiple thin pages on one topic; consolidate into one stronger page and redirect the rest.
- Retire — stale, duplicate, or irrelevant. Retire deliberately: redirect to the closest relevant page, never to the homepage by default.
The merge/retire decisions are where migration quietly becomes a content-quality project. That is a feature, not scope creep — a migration is the one moment you will have complete visibility into the content estate.
Step 3 — Build the redirect map as a deliverable
The redirect map is a table: every old URL → its new URL (or its retire target). Rules we hold it to:
- 1:1 where possible. Every kept page gets a direct redirect to its exact successor — not to a section page.
- No wildcard-to-homepage. Homepage-redirecting everything is the most common self-inflicted wound in migrations.
- 301, not 302. Permanent moves must say so.
- Chain-free. A → B and B → C must be collapsed to A → C before launch; chains leak and slow evaluation.
- Reviewed against the inventory. The map is complete when every URL in the Step 1 spreadsheet has a destination.
Step 4 — Preserve what rankings are made of
Per kept page, carry over deliberately:
- Titles and meta descriptions — the new page should inherit them unless you are deliberately improving them (and testing that deliberately).
- Heading structure and primary content — the substance that earned the ranking.
- Internal links — new pages should link to each other at least as richly as the old ones did; internal link loss quietly orphans pages.
- Structured data — if the old pages had it, the new pages must too, correctly.
- Media — images, PDFs and documents get their own redirect rows; downloads that 404 are support tickets and lost links.
Step 5 — Pre-launch verification on staging
Before cutover, on the staging domain:
- [ ] Every old URL tested against the redirect map (status 301, correct destination)
- [ ] No redirect chains
- [ ] Title/meta/content spot-checks on the top 20 pages by traffic
- [ ] Forms, checkout and integrations exercised end-to-end
- [ ] Performance at least matches the old site baseline
- [ ] robots.txt, XML sitemap and canonical tags correct on the new build
- [ ] A written cutover runbook with a rollback path
Step 6 — Launch week: watch, verify, respond
Cutover is when preparation meets reality:
- Immediately: crawl the redirect map on production; fix misses same-day.
- Day 1–7: watch analytics for crawl errors and traffic on the top pages; submit the new sitemap; monitor search-engine diagnostics for crawl anomalies.
- Weeks 2–6: expect normal fluctuation; the pages to worry about are the ones that steadily lose visibility — investigate those specifically, they usually trace back to a content or redirect miss.
The uncomfortable summary
Migration safety is not cleverness; it is completeness. Inventory, triage, map, verify — in that order, with no skipped steps. Teams that improvise this under launch pressure are gambling with assets that took years to build, and the house does not win.
If you would rather have an engineer own the checklist: this is a standard phase of how we run modernization projects, runbook and rollback included.