The Website Migration Checklist Nobody Gives You

A client came to us in 2019 after their previous agency migrated them from an old Joomla site to WordPress over a weekend. No redirect map. No crawl of the old site. No DNS planning. By Monday morning, the new site was live, and by Wednesday, their organic traffic had dropped 68%. Three months later, it still hadn't recovered. They'd lost roughly $40,000 in leads during that window, based on their historical conversion rates. The agency's response? "Google just needs time to re-index."

That's not how any of this works.

We've handled migrations for over 25 years now. Platform swaps, domain changes, server moves, CMS rebuilds, HTTP-to-HTTPS conversions, merging two sites into one. And the pattern is always the same: the technical move itself isn't what kills you. The planning you skipped is what kills you.

This is the checklist we actually use. Not a theoretical overview. Not a "top 10 tips" listicle. This is the document we print out, pin to the wall, and check off line by line every time we move a site from one place to another. We're giving it away because we've seen too many businesses get burned by migrations that didn't need to go wrong.

A migration is a controlled demolition. If you don't know exactly where every wall is before you start swinging, something important is coming down.

One Rule Before We Start

Never migrate and redesign at the same time. We cannot stress this enough.

If you change your URL structure, your platform, your design, your content, and your hosting all at once, you've created a situation where diagnosing problems becomes nearly impossible. Did rankings drop because of the new URL structure? The missing redirects? The slower server? The changed page titles? The restructured content? You'll never know.

Migrate first. Get everything stable. Confirm Google has re-indexed, traffic has held, and nothing is broken. Then redesign. Two separate projects, two separate timelines. This alone will save you more grief than anything else on this list.

Phase 1: Before the Migration (Weeks 1-3)

This is where the real work happens. If you're spending 80% of your migration time on this phase, you're doing it right.

Crawl and Document Everything

Run a full crawl of your existing site with Screaming Frog. The free version handles up to 500 URLs, which covers most small-to-mid business sites. Export the full URL list with status codes, titles, meta descriptions, H1 tags, canonical tags, and word counts.

This crawl is your single source of truth. Everything else flows from it.

While you're at it, grab a copy of your site from the Wayback Machine. If something goes sideways, you'll want a reference point that isn't dependent on your old hosting still being active.

Build a URL Map

Every single page on the old site needs a destination on the new site. Every one. Not just the ones you think are important. That random PDF from 2016 that you forgot about? It might have 40 backlinks pointing at it. That blog post from three years ago that gets 800 visits a month from a long-tail keyword? You won't know unless you check.

Your URL map is a spreadsheet. Column A: old URL. Column B: new URL. Column C: redirect type (almost always 301). Column D: notes.

Some old pages won't have a direct equivalent on the new site. That's fine. Map them to the closest relevant page. A 301 redirect to a related page preserves more link equity than a 404. But don't redirect everything to the homepage. Google treats mass homepage redirects as soft 404s, and you'll lose the ranking power those pages carried.

Run a Backlink Audit

Pull your backlink profile from Ahrefs or Semrush. Sort by referring domains and identify your highest-value inbound links. These are the URLs you absolutely cannot afford to break.

Cross-reference this with your URL map. If a page has 15 referring domains pointing at it, that redirect better be airtight. If a page has zero backlinks and zero traffic, it's less critical, but you should still redirect it.

Export Your Google Search Console Data

Search Console only retains 16 months of data, and once your site changes, historical comparisons get messy. Export everything before you start:

• Performance data (queries, pages, clicks, impressions, positions)
• Coverage report (indexed pages, excluded pages, errors)
• Sitemaps report
• Core Web Vitals report
• All manual actions (hopefully none)

You'll need this data to compare pre- and post-migration performance. Without it, you're guessing.

Content Audit

Not every page deserves to come along. A migration is the best excuse you'll ever have to clean house.

Pull up your analytics. Look at the last 12 months. Pages with zero organic visits, zero backlinks, and thin content? Consider whether they belong on the new site at all. Consolidating five weak pages into one strong page is almost always better than carrying dead weight forward.

