The most expensive platform decision I've ever seen wasn't a bad technology choice. It was a perfectly reasonable technology choice made on the wrong number.
A mid-sized consulting firm - around 200 people, complex Salesforce integration, decent content estate - evaluated three CMS platforms. They built a comparison spreadsheet. They compared annual licence costs, got implementation quotes, added a contingency line, and picked the option that came in lowest. Sensible, right? The CFO signed it off in a single meeting.
Eighteen months later, they'd spent more on that "cheapest" platform than either of the other two options would have cost over five years. Custom development to cover gaps they didn't know existed at evaluation. A hosting infrastructure upgrade the vendor hadn't mentioned. An integration rebuild when the CRM team upgraded Salesforce and half the connections broke. And a content migration from hell that nobody had properly scoped.
The Year 1 number was accurate. It just wasn't the right number to make the decision on.
I'll be honest - I've made a version of this mistake myself. Not on the platform selection, but on the migration cost. A project in 2019, a firm not unlike the one above, and a migration line in the budget that I'd estimated based on the content volume without properly accounting for the data model complexity. We got there, but it cost more than it should have, and the client was right to be annoyed. I think about that project every time I review a platform comparison spreadsheet.
Total cost of ownership is one of those phrases that sounds self-explanatory. The total cost. Of owning the thing. Over time. But in practice, most platform evaluations define "total cost" as "the costs we can see from where we're standing right now." Which misses quite a lot.
When I talk about TCO for a digital platform, I mean nine cost categories. Not three. Not five. Nine. And the ones that get missed are the ones that produce the budget surprises in Year 2 and 3.
Those nine categories: licence or subscription fees, implementation and initial configuration, customisation, hosting and infrastructure, maintenance and ongoing development, training, integration development and maintenance, content migration, and - this is the one that gets the most pushback - future migration cost. The eventual cost of moving off the platform you're about to invest in.
I'll come back to that last one.
The licence fee is almost always the number that anchors the conversation. It's the number vendors lead with, the number procurement teams focus on, and the number that appears on the first slide of every platform comparison deck I've ever reviewed. And it's the most misleading single number in the evaluation. Not because it's wrong - it's usually accurate for Year 1. But because it represents somewhere between 15% and 30% of the actual five-year cost, depending on the platform model. Making a decision based on that number is like choosing a house based on the estate agent's fee.
Implementation costs vary enormously - for mid-market platforms in professional services, I've seen the implementation run anywhere from 1x to 5x the annual licence cost. That range alone should tell you something about how much depends on the specifics of your situation. Customisation is worse, because the full extent of what you'll need to customise often doesn't become clear until the platform is actually in use and your team starts bumping into the edges of what it can do out of the box.
And then there's content migration. I've written a companion piece on what a realistic CMS migration actually costs, and the migration line is consistently the most underestimated item in every budget I review. Consistently. It's not even close.
If you're evaluating platforms right now, you're probably looking at some combination of three approaches: a managed SaaS platform, a self-hosted open-source option, or a composable or headless architecture. Each has a fundamentally different cost profile, and the differences don't show up in Year 1.
SaaS managed platforms bundle hosting, infrastructure, and core maintenance into the subscription. The TCO model is more predictable - you can forecast costs with reasonable confidence because the vendor controls most of the variables. But that predictability has a ceiling. Usage-based pricing tiers mean your costs can step up significantly as traffic grows, as you add editors, or as the vendor restructures its feature bundles. And the subscription you sign in Year 1 may not be the subscription you're paying in Year 3. Read the escalation terms. Actually read them. I've seen annual price increases of 15-20% baked into contracts that nobody flagged during evaluation.
Self-hosted open-source looks seductively cheap on paper. The software is free. But hosting, maintenance, security patching, performance monitoring, and customisation are all your responsibility. The licence cost advantage is frequently, I'd say usually, offset by the total infrastructure and internal resource cost. You need people who can manage the platform, and those people cost money whether they appear in the technology budget or the headcount budget. A platform that requires a dedicated developer for routine maintenance has a real ongoing cost that many evaluations conveniently classify as "existing resource" rather than a platform cost. It should be in the comparison.
Composable or headless architectures are the hardest to estimate accurately because the CMS is just one component of a larger stack. The TCO depends on the number and complexity of other components, the integration architecture, and how much orchestration glue you need between them. Typically you're looking at higher implementation and ongoing development cost, often lower hosting cost, and, this is where it gets interesting, better future migration economics. Because the components are decoupled, you can replace any single piece without rebuilding the whole thing. That matters more than most people realise at the evaluation stage.
I've covered how to weigh these trade-offs in more detail in the CMS decision matrix piece - TCO is criterion one in that framework, and the two pieces are designed to work together.
Most platform evaluations compare Year 1 costs. That's understandable - Year 1 is the only year where the numbers feel solid. Years 2 through 5 require assumptions about usage growth, customisation requirements, and integration complexity that are genuinely uncertain. Nobody wants to put uncertain numbers in front of a board.
But ignoring those costs doesn't make them zero. It just means the decision gets made without them. And because different platform models have different cost curves - SaaS costs tend to escalate steadily, self-hosted costs tend to spike around major upgrades, composable costs tend to be higher early and flatten later - the Year 1 ranking and the five-year ranking frequently disagree. Sometimes by a lot.
We've budgeted for the licence, the implementation, and a year of support. That covers the main costs.
I hear this a lot. And I get the logic - you're budgeting for what you can see. But "what you can see" at the evaluation stage is roughly 40-60% of the five-year cost. The rest isn't invisible because it doesn't exist. It's invisible because nobody has an incentive to foreground it. The vendor won't, because it makes their platform look more expensive. The implementation partner might not, because it makes the project look bigger. And your internal team may not, because the costs show up in different budget lines - headcount, infrastructure, support contracts - rather than in the platform line item.
The five-year view should be presented as three scenarios - conservative, central, and optimistic - with the key assumptions stated explicitly. A platform that wins on the central scenario but loses on the conservative one has a risk profile the decision-maker needs to understand. That's not overcomplicating things. That's just being honest about what you're committing to.
I could list twenty things evaluations miss. But five come up so consistently that I'd call them near-certainties rather than risks.
Custom development maintenance is the one that bites hardest. Features built during implementation don't just exist forever for free. As the platform updates - and it will update, especially SaaS platforms - bespoke customisations need testing, patching, and sometimes rebuilding. A customisation that costs £20,000 to build may cost £5,000 to £8,000 per year to maintain. Multiply that across half a dozen custom features and you've got a real annual cost that wasn't in the original business case. Closely related: third-party licence escalation. SaaS pricing structures change. Vendors get acquired, tiers get restructured, features you relied on get moved to premium bundles. One firm I spoke to last year saw their CMS subscription increase by 40% over three years - not because they were using more, but because the vendor consolidated two pricing tiers and they ended up on the higher one. Read the escalation clauses. I know I said that already. I'm saying it again.
Internal resource costs are the ones that disappear most easily into other budgets. The developer who spends two days a month managing the CMS, applying updates, and troubleshooting integration issues. The content editor who loses half a day a week working around platform limitations. These are real costs. They belong in the comparison, even though they don't appear on a vendor invoice.
SEO preservation during migration is the line that gets cut most often when budgets get squeezed. The redirects, canonical tags, and content restructuring required to protect your organic search rankings when you move platforms. If you're getting meaningful traffic from search - and most professional services firms are, even if they don't track it carefully - this is a serious workstream. I've seen firms lose 30-40% of organic traffic after a migration because nobody budgeted for this properly. There's more on this in the piece on what a realistic CMS migration actually costs.
Post-launch optimisation is the last one, and the easiest to dismiss in the planning phase. No platform launches perfectly. The first three to six months after go-live will reveal things that testing didn't catch - user journeys that don't work as expected, content that doesn't render properly on certain devices, integration edge cases that only appear in production. Budget 15-25% of the initial implementation cost for this phase. If you don't need it all, great. But planning for it beats scrambling for emergency budget in month four.
Right, bear with me here - this next bit is going to look like a spreadsheet had a baby with a consultant's deck. It's unavoidably dry. But I've found that no amount of narrative argument lands as well as showing the numbers, so here we are.
The scenario: a mid-market professional services firm. 200 staff, around 10,000 pages of content, two in-house developers, a complex CRM integration with Salesforce, and a need for editorial independence.
SaaS managed platform. Year 1: licence £25,000-£40,000, implementation £60,000-£120,000, content migration £25,000-£40,000, integration build £30,000-£50,000. Years 2-5 annual: licence (with escalation) £30,000-£55,000, maintenance and development £20,000-£35,000, integration maintenance £10,000-£20,000. Estimated five-year total: £310,000-£530,000.
Self-hosted open-source. Year 1: licence £0, implementation £50,000-£100,000, content migration £25,000-£40,000, integration build £35,000-£60,000, hosting setup £8,000-£15,000. Years 2-5 annual: hosting and infrastructure £10,000-£20,000, maintenance and security £25,000-£45,000, integration maintenance £10,000-£20,000, internal resource (partial FTE) £15,000-£25,000. Estimated five-year total: £358,000-£575,000.
Composable headless. Year 1: licence £10,000-£25,000, implementation £80,000-£150,000, content migration £30,000-£50,000, integration build £40,000-£70,000. Years 2-5 annual: licence £10,000-£25,000, maintenance and development £15,000-£30,000, hosting £5,000-£12,000, integration maintenance £10,000-£15,000. Estimated five-year total: £280,000-£480,000.
Now look at the Year 1 numbers in isolation. The self-hosted option looks cheapest. The composable option looks most expensive. That's the ranking most evaluations would produce.
Look at the five-year conservative scenario - the top end of each range. The ranking reverses. Self-hosted is now the most expensive, largely because of the compounding internal resource and maintenance costs. The composable option, despite the higher upfront investment, has the flattest cost curve.
That's the core argument of this entire piece, in one example. The Year 1 comparison and the five-year comparison produce different rankings. And you're making a five-year commitment.
I should say - I've seen cases where the Year 1 winner also wins on five-year TCO. It happens, particularly when a firm has strong internal technical capability and can genuinely absorb the maintenance burden of a self-hosted platform without additional headcount. But you need to test that assumption explicitly rather than hoping it holds.
The raised-eyebrow one. I said earlier that future migration cost belongs in the TCO comparison, and I meant it.
Every platform has a lifespan. CMS platforms get end-of-lifed, vendor strategies shift, and what's modern today will be legacy in seven to ten years. The cost of eventually migrating off your chosen platform is a real, estimable number - and it varies significantly between platform models.
A tightly coupled monolithic CMS where content, presentation, and business logic are intertwined will be expensive to migrate away from. A composable architecture where content is stored in a structured, API-accessible format will be cheaper. That difference should be in the five-year comparison, even if the actual migration falls in Year 7 or 8. Because you're not just choosing a platform for the next five years. You're choosing the migration economics for the platform after that.
I've written about how to assess whether your digital platform is holding back innovation - and the piece on the cost of standing still covers the broader picture of what legacy platforms quietly cost. Both are worth reading alongside this.
Platform investment decisions eventually need to go to a board or a senior leadership team. And the typical board slide - three platforms, annual licence cost, implementation cost, a recommendation - is exactly the kind of misleading simplification this whole piece argues against.
A board-ready TCO comparison should show the five-year total for each option across three scenarios, state the key assumptions behind each scenario, and highlight where the ranking changes between Year 1 and the five-year view. It should include the hidden cost categories that most evaluations omit. And it shouldn't pretend to be precise to the penny - it should be defensible, transparent about its assumptions, and honest about the range of outcomes.
If you want the TCO comparison framework as a pre-built spreadsheet - covering all nine cost categories, a three-scenario model, and a five-year comparison output - download it here. It's designed so a technology leader or CFO can populate it with their own numbers without needing specialist knowledge. Fill it in and you've got most of what you need for the board presentation.
And if you'd prefer a structured TCO assessment for your specific platform options - where we bring the benchmark data and help you populate the model with realistic ranges - book a session. We've done enough of these that the patterns are fairly predictable, even when the specifics aren't.
The five-year number won't be comfortable. It's always bigger than the Year 1 number suggested. But it's the honest number, and honest numbers make better decisions than comfortable ones.