The best migration I've been part of didn't give us much to talk about. Every status update said some version of the same thing: we're on schedule, no issues, same scope, same timeline. There was no war story at the end, and nobody wrote it up as a case study.
For a long time, "it was fine" felt like a weak answer when people asked how it went. I don't think that anymore. If a migration gives you good stories, someone is usually still cleaning up after it.
The ones I've seen go badly mostly didn't fail on budget or technology. Plenty of them launched on time, and the trouble only showed up afterwards, when it became clear nobody had agreed on what "done" meant.
The question nobody answers out loud
Ask five people on a migration what success looks like and you'll get five answers.
The CMO, IT, legal, the brand team and the agency all want something different.
None of those are wrong, but they aren't the same project. If nobody pulls them into one definition, each group measures the migration against its own, and the day after launch you get five different opinions on whether it worked.
"Done" isn't "the new site is live." It's a short list of things that should be true after launch: pages moved with their URLs intact, the team can publish without a developer, compliance is built in rather than bolted on, and the platform can take the next few sites, not just this one.
Write that list down before anyone picks a CMS. It's the cheapest document you'll produce on the whole project, and it's the one that settles arguments later.
Seven signs it's going to hurt
After enough of these, you start to see trouble coming. Here's what I watch for.
1. Nobody has defined done
That's the one above, and it's behind most of the others.
2. The platform was chosen before the requirements existed
Maybe someone liked a demo, a sister market already had a licence, or procurement had a deadline. Either way, the requirements get bent to fit the tool, and you spend the next year working around the gap.
3. Nobody owns the content inventory
Everyone assumes the content is "basically fine" until someone counts it. Then you find thousands of pages, legal copy nobody can trace, several languages and assets in four different places. It's the most underestimated line item in every migration plan I've seen.
4. UAT is treated as a phase at the end
If testing only starts once the build is done, it's really a damage report. UAT needs to run alongside the build, with people who know what the site is supposed to do, not just whether the page loads.
5. Compliance is a launch gate instead of a build input
Age gates, market restrictions, responsible-marketing rules and accessibility all have to be designed in. WebAIM's latest scan found accessibility failures on 95.9% of the top million homepages, so this isn't a niche problem. If these only show up at the end, you rebuild.
6. The platform doesn't match the team's maturity
Hardly anyone talks about this one, and it decides more migrations than the technology does. Hand a headless stack to a team with no content operations and they'll go back to asking a developer for every change. The right platform is the one your team can use on a normal Tuesday.
7. The migration is scoped as an ending
If nobody asks what gets built on it next, the foundation fits exactly one site and the second one starts from scratch.
What boring looks like in practice
We've supported Diageo's digital properties for over a decade, across four platform generations. We saw the migration from before, during and for years after, which is when you actually find out whether it worked.
The old platform had real problems. It didn't have full CMS capability, so routine changes needed engineering, it hadn't kept up with compliance requirements, and it cost more to run than it should have.
We handled the migration directly on three sites: zacaparum.com, stitzelwellerdistillery.com and thegoodcraftco.com. On around fifteen others, including Baileys, Captain Morgan, Ketel One, Smirnoff, Bulleit, Don Julio, Casamigos, Tanqueray and Crown Royal, we wrote the requirements and ran UAT.
The bigger change was day to day. Product, recipe and campaign updates moved from engineering tickets to content tasks, because we rebuilt the components and templates around what the team publishes. Infrastructure costs came down too, which is the part finance notices and marketing usually doesn't.
Speed matters more than it sounds. Google's research with Deloitte found that taking a tenth of a second off mobile load time lifted retail conversion by 8.4%.
There's one more thing that rarely makes it into a case study. On a large migration, a thorough UAT pass can turn up hundreds of issues before launch. That sounds alarming until you ask the only question that really matters, which is how many of them reach a consumer.
None, if UAT is doing its job.
That's what it's for, and it's what the boring version buys you. Issues get found by people whose job is to find them, while they're still cheap to fix. No migration has zero issues. The real choice is whether you find them before launch or after, in public, with a campaign already pointing people at the page.
The same principle, a very different company
Diageo is a global portfolio with decades of digital history. RAD Intel is a very different business, but its migration came down to the same question.
They were on HubSpot CMS, which was fine for the site they had but couldn't handle what came next: more brands, more sites, more acquisitions.
We moved radintel.ai to Contentful, and the bigger payoff came afterwards. The same setup has since supported three more sites: lickly.com and radamplify.com are live, and a third is built and waiting on approval to launch.
RAD Intel cared most about getting their own team running the site without going through anyone. They were earlier on the maturity curve, so "done" meant something different, and the right answer for them would have been the wrong one for Diageo. Pick the platform once you know who's going to use it and what you're building next, or you can end up with a very good tool that nobody touches.
Three questions before you start
Migrations get sold as technology projects and budgeted as one-off costs. But most of the hard parts are decisions about who owns what, usually made early by whoever happens to be in the room, and it's rarely a one-off cost. You'll either build on the platform for years or end up rebuilding it a lot sooner than you planned.
So before asking what it'll cost or which platform to pick, I'd ask these three:
- What will be true after launch that isn't true today?
- Who publishes on this platform on a normal Tuesday, and can they?
- What's the second thing we'll build on it?
I put a version of that last one in a proposal recently. We'll migrate N sites for you, but what matters just as much is what you do on site N+1.
A platform that consolidates N sites and then makes the next one just as hard has solved the wrong problem.
If you can answer those three, your migration will probably be boring. Take it.
Planning a migration?
Thorium Digital builds and consolidates enterprise websites for multi-brand and regulated businesses. If you're evaluating a migration, choosing a CMS or consolidating sites, we can help you work through the requirements, spot the risks and build a roadmap before you commit to a platform.
Make launch day boring.
