A managing partner rang me, furious about an £80k overrun. The culprit was a CMS choice made three years earlier. Here's why it's strategic.
Let me tell you about a conversation that probably sounds familiar.
A managing partner at a 200-person consulting firm rang me a few months back. They'd just been told their website rebuild was going to take twice as long as expected and cost an additional £80k. He was frustrated - understandably - and wanted to know who'd messed up. The project manager? The developers? The agency?
None of them, as it turned out. The problem was a CMS decision made three years earlier by someone who'd since left the business. That person had chosen a platform based on a slick demo and a competitive first-year licence fee. Nobody senior had been in the room. Nobody had asked what the firm might need in 2025. And now every new feature, every integration, every attempt to do something even slightly ambitious was hitting the same wall: the platform couldn't do it without expensive custom development.
Three years of compounding constraints, and the bill had finally landed.
I've seen this pattern enough times that I should probably have a slide for it. And I'm writing this not for the person who'll configure the CMS or manage the migration, but for the managing partner, the marketing director, or the COO who assumes this is a technology decision they don't need to be involved in.
It's just a website platform. Marketing choose it, IT implement it, we go live. I don't need to be involved in that decision.
I get it. You've got a hundred things competing for your attention, and "content management system selection" doesn't exactly set the pulse racing. But this decision will quietly shape your firm's digital capability, its flexibility, and its total technology cost for the next five to ten years. And by the time the consequences become visible, the cost of fixing them will be significantly higher than getting it right in the first place.
Most people think of a CMS - a content management system - as the tool that lets the marketing team update the website. That's true, as far as it goes. But it's a bit like describing your office building as "the place where we keep the desks."
A modern CMS - or its more capable cousin, the Digital Experience Platform (DXP) - is the foundation on which your entire digital client experience sits. It determines what personalisation is possible. It governs which integrations with your CRM, marketing automation, analytics, and other systems can actually be built. It dictates how quickly your digital team can respond to new requirements. And it sets the migration cost when - not if - the platform eventually needs to change.
If you've read my piece on why most B2B service websites still fail their users, you'll already recognise the symptoms of a digital experience that's fallen behind. What you might not have connected is that the platform underneath is often what's preventing you from fixing it. Your team might have brilliant ideas for improving the client journey, but if the CMS can't support them without six weeks of custom development and a £30k change request, those ideas die in a backlog.
Every digital capability decision your firm makes for the next several years will be shaped - or constrained - by this choice. That's not hyperbole. It's just how these platforms work.
Nobody sets out to choose the wrong CMS. It happens through a series of perfectly reasonable decisions that look fine individually but compound into something problematic.
The most common one: choosing for today, not for three years from now. The firm evaluates platforms against its current requirements - the ones it can articulate right now - and picks the one that fits best. Makes sense, right? Except that your requirements in three years will look nothing like your requirements today. You'll want to integrate with a system you haven't bought yet. You'll need personalisation you haven't imagined yet. You might be exploring AI capabilities that didn't exist when you signed the contract. The platform that fits your current needs like a glove often becomes the platform you've outgrown within eighteen months.
I was in a boardroom last year where the CTO admitted - somewhat sheepishly - that they'd chosen their CMS specifically because it handled their existing content types well. What they hadn't anticipated was that the firm would acquire two smaller practices within two years, each with their own content, their own branding requirements, and their own integration needs. The platform couldn't accommodate any of it without significant rework. I didn't say "I told you so." But I thought it quite loudly.
Then there's over-customising to fit existing processes. This one's driven by good intentions. The implementation team encounters a gap between what the platform does out of the box and how the firm currently works. Rather than adapting the process to the platform's strengths, they build custom functionality to replicate the existing way of doing things. Six months later, you've got a heavily customised platform that does exactly what you used to do - but now you're locked in. Every upgrade becomes a risk. Every new feature from the vendor might break your customisations. And when you eventually need to move, the migration cost has ballooned because you're not just moving standard content - you're unpicking years of bespoke development. I've seen firms spend more on maintaining their customisations over five years than they spent on the original platform. It's genuinely bonkers.
A third pattern: ignoring integration requirements until it's too late. Your CMS doesn't exist in isolation. It needs to talk to your CRM, your marketing automation platform, your analytics tools, your event management system, maybe your document management system. These integrations are where most of the real value lives - and they're routinely treated as an afterthought. The firm selects a CMS, signs the contract, starts implementation, and then someone asks, "Right, how do we connect this to Salesforce?" And the answer is either "with difficulty," "with an expensive middleware layer," or "you can't." By that point, you're committed. You either accept the capability gap or you fund costly workarounds that nobody budgeted for.
And then there's the one that probably costs firms the most money in aggregate: underestimating total cost of ownership. The licence fee is the number everyone fixates on. It's clean, it's comparable, and it fits in a spreadsheet. But it's typically 20-30% of the real cost. Implementation, hosting, ongoing maintenance, developer support, upgrades, and eventual migration - that's where the money actually goes. A platform with a £15k annual licence that requires £60k a year in developer support is more expensive than a platform with a £30k licence that the marketing team can manage independently. You'd never know that from the procurement spreadsheet, though.
I'll be honest - we got this wrong ourselves once. Early in a project for a financial services client, we recommended a platform partly because we knew it well and could move quickly. We underestimated how much their compliance requirements would drive customisation over time. Two years later, they were spending more on maintenance than on new development. We've since built total cost modelling into every platform recommendation we make. Expensive lesson, but a useful one.
So if feature lists and demo scores aren't the answer, what should you actually be evaluating?
Usability for the people who'll use it every day - and I mean the marketing coordinator who needs to publish a blog post on Tuesday morning, not the developers. If your content team can't use the platform confidently and independently within a few weeks of launch, something's gone wrong. I've seen platforms that were technically impressive but practically unusable - the kind where updating a phone number requires a developer. That's not a CMS; that's a bottleneck with a login screen.
Flexibility to support growth and change matters enormously, and this is where architectural decisions come in. For most mid-market B2B service firms, I'd push toward headless or composable architecture over a traditional monolithic CMS - not because it's fashionable, but because it gives you the ability to swap out components as your needs change without rebuilding from scratch. The question worth asking in any vendor demo is: "What happens when we need to do something we haven't thought of yet?" If the answer involves a six-figure change request, keep looking.
Integration capability is the one that bites people hardest. Can the platform connect to the systems you already run? Can it connect to the ones you'll probably buy in the next three years? Modern platforms with strong API layers make this relatively straightforward. Older or more closed platforms make it painful and expensive. This isn't a nice-to-have.
And then there's migration ease - the question nobody asks during procurement and everyone wishes they'd asked during replatforming. How easy is it to get your content and data out of this platform when the time comes? Platforms that store content in open, structured formats are dramatically easier to migrate from than those that lock content into proprietary structures. The average migration costs $1.75 million and runs 18% over budget. The firms that plan for this from day one tend to make very different platform choices than the ones that don't.
If you're reading this because you're already facing a CMS replacement - maybe your current platform is end-of-life, maybe the costs have become untenable, maybe you've just had enough of the workarounds - the temptation is to frame the whole exercise as damage control. How do we replicate what we had on a newer platform?
Wrong question. Genuinely wasted opportunity.
A replatforming moment is the best chance your firm gets to rethink your digital architecture, your content strategy, and the way your digital team actually works - all at once. You've got a clear mandate to change things. You've got budget allocated. You've got attention from leadership. Using that moment to rebuild what you already had is like renovating your kitchen and putting everything back in exactly the same place.
The firms that get the most value from replatforming start by asking: "Knowing what we know now, what would we build if we were starting from scratch?" Not because you'll literally start from scratch - you won't - but because the question forces you to challenge assumptions that have been baked into your digital setup for years.
We worked with a professional services firm that had been running a heavily customised WordPress installation for six years. When they finally committed to replatforming, they initially briefed it as a like-for-like migration. We pushed them to step back. Turned out that half their content was redundant, their site architecture reflected an organisational structure that hadn't existed for three years, and their enquiry paths were so convoluted that potential clients were giving up before making contact. The replatform became a complete rethink. Sixty-seven percent increase in qualified enquiries within six months. That wouldn't have happened if they'd just moved the furniture to a new house.
If this is resonating, our guide The Replatform Reckoning goes much deeper on the financial case and the practical roadmap. It's specifically written for the CFO or senior leader who needs to build the business case internally.
This all sounds reasonable, but surely this is what I pay my technology team and my agency to handle?
Partly, yes. But technology teams optimise for technical elegance. Agencies optimise for platforms they know well - and, let's be honest, platforms they have commercial relationships with. Marketing teams optimise for ease of use. None of them, on their own, will optimise for your firm's commercial priorities over the next five years. That's your job.
The managing partner or marketing director who is absent from the CMS selection process typically becomes very present when the consequences emerge. I've watched it happen - the senior leader who waves away the platform evaluation, then six months later is in a meeting demanding to know why the website can't do something that was ruled out by a technical decision they weren't part of.
You don't need to understand the technical architecture. You don't need to sit through every vendor demo (though sitting through one or two is quite revealing - you learn a lot about a vendor from how they handle questions they weren't expecting). What you need to do is ensure the selection criteria reflect your commercial priorities, not just technical requirements. Ask the questions that make the room go quiet: What does this cost us over five years, not just year one? What happens when we outgrow this? How hard is it to leave?
That's half a day of your time at the requirements stage. Compare that to the weeks you'll spend managing the fallout of a decision that went wrong.
Your CMS shapes your client experience. Not in an abstract way - in a very practical, daily way. It determines whether your website loads fast enough to keep a prospect engaged. It controls whether your content team can publish timely thought leadership or whether every article sits in a two-week queue because the platform is too difficult to use. It decides whether a potential client can find what they need in three clicks or gets lost in a navigation structure that made sense to an information architect five years ago but makes no sense to anyone actually trying to hire your firm.
The firms that treat CMS selection as a strategic decision - one that connects platform capability to client experience to commercial outcomes - make better choices. The ones that treat it as procurement make choices they live to regret.
I've written separately about what to look for when evaluating specific platforms, and if you're at the point where you're ready to compare options, that's probably your next step. There's also a detailed piece on why Xperience by Kentico works well for mid-market firms if you want to go straight to a specific platform evaluation.
Your CMS decision isn't a technology decision. It's a business decision that happens to involve technology. And it deserves your attention before it demands your budget.