Migrations are where good websites go to lose their traffic. Not because migration is hard, but because the boring part gets rushed.
Here's what's actually involved.
What counts as a migration?
Anything that changes what search engines already know about your site:
- Changing platform, WordPress to Webflow, Drupal to anything
- Changing your URL structure
- Changing domain
- Moving to HTTPS
- Consolidating multiple sites into one
- Changing hosts
- A redesign that reorganizes the navigation
That last one catches people. They think a redesign isn't a migration. If the URLs change, it is.
The part that matters: the redirect map
Everything else is negotiable. This isn't.
Crawl your existing site and export every URL. Every one. Then map each to its destination on the new site.
What goes wrong:
- Only the important pages get mapped. Then a page nobody remembered turns out to have twelve years of backlinks.
- Redirect chains. Old URL to intermediate URL to final URL. Each hop loses a little and adds latency. Point directly at the destination.
- Redirects to the homepage. A page that no longer exists should either redirect to its closest equivalent or return a 404. Dumping everything on the homepage tells search engines nothing and frustrates people.
- 302 instead of 301. A temporary redirect doesn't pass authority. Use 301 unless you actually mean temporary.
The safest redirect is the one you don't need. If you can keep a URL, keep it. Nobody ever got fired for not changing a URL structure.
What a migration project plan covers
URL inventory. Crawl the old site. Cross-reference with analytics and Search Console so you catch pages the crawler missed and pages that actually earn traffic.
Content inventory. What moves, what gets rewritten, what gets retired. This is a decision-making exercise, and it's usually the thing that stalls the project for a month because nobody wants to make the calls.
Redirect map. Every old URL to a destination. Signed off by someone.
Technical checklist. robots.txt, XML sitemap, canonicals, analytics, tag manager, Search Console verification on the new property, structured data.
Staging and testing. Test redirects on staging. All of them, not a sample.
Launch sequence. Who does what, in what order, and who can roll it back.
Monitoring. Eight weeks minimum. Rankings, crawl errors, 404s, traffic by page.
Where migrations go wrong
The redirect map is done last, in a hurry, by whoever's free. It's the highest-stakes deliverable in the project and it gets treated as cleanup.
Staging is indexed. Someone forgets to block it, and now you have a duplicate site competing with yourself. Check robots.txt on staging, and check it again on launch day, because the classic failure is launching with the staging robots.txt still blocking everything.
Nobody crawled the old site before it was gone. You can't build a redirect map from a site you deleted. Crawl first, keep the export.
Content changed at the same time. If you rewrite the pages and change the URLs in one go, you can't tell which change caused a ranking drop. If you can, migrate first and rewrite later.
Nobody watched afterward. Migrations fail quietly. Traffic slides for six weeks and someone notices in the quarterly report.
What recovery looks like
A dip is normal. Search engines have to recrawl and reprocess everything.
A well-executed migration recovers in four to eight weeks. If you're still down after two months, something's broken and it's findable: check for redirect chains, 404s with inbound links, dropped pages, and pages whose content changed enough that they're no longer about the same thing.
The one rule
Crawl the old site before you touch anything.
Every migration disaster we've seen starts the same way: nobody has a list of what used to be there.
Pragmatica has been building and migrating websites for Canadian non-profits, charities, and associations since 2004. If you're planning a move, get in touch.
