Every B2B marketing leader has lived through this once. The CMS migration that was supposed to take three months. The launch date that slipped, then slipped again. The post-launch traffic dip that lasted six months. The expensive new platform that does roughly what the old one did, just slower.
Replatforming is one of the few projects in marketing where the default outcome is failure. Not catastrophic failure — the site usually ships. But late, over budget, and shipping something nobody's particularly proud of. Sometimes the team that started the project has been reshuffled by the time it launches.
It doesn't have to be like this. The teams that get CMS migrations right are doing four things differently from everyone else. None of them are technical. All of them are about what you decide before the engineering starts.
The CMS migration that fails isn't the one that picks the wrong platform. It's the one that didn't freeze scope.First — why these projects go wrong
The four failure modes
If you've been on a CMS migration that went badly, you'll recognise at least one of these. Most projects hit two or three.
Scope grows during the build
The project kicks off with a clean scope — 80 pages, 6 templates, 4 content types. Three months in, someone notices the campaign microsite isn't on the list. Then product wants a comparison feature. Then sales wants a new partner portal. Each individual ask sounds reasonable. By month six, the scope has doubled but the timeline hasn't, so something has to give. Usually it's quality, or the launch date, or both.
The fix is brutal and political: every scope change after kickoff costs time and money, and that has to be visible. No "quick additions." No "we can squeeze that in." If the comparison feature is critical, it goes in. But it goes in with a new launch date attached. The team's job is to defend the original scope, not to absorb new asks silently.
The team picks the platform before they know what they need
Most CMS selections start with a vendor demo. Three platforms, three slick presentations, a feature comparison spreadsheet. The team picks one based on what looks impressive in the demo. Six months later they realise they bought the wrong tool for the job they actually have.
The fix is to write a one-page brief before you take a single demo. What does your marketing team need to do on this CMS, every week, for the next three years? What kinds of pages? What workflow? What integrations matter? Who's editing — your designers, your content writers, your engineers, your partners? Most of the platform decision falls out of those answers. Demo the shortlist of two that match, not the marketed shortlist of five that don't.
Content migration is treated as an afterthought
The engineering team designs the new templates. Six weeks before launch, someone asks "where's the content?" and discovers there are 1,800 pages that need to be either migrated, rewritten, or retired. Nobody has a plan, nobody owns it, and there's no time to do it properly. The launch slips. Or it ships with broken pages.
The fix is to do a full content audit before kickoff. Every URL, with traffic, conversions, and a decision: migrate as-is, rewrite, or retire. Most teams find 60-80% of their old content is dead weight that should be retired. A leaner site post-migration usually performs better, but only if you've made the calls deliberately.
SEO is bolted on at the end
The most painful failure mode. The new site launches. Traffic drops 40% in the first two weeks. The team scrambles. Redirects were missing or wrong. URL structures changed. Schema markup was lost. Six months of organic traffic disappears overnight and takes 12-18 months to recover, if it recovers at all.
The fix is to write the redirect map before the build starts. Every URL, mapped to its new home or explicitly retired. SEO sits at the kickoff meeting, not the launch meeting. Plan for a 4-8 week dip even if you've done it well — but the difference between a 4-week dip and a 6-month collapse is whether you treated SEO as a feature, not an afterthought.
The scope you start with is the scope you ship — or you don't ship at all. Treat it as a contract, not a starting point.Second — what the good ones do differently
The quiet way to get it right
Teams that ship CMS migrations on time and on budget aren't smarter than the ones that don't. They're more disciplined about a small number of decisions, made early.
1. Frozen scope: page count, template count, integration count, all signed off before engineering starts.
2. Content audit first: every URL classified — migrate, rewrite, retire — before the new templates are designed.
3. Redirect map at kickoff: SEO involved from day one, not week 24.
4. One platform decision-maker: not a committee. Someone whose neck is on the line if the choice is wrong.
These sound mundane. They are. That's the point. Most CMS migrations fail because of mundane things — scope creep, content drift, missing redirects, platform tourism. The exciting parts of a build (design, animation, technical architecture) are rarely where projects die. They die in the boring stuff that nobody wanted to own.
One more thing: small launches beat big ones
If you can, don't launch the whole site at once. Launch the new CMS with a subset of pages — maybe the blog, or the resource centre, or a new product section — and migrate the rest in phases over the following months. This does two things. It forces the team to use the new tools and surface real problems before the whole site depends on it. And it spreads the SEO risk: a partial migration with a 10% dip is recoverable. A full migration with a 40% dip is a board-level conversation.
Phased launches feel slower. They're actually faster, because they let you fix problems while the stakes are small. Big-bang launches feel decisive. They almost always create months of unplanned work to fix what shipped broken.
Boring decisions, made early. That's the whole game.
If you're at the start of a CMS migration, the next thing you do shouldn't be a vendor demo. It should be the one-page brief: what does your team need to do, every week, for the next three years? Get that right and most of the rest falls into place. Skip it and no platform on earth will save the project.