There's a number hiding in your business that nobody has ever calculated. Not because it's hard to find - though it is - but because it's distributed across so many budget lines, departments, and workarounds that it never shows up as a single figure. And because it never shows up as a single figure, nobody ever has the reaction they'd have if it did.
I'm talking about the total annual cost of running your legacy platform. Not the licence fee. Not the hosting bill. The actual, fully loaded cost - including the maintenance hours, the manual processes that exist because the system can't do what you need, the integration failures, the security exposure, and the opportunities you've quietly shelved because the platform couldn't support them.
When someone actually does this calculation properly - all categories, no rounding down the awkward ones - the number is typically three to five times what leadership thought it was. And at that point, the conversation changes. "We can't afford to modernise" becomes "We can't afford not to."
But getting to that number is the hard part. So let's work through how to do it.
First, a bit of empathy for your finance team. They're not missing this number because they're bad at their jobs. They're missing it because of how organisations account for technology costs.
Maintenance contracts sit in IT. The two developers who spend 60% of their time keeping the CMS alive. They're headcount in the technology budget, not a line item called "legacy tax." The marketing coordinator who manually reformats content because the platform can't handle it. That's a marketing cost. The hours your operations team spends re-keying data because two systems don't talk to each other. Operational overhead. The security review that took three months instead of four weeks? Compliance spend.
Each of these costs is real. Each is individually defensible. And each sits in a different budget, owned by a different person, reviewed at a different time. No single view exists. Which means no single person ever sees the total.
McKinsey's research suggests enterprises burn around 40% of their IT budgets just maintaining legacy systems. Forty percent. And that's only the portion explicitly categorised as IT spend - it doesn't capture the workarounds, the lost productivity, or the opportunity cost sitting in other departments' budgets.
I sat with the COO of a 400-person professional services firm last year who was genuinely shocked when we helped them total it up. They'd been approving the individual line items for years - each one looked reasonable in isolation. But when you stack them together? They were spending north of £600k a year propping up a platform they'd convinced themselves was "good enough." I remember the COO going quiet for a moment, then saying something like: "If someone had put this number on my desk three years ago, we'd have moved then."
We asked, gently, why nobody had. Turns out the IT director had flagged it twice - once in a quarterly review, once in an email that got buried. The number had existed. It just hadn't been assembled in a way that made it impossible to ignore.
That's the problem.
If you're going to build a credible total cost picture - one that a CFO will actually engage with rather than dismiss - you need to go beyond the obvious. Not all of these will apply equally to every organisation, but most firms I've worked with find costs in at least five of the six.
Maintenance labour. This is the big one, and it hides most effectively. What proportion of your IT and development team's time goes into keeping the existing platform running - patching, updating, fixing things that break, managing hosting, dealing with compatibility issues - versus building new capability? In most mid-market firms running legacy platforms, that split is somewhere around 60/40 or 70/30 in favour of maintenance. Some are worse. I've seen firms where the ratio was closer to 80/20, and the CTO was still describing the team as "delivering the digital roadmap." They were, technically. Just very, very slowly.
To estimate this: ask your technology lead to have the team track their time honestly for a fortnight. Categorise hours as either "keeping the lights on" or "building something new." Multiply the maintenance proportion by your annual technology team cost - salaries, contractors, the lot. That's your maintenance labour number.
Manual workarounds. These are the processes that only exist because the platform can't do what a modern system would handle automatically. Content published in two places because the CMS doesn't support multi-channel. Data exported to a spreadsheet, manipulated, and re-imported because the reporting won't do what's needed. Someone in your marketing team spending half a day every week reformatting things for the website because the templates are rigid and broken.
These costs are almost never attributed to the platform. They show up as operational headcount. To estimate: map the processes that touch the platform and ask each team how much time they spend on steps that wouldn't exist if the system worked properly. Convert those hours to cost.
Integration maintenance. Every system your platform connects to - CRM, marketing automation, finance system, whatever - represents an integration that needs maintaining. Legacy platforms typically rely on custom-built or heavily customised integrations that break when connected systems update. Each breakage triggers a diagnosis-and-fix cycle. Each fix adds complexity to an already fragile architecture.
Look at your incident logs and support tickets for the last twelve months. How many relate to data not syncing, integrations failing, or information not flowing between systems? Multiply the average resolution time by the cost of the people involved. I worked with a firm recently where integration issues were consuming roughly 15 hours a week of senior developer time. At their day rates, that was close to £60k a year - for a problem nobody had ever formally named.
Security incident exposure. This is the one that makes CFOs uncomfortable, and it should. Platforms that have reached or are approaching end of life don't receive regular security patches. The average cost of a data breach is now $4.45 million globally - and that figure is higher in regulated industries.
You're not going to calculate the exact probability of a breach. But you can build a probability-weighted expected cost. If industry data suggests a 5% annual probability of a significant security incident for organisations running EOL platforms, and the estimated cost of an incident for a firm your size is somewhere between £500k and £2m (regulatory fines, remediation, client notification, reputational damage), then the expected annual cost is £25k to £100k. That's a real number. It belongs in the model. And honestly, 5% might be conservative for some of the platforms I've seen in the wild.
Opportunity cost. This is the hardest to quantify and the most important to include. What initiatives have you deferred, scaled back, or abandoned because the platform couldn't support them? The personalisation project that was too complex to implement on the existing CMS. The client portal that would have reduced churn but couldn't integrate with your systems. The content strategy that died because publishing was too slow and painful.
I know - opportunity cost feels squishy. CFOs are naturally sceptical of it, and rightly so. But excluding it entirely is just as misleading as inflating it. My suggestion: pick two or three specific, concrete initiatives that were shelved or compromised because of platform limitations. Estimate their likely impact conservatively - use the low end of whatever business case existed. Include those figures with clear assumptions and let the CFO interrogate them. A conservative, well-documented opportunity cost is more persuasive than a precise one nobody believes.
Vendor premium. As platforms age, the pool of people who can work on them shrinks. Specialist contractors charge more. Vendor support contracts for legacy versions get more expensive - or disappear entirely, forcing you into expensive third-party arrangements. I've seen firms paying 30-40% more for development time on legacy platforms compared to what the same work would cost on a modern stack, simply because the talent pool has moved on.
To estimate: compare your current contractor day rates and vendor support costs with market rates for equivalent work on modern platforms. The delta is your vendor premium.
Here's where it gets practical. And I want to be honest about something: you don't need precise figures for every category. In fact, if you present a precise total, a good CFO will pick it apart. What you need is defensible estimates with explicit assumptions.
Build the model as a range, not a point estimate. "We believe the total annual cost of maintaining our current platform is between £380k and £520k" is more credible than "The cost is £447,000." The range signals that you've thought about uncertainty. The methodology behind it signals that the thinking is rigorous.
For each category, document three things: how you estimated it, what's included, and what's excluded. A CFO who can see the methodology and test it against their own knowledge of the organisation's cost structure will engage with it. A CFO who receives a number with no workings will bin it.
One more thing. Present the total alongside the current "official" technology budget. The gap between the two is the legacy tax - the amount the organisation is paying that it doesn't realise it's paying. That gap is what changes the conversation.
The six cost categories I've just described don't stay static. They grow. Independently. Every year you defer the decision.
Maintenance costs rise because the system gets harder to support. The people who built it leave. Documentation was never great to begin with. Each patch introduces new fragility. The developers who can work on it charge more, because there are fewer of them.
Workaround costs accumulate as teams build more processes around the platform's limitations. These workarounds become embedded. People stop questioning them. "That's just how we do it" becomes the answer, and nobody remembers that "how we do it" was originally a temporary fix for a platform limitation. I've walked into firms where a workaround introduced in 2019 had since spawned three further workarounds, each one a response to the previous one's limitations. Nobody could tell me why any of them existed. They just did.
Integration costs grow as every connected system evolves. Your CRM vendor ships an update. Your marketing platform changes its API. Your finance system moves to a new version. Each change puts pressure on the custom integrations holding everything together. The architecture gets more fragile, not less.
Security exposure increases with every month of missed patches. Vulnerability databases grow. Attack surfaces expand. The probability-weighted expected cost of an incident creeps upward.
And opportunity cost compounds because your competitors aren't standing still. While you're maintaining, they're building. While you're working around limitations, they're launching the client portal, the personalisation engine, the content strategy that drives inbound enquiries. The gap doesn't just persist - it widens.
A firm that defers the decision for three years doesn't face the same number in year three. It faces a larger number, with fewer options, and probably a more urgent timeline. Emergency migrations - the kind forced by a security incident, a vendor pulling support, or a system failure at the worst possible moment - cost two to three times what a planned migration costs. I've seen it happen. It's not pretty, and it's expensive in ways that go well beyond the invoice.
"We need budget to replace our technology platform" is a losing pitch. I've watched it fail dozens of times. The board hears "technology spend" and immediately thinks about the last technology project that overran, the one before that which was delivered but never adopted, and the $2.3 trillion that's been wasted globally on unsuccessful digital transformation. You're fighting against scar tissue before you've even finished the first slide.
The pitch that works doesn't ask the board to approve a technology spend. It asks the board to choose between two cost trajectories.
Scenario A: Continue with the current platform. Here's what it's costing us today - the total legacy cost number. Here's the projected trajectory over three years, accounting for rising maintenance costs, growing workaround overhead, and increasing security exposure. Here's the probability-weighted cost of a forcing event - a security breach, vendor end-of-life, or system failure that triggers an emergency migration.
Scenario B: Modernise. Here's the investment required. Here's the payback period. Here's the projected annual cost structure post-implementation. Here's the capability it unlocks and the conservative revenue or efficiency impact of that capability.
Framed this way, the question isn't "do we want to spend money on technology?" It's "which of these two cost trajectories do we prefer?" And when the total cost of standing still is honestly calculated - all six categories included - Scenario B almost always wins. Not because modernisation is cheap. It isn't. But because the status quo is more expensive than anyone realised.
I want to be straight about something, though. Modernisation carries real risks. Platform projects overrun. They get more complex than expected. The benefits take longer to materialise than the business case promised. If your board has been burned before - and McKinsey estimates that 70% of large-scale transformations fail, so there's a reasonable chance they have - you need to address this head-on.
Acknowledge the risk. Show how it's being mitigated - phased delivery rather than big-bang, early value realisation in the first phase, clear governance, and an honest assessment of what could go wrong. A CFO who's seen a £500k project turn into a £1.2m project needs to see that you've thought about the downside, not just the upside. The credibility of the entire case rests on this.
If you want to see what a phased approach looks like in practice, we published a guide called The Replatform Reckoning that walks through the financial case and delivery approach in detail. It's free, and honestly, it's the thing I'd hand to a CFO before a board meeting.
The reason most legacy platforms survive as long as they do isn't that anyone has made a conscious decision to keep them. It's that nobody has ever assembled the full cost picture and put it in front of the person who would act on it.
The managing partner who approves the annual IT budget sees a number that looks manageable. The CFO who reviews the P&L sees technology costs broadly in line with last year. The operations director sees workarounds that are annoying but functional. Everyone is looking at their piece of the picture. Nobody is looking at the whole thing.
Once you assemble it, the next step is presenting it in a way that gets board approval - because getting the analysis right is only half the battle. The other half is framing it for a room full of people who've been burned before and need to feel like they can actually say yes.
The firms that make this transition successfully don't pitch it as a technology project. They pitch it as an end to a cost that's been growing unnoticed for years.
Which, if you do the maths properly, is exactly what it is.