A CMS migration checklist that covers what actually breaks

Most migrations fail in the same few places. This is the order to do things in, and what goes wrong at each step.

Before you move anything

1. Export a full list of your current URLs. Not the ones in your menu — every URL that exists. Crawl the site, and pull the list from your analytics and from Search Console as well, because each source will show URLs the others miss.
2. Find out which of them get traffic or have links. This decides what must survive. A page with fifty referring domains matters more than a hundred pages with none.
3. Write down your content types. Not “we have a blog” but the actual structures: which fields exist, which are used, which are empty on every record.
4. Take a backup you have tested. An untested backup is a hope, not a backup.

Step one is where most of the pain comes from later. If you do not have the URL list before the move, you cannot tell what broke after it.

Mapping the content

Take your content types and write down what each becomes on the new platform. Do it on paper before touching a tool. Three things always need a decision:

• Fields with no equivalent. Every migration has some. Decide now whether they get rebuilt, merged into the body, or dropped.
• Taxonomies. Category structures rarely match. Nested categories going into a flat system need a plan.
• Media. Files and their database records are separate problems. Moving one without the other gives you broken images or orphaned files.

See the platform reference for how individual systems structure content.

URLs and redirects

If URLs change, every old one needs a 301 to its closest equivalent. This is the step people rush and regret.

• Map old to new individually. Redirecting everything to the homepage throws away whatever those pages had earned.
• Watch for chains. A pointing to B pointing to C. Point A at C.
• Check trailing slashes. A mismatch produces an extra hop on every request.
• Use 301, not 302. A 302 tells search engines to keep the old URL. See 301 redirects in WordPress.

If you can keep the URLs identical, do that instead. It is always less work than redirecting them.

Before going live

1. Check the new site is not blocking crawlers. Staging sites get noindex tags and password protection, and both get forgotten. In WordPress, make sure “Discourage search engines from indexing this site” is unticked on the Reading Settings screen. A migration that goes live with staging settings still on is a common and expensive mistake.
2. Spot-check your highest-value pages by hand. Not a sample — the specific pages you identified in step two.
3. Test the redirects. Every one should be a single 301 to a page returning 200.
4. Check the internal links. Links inside content often still point at old paths.
5. Confirm analytics is installed and firing on the new site, or you will be blind exactly when you need data.

After going live

Expect a dip. Even a clean migration usually loses some visibility for a few weeks while search engines recrawl and reassign what they know. The question is whether it recovers.

• Submit a sitemap of the new URLs straight away
• Watch for 404s in your server logs and in Search Console for at least a month — that is where you find the URLs you missed
• Compare page by page, not site totals. Averages hide the specific pages that dropped
• Leave the redirects in place permanently. Removing them after a few months undoes the work

The three that cause most of the damage

In rough order of how often they happen: no URL inventory taken beforehand, so nobody can tell what broke. Redirects pointed at the homepage instead of matching pages. And staging’s noindex left on after launch.

None of the three is technically difficult. All three are easy to skip under time pressure, which is exactly when migrations happen.