Technical debt is the new load-shedding: The innovation tax SA enterprises can’t see

Brett Airey, Managing Director, Splitpoint Solutions.

---

South Africans have become world-class at one particular skill: keeping the lights on. We’ve learned to run businesses around an unreliable grid, with inverters, generators and scheduled outages. We’ve normalised spending enormous amounts of money and energy not on growth, but on simply not going dark.

There’s a quieter version of this running inside almost every enterprise IT environment in the country. We just don’t call it load-shedding. We call it technical debt, and like load-shedding, its real cost isn’t the visible expense. It’s everything you didn’t get to do because you were too busy keeping the old thing running.

Technical debt is the accumulated cost of yesterday’s shortcuts, ageing systems and deferred maintenance: workarounds layered on workarounds that quietly calcify into the thing nobody dares touch. And the numbers attached to it are sobering.

Deloitte’s 2026 Global Technology Leadership Study estimates that technical debt accounts for between 21% and 40% of an organisation’s entire IT spend. In banking, Accenture’s 2026 research puts the figure as high as 70% of the IT budget going to maintaining legacy systems and technical debt. That’s not a rounding error. That’s the majority of the budget spent keeping the lights on, with whatever remains funding the future.

And here’s where it stops being an IT problem and becomes a competitive one. In survey after survey, IT leaders say technical debt is actively limiting their ability to innovate. As the market pivots towards AI, legacy estates are increasingly the thing blocking adoption outright. You cannot bolt modern AI capabilities onto a foundation nobody fully understands. The organisations that will win the next few years aren’t necessarily those with the best AI strategy. They’re the ones whose foundations are clean enough to build on.

So while we’ve been distracted by the literal grid, a second one has been browning out the whole time: the one that powers innovation.

The insidious thing about technical debt is that it’s almost invisible until it’s measured. Legacy systems are quiet. Their licensing costs are predictable. They feel, as one report put it, like part of the furniture. Nobody gets fired for the system that’s been running since 2008.

The cost rarely appears as a line item demanding attention. Instead, it shows up as slowness, fragility and the project that took three times longer than expected because of “dependencies”.

Consider the everyday forms this takes:

• The core system only one or two people still fully understand, and both are nearing retirement.
• Infrastructure that gets more capacity thrown at it to “fix” performance issues when the real cause is a configuration problem nobody has the visibility to diagnose. You buy a bigger pipe instead of finding the blockage.
• The quick fix applied to the quick fix, three layers deep, where changing anything risks breaking something nobody can fully map.
• The platform that quietly slipped out of vendor support and is now a compliance and security exposure waiting for an audit to uncover it.

• Continued reliance on legacy AS/400 systems and COBOL long after the people who built them have gone.
• Organisations upgrading to 10Gig or 40Gig infrastructure to solve performance issues when the real root cause was poor configuration or throughput management: spending capex to mask a visibility problem.

Each one is a small outage of the future. Individually survivable. Collectively, they’re the reason the innovation budget never seems to arrive.

The fix isn’t a rebuild. It’s a map.

Here’s the instinct to resist: when technical debt finally becomes undeniable, the temptation is to call for a grand rebuild, rip everything out and modernise it all. That’s the equivalent of buying a bigger generator without checking which circuits are actually drawing the load. Expensive, disruptive and often aimed at the wrong problem.

The first step in clearing technical debt isn’t a rebuild. It’s visibility.

You have to map the mess before you can prioritise it: see what’s actually running, what depends on what, where the real performance and risk concentrations sit, and which of your “critical” systems are genuinely critical versus merely old. Only then can you make evidence-based decisions about what to modernise first, what to leave alone and what’s quietly costing you the most.

This is the unglamorous truth behind every successful modernisation programme: the organisations that get it right don’t start by building. They start by seeing.

Mapping technical debt turns a vague, paralysing sense that “everything is fragile” into a ranked, fundable and defensible plan. It’s the difference between a panicked rip-and-replace exercise and a surgical one.

Load-shedding taught South African business a hard lesson: you cannot manage what you cannot predict, and you cannot afford to pour your best energy into simply staying on. Technical debt is the same lesson, wearing a server rack instead of a substation.

At Splitpoint, we’d put it bluntly: you can’t fix what you can’t see, and you certainly can’t prioritise it. Before you fund another rebuild or throw more hardware at a problem you haven’t diagnosed, map the mess. Find out what’s actually drawing the load.

The first watt of innovation you get back is the one you stop wasting on keeping the old lights on.

Splitpoint Solutions maps and monitors what’s actually running across your network, infrastructure and application estate, so technical debt becomes something you can see, rank and act on, instead of something you only feel.