Sit with this number for a moment. If your firm is spending 60-80% of its IT budget maintaining existing systems - and McKinsey and Gartner consistently put mid-market firms in that range - then for every £100,000 you allocate to technology, somewhere between £60,000 and £80,000 is going towards keeping the lights on. Not building anything new. Not closing capability gaps. Not preparing for what's coming. Just... maintaining.
And that percentage is almost certainly higher than it was three years ago.
This is the quiet arithmetic of technical debt. It doesn't announce itself. There's no single moment where someone walks into the boardroom and says, "We've got a problem." Instead, it shows up as a gentle, year-on-year squeeze: slightly longer timelines, slightly higher support costs, slightly more change requests that come back with "the platform can't do that" or "we'd need to rebuild the integration layer first." Each one feels manageable on its own. None of them would make it onto a board agenda.
But they compound. And that word - compound - is the one that changes this from a technical grumble into a financial risk.
The reason technical debt doesn't get boardroom attention is partly a language problem. When your IT team says "technical debt," most managing partners and CFOs hear "stuff we'd like to tidy up." It sounds discretionary. The tech equivalent of repainting the office - nice to do, not urgent.
Technical debt actually behaves like financial debt. Not metaphorically. Structurally. It accrues interest. That interest compounds. The longer you carry it, the more of your capacity gets consumed by servicing it rather than investing in growth.
I've written about this dynamic in a companion piece on what your IT team wishes the board understood - worth reading alongside this one. But here I want to go further. I want to give you the financial model that makes this real. Because in my experience, the moment you show a CFO or managing partner the actual cost curves, the conversation shifts from "can we defer this?" to "how quickly can we start?"
I'll be honest: the first time I ran these numbers for a client, even I found the gap surprising. And I'd been saying "technical debt compounds" for years before I actually modelled it properly.
Technical debt doesn't compound through a single mechanism. It compounds through three interlocking ones, and each one accelerates the others.
The most visible is maintenance cost escalation. Each additional year of deferred maintenance adds complexity to the existing system. Integrations that worked cleanly when the platform was current become fragile as the systems around them evolve. Custom code that was fit for purpose three years ago becomes harder to update without breaking dependent components. I was on a call last year with a CTO at a mid-sized consulting firm - he was screen-sharing a Jira board with a backlog that made my eyes water - and he told me his team was spending four days to implement changes that would have taken half a day on a modern platform. Four days. For what was essentially a content update that touched an integration endpoint. That's not inefficiency. That's compound interest.
The second mechanism is less visible but arguably more expensive: capability gap widening. The cost of adding new capabilities to an increasingly complex legacy system grows non-linearly. And I want to stress that word. It's not that things get a bit harder each year. The difficulty curve steepens. An integration that took two weeks when the platform was current might take six weeks by Year 3. By Year 4, it might be technically infeasible without a partial rebuild. I've seen firms quoted £150,000 to build functionality on a legacy platform that would have cost £30,000 on a modern one. The platform didn't just make the work harder. It made it five times more expensive.
The third mechanism - remediation cost growth - is the one that really catches boards off guard. The eventual cost of addressing accumulated technical debt isn't simply the cost of the upgrade that was deferred. It's the upgrade cost plus the cost of untangling the additional complexity added during the deferral period. Every workaround, every patch, every "quick fix" that kept the system running added another layer that has to be understood, unpicked, and migrated. A professional services firm came to us a couple of years back - about 350 people, decent-sized IT team, not a small operation - who'd been deferring a platform migration for four years. The original project had been scoped at around £180,000. By the time they engaged us, the realistic cost was north of £400,000. The destination hadn't changed. The starting point had just got so much more complicated.
These three mechanisms don't operate independently. Maintenance cost escalation forces teams to implement more workarounds, which widens the capability gap, which increases the eventual remediation cost, which makes the business case harder to approve, which leads to further deferral. It's a feedback loop. And like most feedback loops, it's much easier to break early than late.
Let me make this tangible with an illustrative model. These are ranges, not precise estimates - actual figures depend on your specific platform, your integration estate, and how much customisation has been layered on over the years. But the shape of the curve is consistent with what we've seen across dozens of mid-market professional services engagements. McKinsey's analysis suggests maintenance costs can increase by 15-25% annually when platforms go unmaintained; Gartner has reported that remediation costs for deferred platform investment typically grow at 1.5-2x the rate of the original deferral.
So. Imagine a mid-market B2B service firm - a 200-person consultancy, or a law firm with 150 fee earners. They're running a CMS and integration stack implemented five or six years ago. It works. It's not broken. But it's starting to creak.
Year 1 (the baseline). Annual maintenance and support costs: roughly £80,000-£120,000. This covers hosting, patching, vendor support, and the internal developer time needed to keep things running and make routine changes. A structured platform upgrade at this point would cost somewhere in the range of £150,000-£250,000, depending on scope. Act now, and you're looking at £230,000-£370,000 in Year 1, then significantly reduced ongoing costs.
Year 3 (the squeeze). Annual maintenance has crept up to £120,000-£180,000. The increases aren't dramatic year-on-year - maybe 15-20% each time - but they've compounded. More importantly, the team is spending an increasing proportion of their time on workarounds rather than productive work. You've probably had two or three capability requests declined or delayed because the platform can't support them without significant rework. The upgrade cost has also grown: you're now looking at £250,000-£400,000, because there's more complexity to untangle. Cumulative maintenance plus the upgrade: roughly £610,000-£920,000. Compare that to acting in Year 1.
Year 5 (the reckoning). Annual maintenance: £180,000-£280,000. The platform is now consuming a disproportionate share of IT budget and team capacity. Several integrations are running on deprecated APIs or unsupported libraries. The security posture is deteriorating - not catastrophically, but enough that your compliance team is starting to flag it. The upgrade is now effectively a full remediation project: £400,000-£650,000, because the accumulated workarounds, custom code, and integration complexity all have to be addressed before you can move forward. Total cumulative cost: north of £1m. Possibly well north of it.
And here's the number that matters most. If you'd acted in Year 1, your total five-year cost - the upgrade plus reduced ongoing maintenance on a modern platform - would have been somewhere in the range of £450,000-£650,000. By deferring to Year 5, you've spent more on maintenance alone than the entire upgrade would have cost, and you still have to pay for the upgrade. The deferral didn't save money. It roughly doubled the total expenditure.
Every platform has a point at which the annual cost of maintaining it exceeds the amortised cost of replacing it. Think of it like an old car. There's a year where the MOT repairs, the breakdown cover, the unreliability, and the fuel inefficiency add up to more than the monthly payment on something newer. You know the moment. You've probably lived it.
For most mid-market professional services platforms, this tipping point occurs somewhere between Year 3 and Year 6 of sustained deferral. Where exactly depends on the complexity of your customisation and integration estate. A relatively vanilla CMS with light integration might not hit the tipping point until Year 5 or 6. A heavily customised platform with deep CRM integration, portal functionality, and multiple third-party connections might cross it by Year 3.
The problem - and this is really the crux of it - is that the tipping point is almost never visible in real time. It's distributed across maintenance contracts, developer time, opportunity costs from declined change requests, and the slow erosion of team productivity. You've crossed it before anyone realises you've crossed it.
I had this exact conversation with a managing partner at a law firm. We were in a meeting room in their offices - proper old-school boardroom, the kind with a mahogany table and a projector that takes three minutes to warm up - and I was walking her through a forward cost projection we'd put together after their IT team had given us access to the last four years of maintenance invoices. When I got to the slide showing the cumulative maintenance spend versus the upgrade cost, she went quiet for a moment. Then she said, "So you're telling me we've been paying more to keep the old thing running than it would cost to replace it, and nobody told me?"
Nobody told her because nobody had done the maths. The IT team knew the platform was painful. They'd been saying so for years. But they were expressing it as a technical complaint, not a financial one. And technical complaints don't make it onto the board agenda.
We can't afford the upgrade this year. We'll budget for it next year.
I hear this constantly. And look, I get it - genuinely. Budget cycles are real. Cash flow constraints are real. There are years when there simply isn't £200,000 available for a platform investment, no matter how compelling the case. I'm not going to pretend that's not a legitimate constraint.
But here's what I'd push back on: the assumption that deferring is cost-neutral. Every year of deferral has a price. That price isn't always visible in this year's P&L, but it's accumulating in your cost base, in your team's productivity, in the capability gaps you're working around, and in the eventual remediation bill. "We'll budget for it next year" is a perfectly reasonable thing to say - as long as you're also saying, "and we understand that next year's version of this project will cost 15-25% more than this year's." If the board is making that trade-off consciously, fine. Most aren't. They're making it by default, because nobody's presented the comparison.
There's a companion piece on what legacy platforms hide from your P&L that goes deeper on this - worth reading if you're trying to build the internal case.
You don't need a full technical audit to get a directionally useful estimate of what technical debt is costing your firm. You need honest answers to three questions.
What percentage of your current IT budget is spent maintaining existing systems, rather than building new capability? If you're at 60% or above, technical debt is consuming the majority of your technology investment. If that percentage has increased over the last three years - and for most firms it has - then it's actively compounding. The trend matters more than the absolute number.
How many change requests from the business have been declined or significantly delayed in the last twelve months because the platform can't support them? Each declined request has a cost. Sometimes it's obvious - a feature that would have saved the operations team 20 hours a week doesn't get built. Sometimes it's invisible - a capability that would have differentiated you in a competitive pitch doesn't exist, and you never know you lost the work because of it. If your business teams have stopped asking for changes because they already know the answer, that's an even more expensive signal. You've normalised the constraint.
When was the last time the platform underwent a structured upgrade or refactoring - not a patch, not a hotfix, but a genuine planned upgrade? If the answer is "more than three years ago," and your firm's requirements have evolved in that time - new service lines, new markets, new compliance requirements, a shift in how clients want to engage with you - then the gap between your platform's current state and your current requirements is a rough proxy for accumulated technical debt.
If you want to go a step further, take your current annual maintenance cost and project it forward at 15-20% compound growth for three and five years. Then compare those cumulative figures to the cost of a structured upgrade today. That comparison is usually enough to shift the conversation.
This is the part that actually matters. You can understand the compounding mechanism perfectly and still fail to get the investment approved if you present it wrong. I've seen it happen - technically rigorous, financially sound business cases that die in the boardroom because they were framed as IT projects rather than financial decisions. It's maddening.
The format that works - and I mean consistently works, across CFO and managing partner audiences - has three components.
The three-line cost comparison. Put these numbers side by side, on one slide or one page: your current annual maintenance cost; your projected annual maintenance cost in Year 3 if deferral continues (use the 15-20% compound growth model); and the cost of a structured upgrade now, including the first year of reduced ongoing costs. That's it. Three numbers. No technical jargon. No architecture diagrams. When a CFO sees that the three-year maintenance trajectory exceeds the upgrade cost, you don't need to explain the urgency. The numbers do it.
A single risk statement. Not a list of twelve risks rated red, amber, and green - nobody reads those, and they give the impression that everything is vaguely under control. One statement. The specific security, compliance, or capability risk that the current technical debt creates, expressed in commercial terms. Not "the CMS is running on an unsupported version of .NET" but "our platform is running on software that no longer receives security patches, which means a breach would be uninsurable and our compliance team has flagged it as a material risk." Not "the integration layer is fragile" but "we've had two near-misses this year where client data could have been exposed, and the technical team estimates a 30-40% probability of a significant failure in the next eighteen months." One risk. Stated commercially. That's what creates the urgency the numbers alone might not.
A phased investment proposal. Boards resist large, monolithic investment requests - especially for something they've been deferring, which means they're already predisposed to keep deferring. So don't ask for the full amount. Structure it as Phase 1 (a contained, lower-cost initial engagement - often an assessment or discovery phase, typically £15,000-£40,000) with a defined gate review before Phase 2 (the main investment). This gives the board a smaller initial commitment, a natural decision point, and the confidence that they're not writing a blank cheque. We use this structure constantly at Distinction, and it's the single biggest factor in getting stalled investment decisions unstuck.
The whole thing should fit on two pages. If you need more than two pages to make the case, you're including too much technical detail and not enough financial comparison.
If you want a structured template for estimating your firm's technical debt cost and presenting the upgrade case to the board, [download it here]. It covers the three diagnostic questions, a simple maintenance cost escalation model, a remediation cost estimate format, and the board presentation structure I've just described. It's designed so that a managing partner or CFO can complete it using existing IT budget data without needing a technical background.
Not all technical debt is bad. Some of it is a perfectly rational business decision. When you launch a product quickly and accept some shortcuts to hit a market window, that's deliberate technical debt - and it can be the right call. When you defer a non-critical upgrade because capital is genuinely constrained and you've got a higher-priority investment, that's a conscious trade-off.
The problem isn't technical debt per se. The problem is unmanaged technical debt - debt that's accumulating without anyone measuring it, without anyone modelling its forward cost, and without anyone making a conscious decision about when and how to address it. That's the kind that compounds silently until the remediation bill is two or three times what it would have been if someone had been paying attention.
The diagnostic questions and the board presentation format I've described aren't designed to panic anyone into spending money they don't have. They're designed to make the trade-off visible. So that when the board says "not this year," they're saying it with full knowledge of what that decision costs. And when the board says "yes, let's move," they're doing it with a clear, phased plan rather than a panicked reaction to a crisis.
The firms that manage technical debt well don't spend more on technology overall. They spend less. They just spend it earlier, more deliberately, and on the right things. The ones who defer until crisis hits? They spend the most of all.