80% keep-the-lights-on: reading your IT budget honestly

Read it naively and maintenance is a little over half your IT budget; read it honestly and it sits closer to 80%. Deloitte's tech-finance research puts pure operations at 55% of the technology budget against 19% for innovation, and Gartner's run-grow-transform framework lands "run the business" near two-thirds. The distance between those figures and the honest 80% is the part nobody itemises: integration upkeep, licence maintenance, and interest on old decisions. It compounds, which is the actual problem.

Why is more than half the budget spent before you build anything?

Start with the least controversial number. Deloitte's survey has the average IT department spending 55% on keeping existing operations running and only 19% on new capabilities, with the remaining quarter going to "business capability enhancements" — which is mostly keeping current systems relevant, not building anything you would put in a press release. Gartner's categorisation reaches the same neighbourhood from another direction: under its run-grow-transform model, run-the-business spend for a typical enterprise sits around two-thirds before anyone touches growth or transformation.

So the conservative, defensible read is that two of every three IT dollars are committed to standing still. That is not a scandal on its own; systems that move money and stock have to keep working. The scandal is that most budgets stop reading there, treat the two-thirds as fixed, and negotiate innovation out of the remaining third. The honest reading refuses to stop, because the run-the-business line is not one cost. It is at least four, stacked, and each behaves differently.

What is hiding inside the number?

Decompose "keep the lights on" and the fixed-cost illusion falls apart. Only the first row below is genuinely fixed. The other three grow on their own schedule.

McKinsey's tech-debt research is the sharpest instrument here. Surveyed CIOs estimated tech debt at 20 to 40% of the value of their entire technology estate before depreciation — hundreds of millions of dollars of unpaid principal for a large firm. And the interest is not paid from a maintenance budget; the same research found that 10 to 20% of the budget earmarked for new products is diverted to resolving tech-debt issues. That is how the naive 55% becomes an honest 80%: a fifth of your "innovation" spend was maintenance wearing a project code.

Why does the ratio compound instead of shrink?

Because every component except the first is a function of how many moving parts you own, and that count only goes up. Buy a platform and you have bought its licence maintenance forever, its integration to every system it touches forever, and a seat at every coordination meeting its vendor attends. None of that retires when the novelty does. We have written before about how the meeting to coordinate four vendors can cost more than the feature it coordinates; that meeting is a maintenance cost that never appears on a maintenance line.

Integration is the worst offender because it is quietly quadratic. Each new system does not add one link; it adds links to everything it must talk to, and every one of those links is a thing to monitor, re-test on each upgrade, and repair when a schema drifts. The failure mode is not hypothetical — when an integration is under-built and under-tested, you get the go-live that ends up suing its own integrator. Even absent disaster, the upkeep is permanent. You do not add maintenance load once; you raise the floor under it, and next year's "innovation" is negotiated down from the higher floor.

How much of your "innovation" line is really maintenance?

More than the label admits, and reading honestly means auditing it. Two tells recur. The first is that the flagship "transformation" programmes are mostly migration and integration. A new ERP is not new capability; it is the same capability re-plumbed, which is why the median ERP implementation runs 15.5 months before anyone sees a benefit — that time is spent moving data and rebuilding interfaces, that is, maintenance you capitalised.

The second tell is the shadow estate. When the sanctioned systems cannot do the job, the work migrates to spreadsheets someone maintains by hand at night, and that unbudgeted labour is real maintenance the finance model cannot see. If your operation quietly runs on hand-kept files, you are already paying for maintenance twice: once to the vendor whose platform did not fit, and once to the person keeping the workaround alive. The honest budget counts both.

So what actually moves the ratio?

Only one lever does, and it is unglamorous: reduce the number of moving parts you are obliged to keep alive. You cannot optimise a maintenance ratio while its inputs — vendors, licences, point-to-point integrations — keep multiplying; you can only remove them. In practice that means fewer platforms publishing to one event bus you own and instrument yourself, so integration becomes engineering time you already fund rather than a per-vendor tax that renews forever. That is a direction, not a weekend project, and it is the only one that changes the slope.

The uncomfortable arithmetic is that the ratio drifts the wrong way by default: consumption pricing, vendor sprawl and deferred rework all push run-the-business spend up while budgets stay flat, so the innovation third gets thinner each year without anyone deciding it should. The teams that reverse it over the next few budget cycles will not be the ones who negotiate a better discount on the eighth platform. They will be the ones who read the 80% honestly, name what is hiding inside it, and stop adding to the part that compounds.