Forty percent of enterprise IT budgets go on maintaining legacy systems. Not improving them, not building new things on top of them - just keeping them running. That's a McKinsey number, and if you're a technology leader or managing partner at a mid-sized B2B service firm, I'd wager your internal figure isn't far off. You just haven't calculated it explicitly.
Nobody decides to spend 40% of their IT budget on standing still. It happens incrementally - a patch here, a workaround there, a vendor change request that costs three times what it should. Each one feels manageable in isolation. But over three or four years, the accumulation creates something I've started calling the platform tax: a hidden drag on every digital initiative you run, every feature you try to ship, every idea that gets quietly shelved because "the platform can't do that easily."
The tricky part? The platform tax doesn't show up as a line item. It shows up as projects that take longer than they should, cost more than they were quoted, and deliver less than was promised. And because those symptoms look like execution problems - resourcing issues, poor scoping, agency underperformance - the platform rarely gets identified as the actual cause.
Our platform is fine. The delays are about resourcing and prioritisation, not the technology.
I hear this a lot. And honestly, sometimes it's true. But here's a useful test: if every digital initiative you've run in the last two years has taken longer or cost more than expected, at some point the common denominator stops being the people and starts being the thing they're all working on top of. That's the diagnostic shift this piece is about.
Before we get into any kind of framework, let me describe a few patterns I see repeatedly across the B2B service firms we work with. These aren't obscure technical indicators - they're things that show up in project retrospectives, board updates, and honest conversations in the pub after work.
Slow release cycles. Content changes or new features that should take days end up taking weeks. Not because anyone's being lazy, but because the platform requires specialist knowledge, lengthy testing cycles, or vendor involvement for changes that ought to be routine.
I sat with a marketing director at a mid-sized consulting firm last year who told me it took eleven working days to update a service page. Eleven days. For a text change and a new image. When I asked why, the answer was a chain of dependencies: the CMS required a developer to modify a template, the developer needed to test in a staging environment that was three versions behind production, and the deployment window was fortnightly. Each link in that chain was individually reasonable. The total was absurd. I left that meeting thinking the platform was the problem. Then I spent another hour with the IT lead and realised the deployment window existed because a previous update had taken the site down for four hours during a client pitch. So there was a reason for it - just not a good enough one to justify the ongoing cost.
Workaround accumulation. This is the one that creeps up on you. Over time, the team builds a collection of manual processes, spreadsheets, custom scripts, and third-party tools that compensate for what the platform can't do natively. I worked with a financial services firm that had seventeen separate workarounds documented in a shared folder called - and I'm not making this up - "The Way We Actually Do Things." Each workaround had its own maintenance cost and failure risk. Two of them were maintained by a single person who, if they left, would take the institutional knowledge with them. That's not a platform. That's a house of cards with a content management system somewhere underneath.
High cost of change. Every new requirement comes back with a quote that feels disproportionate. You ask for a simple CRM integration and get told it's a six-week project. You want to add a new content type and discover it requires changes to three interconnected modules. The reason is almost always the same: the platform was built for a different set of needs, and adapting it to current ones generates new technical debt with every modification. Like renovating a house where every wall turns out to be load-bearing.
Vendor or specialist dependency. Changes can only be made by a specific vendor, a particular agency, or one or two people internally who understand the platform's idiosyncrasies. I've seen firms where the departure of a single senior developer effectively froze their digital roadmap for three months while they found someone who understood the bespoke customisations built over the previous five years. If your ability to execute digitally depends on the availability of a handful of specific individuals, that's a platform problem wearing a people costume.
Do any of these sound familiar? If you're nodding at two or more, it's worth doing a more structured assessment.
When we run platform assessments at Distinction, we look at four dimensions. A proper assessment takes time and input from multiple stakeholders - I'll be honest about that - but these give you a starting point for working out whether your platform is a multiplier or a millstone.
Flexibility. Can the platform accommodate new requirements without significant rework or specialist intervention? A healthy platform lets you add new content types, modify page layouts, create new user journeys, and adjust business logic without rewriting core code or involving the original vendor. A constrained one treats every new requirement as a custom development project.
A useful proxy: ask your team how long it would take to launch a completely new section of the website - a resource hub, say, or a client portal. If the answer involves the words "scoping exercise," "vendor consultation," or "it depends on the release schedule," you're probably in constrained territory.
Integration capability. Can the platform connect to new systems cleanly, or does every integration require custom development? Modern B2B service firms run on interconnected systems - CRM, marketing automation, client portals, billing, knowledge management. A healthy platform has well-documented APIs and can be connected to a new system without destabilising existing ones. A constrained platform treats every integration as a bespoke project, often requiring middleware or custom code that nobody wants to maintain two years later.
This matters more than it used to. If you're exploring AI - and Gartner's 2025 analysis found that 68% of organisations say legacy systems are actively obstructing their AI adoption - integration becomes the critical question. AI systems need clean data flows and flexible APIs. A platform that can't provide those will be a bottleneck on your AI ambitions before you've even started.
Editorial experience. Can your marketing team work productively on the platform without involving developers for routine tasks? This gets overlooked because it sounds like a convenience issue rather than a strategic one. It isn't. If your content team needs to raise a ticket, wait for a developer, and go through a deployment cycle to publish a blog post or update a case study, you've effectively throttled your firm's ability to communicate with the market. Content doesn't get published. Thought leadership goes stale. Campaigns launch late. The marketing team spends its time chasing tickets instead of doing marketing.
Cost of change. Track the last five or six digital initiatives your firm has run. For each one, compare the original estimate to the actual cost and timeline. If the pattern is consistently 1.5x to 2x over estimate, the platform is almost certainly a factor - because it means every project is carrying a hidden surcharge for working around platform limitations. Research suggests developers spend roughly a third of their time dealing with technical debt. That's a third of your development capacity going not on building new things, but on navigating around the consequences of previous decisions.
I want to be direct about something.
A firm whose platform constrains the speed of digital change is a firm that's slower to respond to client expectations, slower to test new ideas, and slower to fix what isn't working. The platform isn't just a technology asset sitting in the background - it's a multiplier on your digital team's capacity to act. When the multiplier is healthy, investment in digital initiatives produces proportionate returns. When it's constrained, you get progressively less from each pound you put in.
This is why 70% of large-scale digital transformations fail, according to McKinsey. Not because the strategy was wrong or the team was incompetent - but because the underlying infrastructure couldn't support the pace and flexibility the transformation required. The strategy assumed a platform that could adapt. The reality was a platform that resisted every change.
I was in a conversation with the COO of a 300-person professional services firm about six months ago. They'd spent roughly £1.2 million on digital initiatives over the previous two years. When we mapped the outcomes against the investment, the return was around 40% of what comparable firms were achieving with similar spend. The difference wasn't strategy, talent, or ambition. The difference was that their platform made everything harder, slower, and more expensive than it needed to be.
For a managing partner, the relevant question isn't "is our technology stack modern?" It's "is our technology stack making our digital investment more productive or less productive than it should be?" If the answer is less, then every initiative you approve - every website improvement, every client portal enhancement, every AI pilot - is delivering below its potential. And that gap between potential and actual return is the platform tax.
That's not a technology conversation. That's a boardroom conversation.
I should talk about technical debt, because it's the mechanism through which platforms go from "a bit frustrating" to "actively holding us back" - and it's a concept that often gets lost in translation between IT and the rest of the business.
Technical debt is the accumulated cost of design decisions that prioritised speed or convenience over soundness. Every shortcut taken, every workaround implemented, every "we'll fix that properly later" that never got fixed - those are all deposits into a technical debt account that charges compound interest.
It doesn't appear on the balance sheet. But it shows up in every subsequent project as additional complexity, higher cost, and longer timelines. Think of it like a house where every previous owner did their own plumbing. Individually, each modification worked. But after four owners and twenty years, the system is so convoluted that even a qualified plumber needs two days just to understand the layout before they can fix a leak. The longer you leave it, the worse it gets.
The firms that manage this well aren't the ones that avoid technical debt entirely - that's practically impossible. They're the ones that account for it, measure it even roughly, and factor it into investment decisions. If your board is approving digital budgets without understanding the technical debt burden those budgets are working against, they're making decisions with incomplete information.
So you've run the diagnostic, recognised some symptoms, and concluded that your platform probably is constraining your digital ambitions. Now what?
I want to push back against the assumption that the answer is always "rip it out and start again." Sometimes it is. But the firms that jump straight to replatforming without understanding their options often end up spending more than necessary or, worse, recreating the same problems on a shinier stack.
Improve. Some platforms can be extended or optimised to address the bottleneck without full replacement. If the core architecture is sound but the implementation has accumulated debt, a focused remediation programme - clearing out workarounds, upgrading integrations, improving the editorial tooling - might be enough. This is typically the fastest and cheapest option, but it only works if the platform's foundations can support the improvement. There's no point repainting the walls if the foundations are cracked.
Integrate. If the platform's core is functional but lacks specific capabilities - say, it can't support the personalisation or AI use cases you need - it may be possible to bolt on additional tools that compensate for the gaps. A headless content layer, an API gateway, or a dedicated integration platform can extend what the existing system can do without replacing it wholesale. This works well when the platform's strengths are genuine but its limitations are specific and well-defined.
Replace. If the platform's architectural foundations are fundamentally misaligned with your current and future needs - if the cost of improvement would approach or exceed the cost of replacement, or if the platform is approaching end of life - then replacement becomes the rational choice. But "replace" doesn't mean "big bang." It means a planned, phased transition to a platform that's built for the kind of change you need to make.
The decision between these three depends on the severity of the constraint, the platform's architectural foundation, and - critically - a realistic cost comparison over a three-to-five-year horizon. A platform that costs £50k a year to maintain but limits your digital effectiveness might actually be more expensive over five years than a £300k replacement that unlocks the returns your initiatives should be generating. That's the cost comparison that often creates the mandate to act. Not "the platform is old," but "the platform is making every digital pound we spend worth sixty pence."
If you've read this far and you're thinking "right, I need to actually look at this properly" - good. A few practical suggestions.
Don't try to do the assessment alone. The technology leader sees the technical constraints. The marketing team sees the editorial limitations. The finance team sees the cost overruns. The managing partner sees the strategic drag. No single perspective captures the full picture, and if you let IT own this assessment entirely, you'll get a technology answer to what is partly a commercial question.
Start with the cost of change dimension. It's the most commercially legible of the four, and it's the one that tends to get the attention of the board. If you can demonstrate that your last five digital initiatives each cost 50% more than estimated, and that the common factor was the platform, you've got something concrete to work with.
And be honest about what you find. I've seen firms go through this exercise and conclude that their platform is fine - that the real problems are resourcing, governance, or strategy. That's a legitimate outcome. The diagnostic is genuinely open to all conclusions, including "the platform isn't the problem." The point is to know, rather than assume.
Look, I know the instinct is to file this under "important but not urgent" and come back to it next quarter. That's human nature. But the platform tax doesn't pause while you think about it. Every digital initiative you run between now and whenever you address the constraint will carry the surcharge.
The diagnostic question isn't "what went wrong with the last project?" It's "what would that project have cost and delivered if the platform had been built for this kind of change?"
If the gap between those two answers is small, your platform is probably fine. If the gap is significant - and in my experience, it usually is once you actually do the maths - then you've found the thing that's been quietly absorbing your digital investment for years.
And that's not an IT problem. That's a strategic one.