The Migration Checklist Nobody Gives You

Every website redesign proposal has a line item that says something like 'content migration'. It is one line because everyone involved wants to believe it is one line. Then launch week arrives, and it turns out that line contained four hundred blog posts with hotlinked images, a decade of URL structures nobody documented, sixty PDFs linked from invoices customers still have, and a contact form whose submissions were quietly feeding a spreadsheet someone in accounting checks every Monday.

Content migration is where redesigns lose search rankings, break customer bookmarks, and burn goodwill — not because it's hard, but because it's boring, and boring work gets skipped. This is the checklist for doing it properly. It's organized in the order you should do it: inventory first, mapping second, moving third, verifying last. Budget roughly a third of your total redesign effort for this. If that number sounds high, that's the point of this article.

Phase 1: Inventory — you cannot move what you haven't counted

Before anything else, build a complete list of what exists. Not what you remember existing. The gap between those two is where the Monday-morning surprises live.

Crawl your own site

Run a crawler over your current site — Screaming Frog's free tier handles up to 500 URLs, which covers many small-business sites; sitemap exports and your CMS's own lists fill the gaps. You're building a spreadsheet with every URL and, for each one: page type (page, post, product, PDF, category archive), rough traffic over the last 12 months (from your analytics), inbound links if you have search console data, and a keep/merge/kill decision you'll make in phase 2.

Inventory the things a crawler misses

This is the section that earns this article its title. Crawlers find pages. They don't find:

• PDFs and downloadable files — price lists, manuals, forms. These get linked from emails, invoices, and other people's sites, and they almost never make it into a redesign plan. Check your uploads folder, not just your pages.
• Images hotlinked from elsewhere or embedded at old paths — content pasted in from Word or an old site sometimes references images on domains you're about to turn off.
• Embeds and iframes — YouTube videos, Google Maps, booking widgets, that mortgage calculator from a third party. Each one is a dependency to re-verify.
• Forms and where their data goes — every form on the old site has a destination: an email address, a CRM, a spreadsheet, a notification chain. Document each one, because the new form will silently go somewhere else if you don't.
• Redirects that already exist — your current site probably has redirect rules from the previous migration. If you drop them, links that have worked for eight years break. Old redirects must be chained into the new map (and ideally flattened so they don't chain twice).
• Email addresses and DNS oddities — if your domain's DNS is being touched during the move, inventory MX records, SPF/DKIM entries, and subdomains (shop., app., that landing page from an old campaign) before anyone changes a nameserver.
• Scheduled and dynamic content — posts scheduled for future publication, seasonal pages currently hidden, content that only appears to logged-in users.

Capture the metadata, not just the content

For every page you're keeping, the migration must carry: title tag, meta description, publication date (republishing everything with today's date wrecks both reader trust and search signals), author, categories and tags, and featured image. In WordPress-to-WordPress moves the export tools handle most of this; in builder-to-WordPress or platform-switching moves, assume nothing carries over until you've verified it does.

Phase 2: Decide and map — the redirect file is the deliverable

With the inventory done, make three decisions per URL: keep as-is, merge into another page, or retire. Be ruthless with merging — five thin posts about the same topic consolidated into one good page usually outperforms all five. Be careful with retiring: a page with zero traffic but a link from an industry association is still earning its keep.

Build the redirect map

The single most valuable artifact of the whole migration is a two-column spreadsheet: old URL, new URL. Rules that keep it honest:

• Every old URL gets a row. Kept pages map to their new address. Merged pages map to the page that absorbed them. Retired pages map to the most relevant surviving page — and only genuinely orphaned content should return a 404 or 410.
• Never redirect everything to the homepage. Search engines treat mass homepage redirects as soft 404s, and users treat them as broken. A visitor following a link about winter tire storage should land on something about winter tire storage.
• Use 301s (permanent), not 302s (temporary). A 302 tells search engines the move isn't real, and they'll keep the old URL in the index.
• Map file URLs too. That price-list PDF needs a redirect just like a page does.
• If URL structure isn't changing, verify that claim. 'We're keeping the same URLs' has a way of being mostly true, and the exception is always the category archives.

