The CMS migration risks that actually cost people money are rarely the ones they worry about. Owners worry about losing content. But content is the easiest part, because it is text and images, and both transfer reliably. Everything attached to the content breaks instead. Start with the addresses it lived at, then the forms it carried. Next come the settings that told search engines what it was, plus the integrations that quietly depended on it. So this guide covers what fails, in the order it usually fails, and how to catch each one early.
Why the free plugin is not the whole job
Every platform pair has an import tool, and most of them work. If you are moving from Joomla, Drupal or a builder, a plugin will very likely carry your posts and pages across.
So it is fair to ask why anyone pays for a migration. The plugin performs the one step that was never risky. It moves content. What it does not do is decide your new addresses, or write the redirects that protect them. Nor does it rebuild your forms or reconnect your analytics. And three weeks later it will not notice that nobody ever crawled a section of the site. Those steps are the job, and they are where migrations go wrong.
In other words, use the plugin. Just do not mistake it for the plan.
Addresses and redirects, the failure that costs traffic
Why addresses matter more than content
This is the first and most damaging of all the cms migration risks, so it deserves the most attention.
Your old platform generated addresses in its own style. Your new one will generate different ones. Meanwhile every link anyone ever made to your site, every bookmark, and every result sitting in a search engine still points at the old form. Without a redirect, all of them land on a page that does not exist.
A redirect carries most of an address’s accumulated standing to its replacement. That is why the redirect map is the highest-value artefact of a migration. Write it before launch, not after. Build it from a real list of your existing addresses rather than from memory.
The two redirect mistakes that recur
Two mistakes recur. First, mapping only the pages someone remembered, which strands older posts and attachment pages. Second, redirecting everything to the homepage. Search engines treat that as equivalent to a missing page, and it strands the visitor just as effectively as an error would. So map each address to its closest genuine equivalent. Where no equivalent exists, say so deliberately rather than by accident. Google’s site move guidance is the reference worth following here.
Search settings are content, and they do not travel
A person wrote your titles and meta descriptions. Whatever handled search settings on the old platform stored them. Import tools almost never carry them.
So a migrated site frequently launches with every title regenerated from the page heading. The pages still exist and still rank for a while. But the thing that persuaded people to click has become a default. Because the content itself looks fine, owners usually notice this months later, as a slow decline rather than a breakage.
Export the old titles and descriptions before the move, then reapply them. If nobody ever wrote them, treat the migration as the moment to write them rather than the moment to lose them.
Forms, and the money that stops arriving
Forms are platform features rather than content, so somebody rebuilds them rather than moving them. That much is expected. The part that follows is not.
A rebuilt form has to reach wherever its submissions went. An inbox, a CRM, a notification address. Each of those is a separate setting, and each fails silently. A broken contact form produces no error anybody sees. It produces an absence of enquiries that looks like a quiet month.
So the test is not whether the form submits. The test is whether a submission arrives at the destination, from a real browser, after launch, with somebody confirming receipt. Do that for every form, including the ones nobody thinks matter.
If money moves through the site, the same logic applies with more urgency. Our guide on diagnosing a broken checkout covers testing the order path properly.
The cms migration risks that disconnect quietly
Beyond the three big failures, a predictable set of smaller cms migration risks recurs. Each one fails without announcing itself.
- Analytics. Tracking code lives in the old theme. Lose it and you cannot tell whether the migration went well, which is exactly when you need the data.
- Search console. The new setup usually needs reverification, and somebody has to declare the change of address.
- Images and internal links. Both frequently still point at the old location. That works right up until somebody switches the old site off.
- Email sending. A new host means a new sending path. So notifications and receipts can stop reaching inboxes even though the site works.
- Anything on a schedule. Scheduled publishing, syncs and automated reports do not migrate themselves.
Email in particular deserves a test rather than an assumption. Our guide on tracing the delivery chain sets out how to check it link by link.
The launch-day mistake that removes your safety net
The most avoidable failure is switching the old site off too early.
While the old platform still runs, almost any discovery stays recoverable. You can read a missed page, look up a lost setting, or download an image again. Once the old site goes, each of those becomes a reconstruction job. On some platforms it becomes impossible, because nobody ever had an export.
So keep the old site available, in whatever read-only form the platform allows, until you feel confident. Where the old platform holds your redirects, as builders typically do, keeping the subscription active is not optional at all. Cancelling removes the redirects protecting your traffic during precisely the weeks they matter most.
How to verify a migration properly
Verification separates a finished migration from a launched one. Therefore work through these in order, because each step depends on the one above it.
- Crawl the old site before launch and keep the address list. Everything else takes that as input.
- Check every old address resolves after launch, and lands somewhere sensible rather than the homepage.
- Compare titles and descriptions against the pre-launch export, page by page.
- Submit every form and confirm it arrives at the destination.
- Confirm tracking fires on a real page view.
- Watch the error report weekly for a month. Most migration damage surfaces in the second and third week, not on launch day.
People skip that last point most often. A migration verified only on launch day has been checked at the single moment when the fewest problems have appeared.
Deciding whether to migrate at all
Everything above is the cost side of the decision, so weigh it before committing. A migration earns its price when the current platform genuinely blocks something you need. It does not when the real problem is that nobody has maintained the site, because that problem transfers intact.
If you are weighing a move in either direction, the companion guides cover both: whether leaving WordPress is the right call, and what a builder migration actually costs.
Once a site has moved, the maintenance obligation is real and continuous. So settle ongoing care before launch rather than after the first incident. Would you rather know what your specific migration involves first? Start a diagnosis and you get the risks in writing, along with our published scope so you can see where we draw the line.