A CMS migration is one of the few projects where the technical work can go perfectly and the outcome still be a disaster. The site launches on time, looks better, loads faster, and traffic falls by half, because a few hundred URLs changed shape and nobody built the map.

The traffic loss is not caused by the new platform. It is caused by discontinuity: addresses that used to resolve now do not, pages that used to be identifiable now look new, and accumulated history attached to old URLs has nowhere to go.

The single decision that determines the outcome: are you keeping the URL structure? If yes, the migration is mostly a content and template exercise and the risk is modest. If no, every changed address needs a redirect to its specific equivalent, and the completeness of that map is what decides whether the migration is invisible or expensive. There is no third option where the URLs change and it works out.

What a CMS Migration Actually Breaks

URLs, which is the big one. Different platforms have different conventions for paths, pagination, categories and dates, and adopting the new platform’s defaults silently rewrites every address on the site.

Metadata. Titles and descriptions written over years frequently do not survive an export, and the new platform generates them from templates instead. This is easy to miss because the pages look fine.

Structured data. Markup added by a plugin on the old platform disappears with the plugin, and the new equivalents rarely emit identical output. Our guide to how AI search engines read schema markup covers what needs to survive.

Internal links. Body content full of absolute links to old paths will keep pointing at them, which after a URL change means every one of them travels through a redirect at best.

Images and media. Different storage paths, different file names, and alternative text that lived in the old database and was not in the export.

Anything a plugin was doing. Redirects configured over years, canonical rules, feed formats, and functionality nobody documented because it was a checkbox.

Inventory all of this before the migration, not after. The list of what the old platform quietly does for you is always longer than expected.

The Redirect Map Decides Everything

If URLs change, this is the deliverable that matters, and it needs to be complete rather than nearly complete.

Build the source list from more than one place. A crawl of the live site finds what is linked. Your analytics and Search Console find pages that receive traffic but may be orphaned. Server logs find what is actually requested, including by other sites linking to you. Any single source misses things, and the pages missed are disproportionately the old ones with links attached.

Map each old URL to its specific new equivalent. Not to the homepage, and not to a category page, because a redirect to something that does not answer the original request is treated as a soft error and passes little value. Google’s site move documentation sets out the mapping it expects. If genuinely nothing corresponds, returning a not-found response is the honest answer and better than a misleading redirect.

Use permanent redirects, keep chains to a single hop by pointing old addresses directly at final destinations, and remember that redirect rules are evaluated in order, so a broad pattern placed above a specific rule will swallow it.

Then test the map before launch, against the full list rather than a sample.

Before You Switch

Crawl and archive the old site. A complete record of every URL with its title, description, canonical, status code and word count. This is your comparison baseline and you cannot produce it after the fact.

Export and verify the content. Check counts, not just that the export ran. Missing categories, dropped custom fields and truncated posts are all common and all silent.

Stage it on a blocked environment. A staging site that gets indexed creates duplicates of your entire site, which is a worse problem than the one you were solving.

Check the new templates emit what the old ones did. Titles, descriptions, canonicals, structured data, hreflang if you run multiple languages, as covered in our multilingual SEO guide.

Plan the timing. Not before your busiest period, and not on a Friday. You want several working days of attention immediately afterwards.

After You Switch

The first forty-eight hours matter more than the following month, because that is when a fixable error is still cheap.

Watch server logs for not-found responses. This is the fastest way to find the URLs your map missed, and it finds them from real requests rather than from your assumptions. Submit the new sitemap, and check that crawling is actually happening rather than assuming it.

Compare against the baseline crawl. Every URL that was indexable before should now either resolve or redirect somewhere specific. Any that does neither is a hole.

Expect a dip. Some fluctuation for a few weeks is normal even on a well-executed migration, because the new addresses have to be recrawled and reassessed. What is not normal is a sustained fall that does not recover, and that almost always traces back to redirects that were missed or pointed somewhere generic.

Keep the redirects permanently. They are not a transitional measure, they are the only thing connecting years of accumulated links to your current pages, and removing them a year later reproduces the original loss.

Mecanik handles migrations of this kind as part of our website development work. The pattern is consistent: the platform change is routine, and the difference between a good outcome and a bad one is entirely in the completeness of the map.

Frequently Asked Questions

Why does traffic drop after a CMS migration? Almost always because URLs changed and the redirect map was incomplete. Old addresses stop resolving, so years of accumulated links and crawl history have nowhere to go. The platform itself rarely causes the loss; discontinuity between old and new addresses does.

Should I keep my URL structure when changing CMS? If you can, yes. Keeping the structure reduces the migration to a content and template exercise with modest risk. Changing it means every altered address needs a redirect to its specific equivalent, and the completeness of that mapping determines whether the migration is invisible or expensive.

Where do I get the list of URLs to redirect? From several sources, because each one misses things. A crawl of the live site finds linked pages, analytics and Search Console find pages receiving traffic that may be orphaned, and server logs find what is actually requested including from external links. Pages missed by a single source tend to be old ones with links attached.

Can I redirect old pages to the homepage? No. A redirect to something that does not answer the original request is treated as a soft error and passes little value. Map each old URL to its specific equivalent, and where nothing genuinely corresponds, returning a not-found response is more honest and more useful than a misleading redirect.

How long should migration redirects stay in place? Permanently. They are not a transitional measure but the only connection between years of accumulated inbound links and your current pages, so removing them a year later reproduces exactly the traffic loss the migration was supposed to avoid.