A useful rule of thumb: any URL that received even one organic visit or has one external link in the past year deserves a proper redirect. The cost of a redirect row is thirty seconds; the cost of a lost ranking is not.

Phase 3: The move itself

Migrate on a staging copy, never in place

All content work happens on a staging site — a private copy of the new site where you can import, break, and re-import without an audience. Your host may provide staging environments with one click; if not, a subdomain behind a password does the job. Two non-negotiables while staging is up: block search engines from indexing it (a robots directive plus password protection — staging sites getting indexed and competing with the live site is a classic self-inflicted wound), and keep a content freeze policy for the old site (see below).

Handle the content freeze honestly

Between 'we copied the content' and 'the new site is live' there is a gap — days or weeks — during which the old site keeps receiving comments, form submissions, orders, and edits. You have two options: freeze content changes on the old site for the duration (fine for a brochure site, announce it to your team), or plan a delta migration — a final pass that carries over everything created since the first copy. E-commerce and membership sites always need the delta pass. Decide which you're doing before you start, not when someone notices last week's blog post is missing.

Watch the fragile categories

Some content types break in transit more than others:

• Internal links — links between your own pages often still point at old URLs (or worse, at the staging domain) after migration. Run a crawler over staging and search the database for both the old domain and the staging domain before launch.
• Embedded images with hardcoded paths — content pasted from the old site may reference the old domain's image paths. A search-and-replace tool that understands serialized data (in WordPress, better-search-replace-style tooling, not a raw SQL replace) fixes this safely.
• Shortcodes and builder markup — content built in one page builder becomes literal gibberish text in another. Every page using shortcodes from the old theme or plugins needs manual review; there's no shortcut here, only smaller and larger versions of the cleanup.
• Formatting from ancient posts — that ancient post styled with inline font tags will look wrong in the new theme. Triage by traffic: fix the top 20, skim the rest.

Phase 4: Launch and verify — the part everyone rushes

Launch day is a checklist, not an event. In order:

1. Deploy the redirect map and test it before announcing anything. Take your top 50 old URLs and check each returns a 301 to the right destination — a browser extension or a simple script makes this a ten-minute job. Also confirm the redirects don't chain (old → older → new).
2. Re-verify every form. Submit each one and confirm the submission arrives where the inventory said it must. This step takes twenty minutes and catches the most embarrassing category of silent failure — the contact form that looks perfect and emails no one.
3. Check the unglamorous infrastructure: the XML sitemap regenerated with new URLs and submitted to Search Console; robots.txt no longer blocking anything (staging blocks have shipped to production more than once in the history of the web); analytics tracking firing on the new pages; SSL valid on every path.
4. Crawl the live site one more time, hunting for 404s, staging-domain links, and missing images.

Then watch for two weeks

Migration problems surface on a delay. For the first two weeks post-launch, check daily: Search Console's coverage and 404 reports (this is where you find the URLs your inventory missed — there are always a few), organic traffic against the pre-launch baseline, and form submission volume. A modest, temporary dip in search traffic after a large migration is normal as search engines reprocess the site; a cliff that doesn't recover within a few weeks means something in the redirect layer is wrong, and the 404 report will usually tell you what. Keep the old site's files and database backed up for at least three months — they're your reference copy when someone asks where that old warranty PDF went.

The short version, for your project plan

The honest conclusion

Nobody gives you this checklist because nobody profits from it. The redesign's exciting deliverables are the homepage mockups, and that's where attention and budget flow. But your search rankings, your customers' bookmarks, and that Monday-morning spreadsheet in accounting all live in the boring line item. Treat migration as a third of the project, produce the redirect map as a real deliverable someone signs off on, and test the forms twice. The reward for doing this well is that nobody notices anything happened — which is, in this one corner of the project, the definition of success.

Photo: Darlene Alderson on Pexels