But be careful here. Don't confuse "low traffic" with "not valuable." Some pages serve existing customers (support docs, product specs, account info). Traffic isn't the only metric that matters.

If you're changing your CMS during the migration, this is also the time to think about choosing the right platform for your actual needs, not just what your developer is most comfortable with.

Benchmark Your Current Performance

Before you touch anything, document what "normal" looks like.

Run your top 10 landing pages through GTmetrix. Record load times, Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. Screenshot the results. You'll want to compare these against the new site to prove the migration didn't make things worse (or to prove it made them better).

Record your current search positions for your top 20 keywords. Note your total indexed page count in Google. Document your monthly organic traffic baseline.

Preserve Your Structured Data

If your current site has schema markup, don't let it evaporate during the migration. Local business schema, FAQ schema, article markup, breadcrumbs, product data — all of it needs to carry over to the new site. We've written in detail about why structured data matters for AI search visibility, and losing it during a migration is one of the most common oversights we see.

Check your current schema with Google's Rich Results Test before migration. Then check it again after.

Lower Your DNS TTL

This is the step everyone forgets. 48 hours before you plan to make the switch, lower your DNS TTL (Time to Live) from whatever it is (often 86400 seconds, which is 24 hours) down to 300 seconds (5 minutes).

Why? TTL controls how long DNS servers cache your records. If your TTL is 24 hours and something goes wrong after launch, it could take a full day for a DNS change to propagate. With a 5-minute TTL, you can switch back in minutes.

After the migration has been stable for 48 hours, raise the TTL back to its normal value.

Phase 2: During the Migration (Launch Day)

If Phase 1 was done properly, launch day should be boring. That's the goal. Boring.

Implement All Redirects Before Going Live

Don't flip the switch and then start building redirects. Every 301 redirect from your URL map should be in place and tested on a staging environment before the new site goes live. Test them with a tool like httpstatus.io or a bulk redirect checker. Look for redirect chains (A redirects to B redirects to C) and fix them. Every chain adds latency and dilutes link equity.

Keep the Old Site Accessible

Do not delete the old site. Do not cancel the old hosting. Keep the old site accessible for at least 30 days after migration, ideally longer. Put it on a subdomain (old.yoursite.com) or just keep the server running.

Why? Because things will go wrong that you didn't anticipate. A redirect you missed. A page you forgot existed. A PDF buried three directories deep that a partner site links to. Having the old site available means you can check and fix these issues quickly instead of reconstructing from memory.

Submit Your New Sitemap

As soon as the new site is live, submit your updated XML sitemap to Google Search Console. Request indexing for your most important pages. This doesn't guarantee faster indexing, but it tells Google where to look first.

If you changed domains, set up a new Search Console property for the new domain and use the Change of Address tool.

Test Everything

We mean everything.

• Click every link on every page. Yes, every one.
• Fill out every form and confirm submissions arrive.
• Test on mobile, tablet, and desktop.
• Check all images load (broken image paths are common after migration).
• Verify SSL is working on all pages, including internal links that might still reference HTTP.
• Confirm analytics tracking is firing on all pages.
• Run Screaming Frog against the new site and compare the crawl against your pre-migration crawl. The page count should match, minus anything you intentionally removed.

Phase 3: After the Migration (Weeks 1-12)

The migration isn't done when the new site goes live. It's done when your organic traffic has stabilized and you've confirmed nothing was lost. That takes 8 to 12 weeks.

Monitor Search Console Daily for the First Two Weeks

Check for:

• Coverage errors: pages returning 404, 5xx, or redirect errors
• Crawl anomalies, especially sudden drops in crawled pages or indexed page count
• Mobile usability issues (the new site might trigger different mobile flags)
• Manual actions (rare, but check anyway)

Google will re-crawl your site at its own pace. You'll see the old URLs slowly drop out of the index and the new ones appear. This is normal. But if you see your indexed page count drop by 50% and not recover within two weeks, something is wrong with your redirects.

Compare Traffic Weekly

