The guide
CMS migration plan: the phases, and what breaks in each
A CMS migration plan has five phases, and they have to happen in this order: inventory every URL, decide what deserves to move, build the redirect map, check what the new templates emit, then cut over in sections. Each one exists because skipping it breaks the next.
Every migration post-mortem I have read arrives at the same sentence somewhere near the middle: the build went fine. Nobody writes up a replatform that fell over because the code did not compile. They write up the one where everything passed, everyone went home, and the traffic quietly left over the following six weeks. That is what this plan is built to prevent. Where there is a number, it comes from our own measurements of 27,385 live sites, and you can download the data and check it.
The plan, phase by phase
Five phases, in the order their dependencies force. Read the summaries in twenty seconds; open any one for the detail and the measurements behind it.
Inventory every URL you have
The complete list, not the CMS export — including the PDFs and campaign pages nobody has opened since 2019.
Skip it and you cannot redirect a page you never knew was there, and every later decision is made on a partial list.
Go deeper
The most expensive mistake in a replatform is trusting the CMS export as the list of what exists. It is a list of what the CMS knows about, which is a different thing. Campaign landing pages, old PDFs, paginated archives and pages built by a plugin that left three years ago all live outside it, and search engines have been happily indexing them the whole time.
Build the real list from a union of sources: server logs, Search Console, a full crawl, and your backlink profile.
Decide what deserves to move
Content migration is a decision, not a transfer. Score each page: move as-is, rewrite on the way, or retire.
Skip it and you pay full price to move pages you will delete, and the scope never shrinks.
Go deeper
Content that earns nothing costs exactly as much to migrate as content that earns everything. Most estates carry more of the former than anyone expects, and the cheapest hour in the whole project is the one spent deciding, page by page, what moves as-is, what gets rewritten on the way, and what quietly retires with a 410.
Do this before the transfer is scoped and the scope shrinks. Do it after, and you have paid to move things you then delete.
Build the redirect map as a test suite
Every old URL, its destination, and an assertion that it lands there in one hop. Runnable, not a spreadsheet.
Skip it and chains and loops survive launch day, because nothing about them looks broken to a human clicking around.
Go deeper
A redirect map is not a spreadsheet you hand over at the end, it is a thing you run. Every old URL, its intended destination, and an assertion that it lands there with a single 301 rather than a chain.
Run it against staging, run it again immediately after cutover, and keep running it for a month.
Check what the new templates emit
Structured data, canonicals and security headers come from templates — and templates are what a migration replaces.
Skip it and the pages look perfect while answer engines quietly stop being able to describe them.
Go deeper
This is the one nobody thinks to check, because the content looks right. Structured data, canonical tags, Open Graph, hreflang and the security headers are all emitted by templates, and templates are exactly what a migration replaces. Content that carried schema on the old platform arrives on the new one carrying none.
Diff the rendered output of your top pages, old against new, before anyone celebrates.
Cut over in sections, keep the old thing serving
Move a section at a time and leave the previous platform up until the redirect suite has been green long enough to be boring.
Skip it and a big-bang cutover is easy to put on a slide and very hard to reverse at 2am.
Go deeper
Big-bang cutovers are popular because they are easy to put on a slide. Moving a section at a time is slower, less satisfying, and dramatically easier to reverse when something is wrong, which it will be.
What a CMS migration project actually involves
It is three jobs wearing one name. You move the content. You rebuild the templates that present it. And you preserve the URLs that every link, bookmark, citation and search result in the world already points at. Project plans tend to budget carefully for the first, generously for the second, and treat the third as a task somebody picks up in launch week. That ordering is precisely backwards, and it is the single most reliable predictor of how the first month after go-live goes.
Why the platform you pick matters less than you think
When we measured readiness across 27,385 sites, WordPress and Drupal landed within a point of each other overall, 75.4 against 76.2. If you are choosing between them expecting one to hand you a readier site, the data does not support it. What differs is which half each one is bad at. WordPress sites carry 2.6× more structured data than Drupal sites; Drupal sites are 2.4× more likely to ship security headers. You are not choosing a quality level, you are choosing which blind spot you inherit.
Two platforms, inverted strengths
Tied on overall readiness (75.4% against 76.2%), and almost perfectly opposed underneath it. WordPress carries 2.6× more structured data, while Drupal is 2.4× more likely to ship security headers.
Structured data
Security headers
The pattern holds outside the commercial web too. Across 9,324 government sites, Drupal averaged 71.6 against WordPress on 61.7, and the gap was almost entirely the same two signals. Defaults, not effort, drive most of it. Which is good news: defaults are something you can check for before you sign anything.
What a template rebuild puts at risk
Phase four above is the one nobody thinks to check, because the content looks right. These are the signals that come from templates rather than content, measured across the whole sample, so you can see how commonly each is already missing before anyone rebuilds anything.
The signals a template rebuild puts at risk
These are emitted by templates, not by content, so they are exactly what a migration replaces. Even across the whole measured web, half of sites ship no structured data at all — and a rebuild is the most common moment for the other half to lose theirs.
Canonical tag
decides which URL survives
Open Graph
how links preview when shared
Structured data
how answer engines describe you
Security headers
set by the platform, not the page
So what would I actually do?
If I were handed one afternoon on a replatform and told to spend it wherever it did the most good, I would not spend it comparing platforms. I would spend it building the complete URL inventory, because every other decision in the project gets better once that list exists and worse while it does not. A mediocre plan applied to a complete inventory beats an immaculate plan applied to a partial one, every time.
And then I would go and look at what my current site is actually emitting, rather than what I assume it emits. That is the part people skip, and it is the part that shows up six weeks later as a line on a traffic graph that nobody can explain.
Want the eleven signals scored on your own site before you commit to anything? The instant grade reads your homepage in about a minute, free, no signup.
Grade my site →Frequently asked questions
What should a CMS migration project plan include?
Five phases, in dependency order: a complete URL inventory, a page-by-page decision about what moves, a redirect map built as a runnable test suite, a check of what the new templates emit before content goes in, and a phased cutover with the old platform still serving. Plans that list deliverables instead of dependencies tend to reorder themselves under pressure, and the phase that gets dropped is almost always the inventory.
What is content migration in a CMS project?
Moving the pages, assets and metadata themselves, as distinct from rebuilding the templates that display them. It is the phase most often budgeted by volume and it should be budgeted by decision: content that earns nothing costs the same to migrate as content that earns everything. A migration is the only moment when deleting pages is cheap and nobody argues about it.
What is a CMS migration?
Moving a website's content and structure from one content management system to another. In practice it is three jobs wearing one name: moving the content, rebuilding the templates that present it, and preserving the URLs that everything else in the world already points at. The third is the one that loses traffic.
How long does a CMS migration take?
For a marketing estate of a few thousand pages, three to six months is typical, and most of that is content modelling and template rebuild rather than the transfer itself. The transfer is usually the fastest part, which is why schedules built around it tend to slip.
Does a CMS migration hurt SEO?
It does not have to. Traffic loss after a replatform is almost always caused by a specific, findable thing: URLs that changed without redirects, structured data the new templates stopped emitting, or pages that were never in the export because nobody had a complete inventory. All three are checkable before launch.
Should I migrate everything at once?
Rarely. Content that earns nothing costs the same to migrate as content that earns everything, and most estates carry a surprising amount of the former. Deciding page by page what moves, what gets rewritten and what gets retired is usually the single biggest reduction in scope available.
How do I stop links breaking during a migration?
Build the redirect map from a union of sources rather than a CMS export: server logs, Search Console, a full crawl and your backlink profile. Exports routinely miss campaign landing pages, old PDFs and paginated archives that search engines have happily indexed for years. You cannot redirect a page you never knew existed.
Is a CMS migration the same as a redesign?
No, though they are often sold together and that is where budgets go missing. A migration changes the system underneath; a redesign changes what visitors see. Doing both at once means that when traffic moves, you cannot tell which change caused it.
Keep reading
The migration guides cover specific platform pairs in depth, with what moves and what has to be rebuilt for each. The underlying study has the full method and the open dataset behind every number on this page. And the redirect mapping field guide goes considerably deeper on the inventory problem than this page does.