£120,000. That's the number a managing partner at a 200-person consultancy told me he'd approved for a CMS migration last year. His agency had scoped it, the proposal looked thorough, and the timeline said five months. Seemed reasonable.
Nine months and £230,000 later, they launched. Nobody had done anything wrong, exactly. The agency wasn't incompetent. The scope wasn't reckless. But the budget was built on what was visible at the point of estimation - and roughly half the actual cost was hiding in places that only became visible once the work started.
I'm telling you that story because it's the median outcome, not the outlier. And the reason it keeps happening isn't that agencies are dishonest or that boards are naive. The specific factors that inflate cost and timeline are almost always invisible at the point of budget approval. They only surface after discovery work has begun.
So this is my attempt to lay out what a CMS migration actually costs and takes, based on what we've seen across well over a hundred migrations at Distinction. Not a price list - I can't tell you what yours will cost without understanding your content estate, integrations, and internal complexity. But I can give you ranges that are more honest than most proposals, and a heads-up on the budget surprises that catch nearly everyone.
Every migration we've worked on falls broadly into one of three complexity categories. The defining factor isn't the platform you're moving to - it's the complexity of what you're moving from and what needs to change along the way.
Simple migration: 3-4 months, £40,000-£90,000
A platform modernisation with a relatively clean starting point. Fewer than 500 pages of content. One or two straightforward integrations - analytics, basic forms, maybe a simple email marketing connection. No significant custom functionality to rebuild. A small editorial team with straightforward training needs.
Genuinely simple migrations are rarer than people think. Firms assume they're in this category because their site looks simple, but the content estate underneath often tells a different story. Still, they exist. We did one last year for a specialist advisory firm - 180 pages, one CRM integration, clean content. In and out in fourteen weeks, came in under £60k. But I'd say that's the exception, not the rule.
Moderate migration: 5-8 months, £90,000-£250,000
This is the most common category for mid-market professional services firms, and the one where budget surprises are most frequent. You're looking at 500 to 5,000 pages of content with moderate structural complexity. Two to four integrations of meaningful complexity - CRM, marketing automation, document management. Some custom functionality to rebuild. And, almost without exception, a discovery phase that surfaces unexpected complexity in at least one area.
I've never seen a moderate migration where discovery didn't reveal something that wasn't in the original estimate. Sometimes the content is more tangled than the audit suggested. Sometimes an integration that looked like a simple API connection turns out to involve custom field mapping and bi-directional sync. Sometimes the editorial team needs a fundamentally different content model, not just a new CMS. That last one tends to be the most expensive surprise, because it touches everything.
Complex migration: 9-15 months, £250,000-£600,000+
Large, legacy-heavy migrations with significant structural and integration complexity. 5,000+ pages of content, often in multiple formats. Four or more complex integrations. Significant custom functionality. Multiple stakeholder groups requiring change management. Sometimes a phased delivery requirement that extends the programme timeline on its own.
The plus sign after £600,000 is doing real work in that range. I've seen complex migrations in financial services and legal run well past that figure, particularly when regulatory compliance requirements or data governance add layers that weren't fully scoped at the outset. One financial services client came to us after a previous agency had quoted £350k for what was, in reality, a £700k programme. That gap wasn't dishonesty. It was just a scope that hadn't been properly discovered.
These ranges are based on Distinction's direct migration experience in professional services. They exclude VAT and internal client resource costs, which you should budget separately. And a well-managed project in the right complexity category absolutely can come in at the lower end of these ranges. The ranges represent the realistic distribution, not a guarantee you'll end up at the top.
1. Content migration takes two to three times longer than estimated
This is, without question, the most consistently underestimated cost line in CMS migration. Every single time.
Your content audit says 1,200 pages. Fine. But those 1,200 pages exist in varying states of quality, structure, and format. There are embedded PDFs that need extracting. Bespoke components that the migration tool can't handle automatically. Legacy HTML that renders perfectly on the old platform and breaks completely on the new one. Images stored at seven different sizes with no consistent naming convention. Metadata that's either missing or wrong.
I sat with a project manager last year who'd estimated content migration at three weeks for a 2,000-page site. It took nine. Not because anyone was slow - because the content was a mess in ways that weren't visible until they started moving it. The site looked perfectly presentable from the outside. Underneath, it was chaos.
2. Integration complexity that wasn't visible at estimate stage
An integration described as "connecting to Salesforce" may involve three API endpoints, custom field mapping, bi-directional sync, error handling, and data transformation rules that only become clear during technical discovery. The gap between "we need a Salesforce integration" and a working, reliable integration in production is enormous. And it's genuinely hard to estimate accurately without doing the discovery work first.
We worked with a law firm where the CRM integration was scoped at two weeks. It took six. Their Salesforce instance had been customised so heavily over eight years that the standard connector couldn't handle their data model. That's not unusual. That's typical.
3. Internal resource requirements that weren't budgeted
This one's slightly awkward to raise, but it matters. Your team's time is a real project cost. Stakeholder interviews, content review and sign-off, testing, decision-making at key governance points - all of this takes time from people who have day jobs. None of it appears in your agency's estimate, because it's not their cost.
But it absolutely affects the timeline. I've seen projects slip by weeks - sometimes months - because the client's senior stakeholders weren't available for decisions at the points where decisions were needed. That's not a criticism. Everyone's busy. But if you're not budgeting internal time as a real resource requirement, you're building a plan that assumes your people have capacity they probably don't.
4. SEO preservation work
Every URL that changes in a migration needs a redirect. For a content-heavy site, the redirect mapping, canonical tag implementation, and content structure decisions required to preserve your organic search rankings represent a meaningful piece of work - typically 3-8% of the total project cost. Skip it or rush it, and you'll watch your search traffic fall off a cliff in the weeks after launch.
I've seen firms lose 40% of their organic traffic post-migration because nobody budgeted properly for this. It took months to recover. And the brutal irony is that the SEO work is usually the first thing that gets squeezed when the budget's tight - which is precisely when it matters most.
5. Post-launch optimisation
No migration launches perfectly. Real user behaviour reveals things that testing didn't catch. Forms that work but frustrate. Navigation paths that make sense to the team but not to actual clients. Performance issues under realistic load. Content that reads differently in the new template.
Budget 15-20% of the initial build cost for the first 90 days of post-launch work. This isn't contingency for things going wrong - it's the normal, expected cost of responding to real-world feedback and refining the platform. A firm that budgets for this looks prudent. A firm that doesn't looks like it overspent.
Our agency has given us an estimate. We trust them. Why would we budget above that?
Because the estimate is based on what's visible now, and a meaningful portion of the cost is hiding behind discovery work that hasn't happened yet. This isn't about trust - it's about the structural reality of how migrations work. Your agency isn't being dishonest. They're giving you the best estimate they can with the information available. The problem is that the information available at estimate stage is incomplete by definition.
The approach that works: don't present the migration as a single large figure. Present Phase 1 - discovery and architecture - as a standalone investment with a defined deliverable. Typically 8-15% of the total programme cost. The output is a discovery report that produces the accurate programme estimate and a clear go/no-go decision point.
Then present Phase 2 - design, build, and migration - as a budget range with explicit assumptions, contingency identified, and a defined set of decisions that will narrow the range during Phase 1.
This gives your board a small, bounded commitment initially. And a much more informed larger commitment after discovery has removed the biggest sources of uncertainty. It's not a trick - it's honest governance. In my experience, boards are far more comfortable approving a £25,000 discovery phase followed by a well-evidenced £180,000 build than they are approving a £200,000 estimate that they suspect might become £280,000. The numbers are similar. The confidence is completely different.
Beyond the five surprises, there are specific line items I see missing from migration budgets over and over.
URL redirect mapping is the obvious one - every URL that changes needs a redirect, and for a 2,000-page site, that's a significant piece of work that affects SEO, client bookmarks, and any external references to your current site. It's also the thing that gets cut when the budget's tight and then costs three times as much to fix after launch.
Analytics reconfiguration is another. Your analytics setup needs rebuilding on the new platform - tracking codes, event definitions, goal configurations, dashboard structures. Typically two to three weeks for a well-instrumented site. Skip it and you launch blind. I've seen firms spend six months post-launch not knowing whether their new site was actually performing better because nobody rebuilt the measurement layer.
Editorial training is the one that makes me slightly nuts, honestly. The number of firms that invest six figures in a new CMS and then give their content team a one-hour walkthrough is... well, it's most firms. Proper ongoing training resources and documented processes aren't glamorous, but they're the difference between a platform that gets used well and one that quietly reverts to bad habits within six months.
Then there's performance testing - load testing to confirm the platform performs acceptably under realistic traffic conditions - and a defined 90-day post-launch support period. That last one isn't optional. It's the period when production issues and user feedback generate the highest volume of work, and the period that determines whether the migration actually sticks.
Underfunded migrations don't just come in over budget. They produce worse outcomes. Corners get cut on content migration, SEO preservation gets deprioritised, post-launch support gets squeezed, and you end up with a new platform that underperforms from day one.
The firms who spend more upfront - on proper discovery, on realistic content migration timescales, on integration that's been properly scoped - tend to spend less overall. Because they don't have to go back and fix things that should have been done right the first time. I know that sounds like a consultant's self-serving argument. But I've watched it play out enough times that I'm fairly confident it's just true.
If you've read the ranges in this piece and thought "that's more than we expected" - good. That was the point. A budget set against realistic ranges is a budget that's more likely to hold. And a board that approves a realistic budget won't be blindsided at month four when the content turns out to be messier than the audit suggested, the CRM integration needs a custom connector, and the SEO redirect structure requires an additional six weeks.
None of that is failure. It's just what CMS migrations actually look like.
If you want to understand which complexity category your migration falls into - and what a realistic budget and timeline looks like for your specific content estate, integrations, and requirements - book a migration scoping session. It takes 90 minutes and produces a calibrated estimate range. It might also save you from being the next managing partner telling me about a project that cost twice what was approved.