Pull up your pre-migration traffic baseline. Compare it week over week. A dip of 10-20% in the first two weeks is normal and expected. Google needs time to process the changes, re-evaluate the content, and update its index.

A dip of 50% or more that persists past week three is a problem. Start investigating redirect issues, crawl errors, or pages that aren't getting indexed.

Run a 30-Day Comparison Crawl

One month after launch, run Screaming Frog again. Compare the new crawl against your pre-migration crawl. Look for:

• Pages that exist on the old site but return 404 on the new site
• Pages with missing or changed title tags
• Pages with missing meta descriptions
• Broken internal links
• Mixed content warnings (HTTP resources on HTTPS pages)
• Orphaned pages (no internal links pointing to them)

Check Your Backlinks

Go back to Ahrefs or Semrush and pull a fresh backlink report. Compare it against your pre-migration audit. Are your high-value backlinks still pointing to URLs that resolve correctly? If a referring domain links to an old URL that isn't redirecting properly, you're bleeding authority. Fix the redirect or reach out to the linking site and ask them to update the URL.

Performance Comparison

Run the same GTmetrix tests on the same pages you benchmarked before migration. The new site should be at least as fast as the old one. If it's slower, figure out why before you do anything else. Common culprits: unoptimized images on the new platform, render-blocking scripts from new plugins, a heavier theme or framework.

The Mistakes That Keep Happening

After 25 years and more migrations than we can count, these are the ones we see again and again.

Redirecting everything to the homepage. We mentioned this earlier, but it bears repeating. If your old site had 200 pages and every redirect points to the homepage, Google will treat all 200 as soft 404s. You'll lose the ranking power every one of those pages had accumulated. Map them individually.

Forgetting about images and PDFs. Your pages might be redirected perfectly, but what about /wp-content/uploads/2018/brochure.pdf? Or /images/team-photo.jpg that other sites link to? These URLs need redirects too.

Not testing redirects before launch. "We'll fix them as they come up" is a gamble, not a strategy. And the stakes are your search traffic.

Ignoring the old site's robots.txt. If you copy the old robots.txt to the new site and it blocks crawlers from sections that should now be accessible, Google won't index those pages. Check it.

Changing URL structure for no good reason. If your old URL was /services/web-design and your new URL is /what-we-do/website-design-services, you've created work for yourself with no clear benefit. Keep URLs consistent where possible.

When You Need Help

Some migrations are straightforward. Moving a 20-page brochure site from one host to another with the same URLs is something a competent developer can handle in an afternoon.

But if you're changing domains, switching platforms, restructuring URLs, and dealing with a site that has 10 years of accumulated search equity — that's a different situation. The cost of getting it wrong is measured in months of lost traffic and the revenue that goes with it.

We've handled migrations exactly like this for businesses across Calgary and beyond. If you're staring down a migration and the checklist above feels like a lot, that's what we're here for.

The single thing to remember: a migration is not a launch day. It's a three-month project, and most of the work happens before anyone touches the new server.

Sources

• Screaming Frog SEO Spider — Free website crawler; free version crawls up to 500 URLs
• Wayback Machine — Internet Archive's tool for viewing cached snapshots of websites
• Google Search Central: Site Moves with URL Changes — Official Google documentation on site migrations, redirect mapping, and the Change of Address tool
• Google Search Central: Redirects and Google Search — Google's guidance on 301/302 redirects, redirect chains, and PageRank transfer
• Google Search Central: Soft 404 Errors — How Google detects and handles soft 404s, including mass homepage redirects
• Google Search Console: Export Data — How to export performance reports, coverage data, and other Search Console data
• Google Rich Results Test — Validates structured data markup and previews rich result eligibility
• GTmetrix — Free website performance testing tool using Lighthouse; reports Core Web Vitals, load times, and optimization recommendations
• httpstatus.io — Bulk URL status code and redirect chain checker for verifying server-side redirects
• Change of Address Tool — Search Console Help — Step-by-step guide for notifying Google of a domain change via Search Console