Resources · Market data
In short
Across surveys and audited budgets, more than half of technology spend goes to running what already exists, a third to a half of engineering hours go to upkeep, and decade-old runtimes still hold a quarter of production. These figures tell you your situation is normal. They don't tell you what your system costs you, so use them to set a baseline and then measure your own.
If you've sat through a modernization pitch recently, you've seen the slide. "Seventy to eighty percent of IT budgets go to keeping the lights on." Sometimes it's attributed to Gartner, sometimes to nobody. You nod, because it feels about right, and then wonder whether anyone has checked.
I went looking for the figures behind the slide: how much technology spend goes to running what exists, how long old versions stay in production, and how thin the skills around them are getting. The data is patchier than the slides suggest, but where it exists it points the same way.
The takeaway is simple. The global data tells you that your situation is normal. It can't tell you what your system costs you or what to do about it. For that you need your own baseline, and the second half of this piece is about building one.
Nobody publishes a clean global split between running existing systems and building new capability, so you work from surveys and from bodies obliged to report. In Deloitte's global CIO research, respondents on average put 55% of the technology budget into existing business operations, 26% into incremental change and 19% into new capability. Across industries the operations share runs from 48% to 67%. That survey is from 2018, so treat it as a benchmark, not a current reading.
Governments give you audited figures. For fiscal year 2024, 26 US federal agencies planned to spend about $95 billion on IT, of which $74 billion went to operations and maintenance and $21 billion to development, modernization and enhancement: 78% on running what exists, in line with the roughly 80% agencies have reported for years. The UK's January 2025 State of digital government review found around 28% of central government technology estates classified as legacy, up from 26% a year earlier, and that maintaining legacy systems often costs three to four times as much as modern alternatives.
So the slide isn't wrong, exactly. Public bodies sit near 80%. Most private companies sit nearer 55% to 65%, still more than half of every technology dollar.
Budget shares hide a second number: how much of your engineers' time goes to upkeep. Stripe's Developer Coefficient study surveyed more than 1,000 developers and 1,000 executives in five countries. The average developer reported 17.3 hours of a 41.1-hour week on maintenance work such as debugging and refactoring, about 42%, with 3.8 of those hours on "bad code", which Stripe priced at roughly $85 billion a year worldwide. Nearly two-thirds of developers called it excessive.
McKinsey asked from the CIO's chair. In a 2020 survey of 50 CIOs at companies above $1 billion in revenue, respondents said 10% to 20% of the budget meant for new products is diverted to resolving tech debt, and put the debt itself at 20% to 40% of the value of their technology estate.
These are self-reported figures, but consistent ones: between a third and a half of engineering effort in an established company goes to keeping the current system working.
The third set of numbers is how long technology stays in production after the industry has moved on. Some of this evidence is telemetry rather than opinion.
A decade-old runtime holding a quarter to a third of production is the norm. And everywhere the preference is to modernize rather than replace, which tells you how many rewrites have already gone badly.
The GAO is blunt about skills. The ten most critical US federal legacy systems it reviewed were between 8 and 51 years old and cost about $337 million a year to run; several used COBOL, and GAO notes that reliance on older languages brings "a decrease in the availability of individuals with the proper skill sets". In banking, a June 2026 study by Hanover Research for Rocket Software found 81% of 250 IT leaders in five countries described their mainframe skills gap as very or extremely significant. It's vendor-commissioned, so read it as direction, not precision.
The squeeze isn't only a mainframe story. In Stripe's study, executives ranked access to developer talent (61%) as a bigger threat than access to capital (56%). In our own work with Rails, Java and .NET estates the pattern repeats at smaller scale: a fifteen-year-old system, two or three people who know why the invoicing job runs in that order, and candidates who don't want to maintain a version they'd rather not list on their CV.
Before any of these numbers go in a board paper, four cautions.
Take the categories the global studies use and apply them to one system, not your whole technology function. Five steps a finance partner and an engineering lead can do in a couple of weeks.
A publisher's subscription platform we worked with went through this exercise. Its budget share sat near the Deloitte average, but when the team tagged a month of time, upkeep on the Rails application came out well above half, two engineers held almost all the knowledge of the renewal logic, and a pricing change had slipped two quarters. The cost of delay on that one change exceeded a year of the system's running cost. The decision made itself once the numbers were theirs.
Fabrica's CLEAR method starts from the same premise: the running system is the evidence. Capture records what the current system does and how often, which gives you the workflow map and knowledge concentration from the steps above, measured rather than estimated. The assessment is scoped to one workflow and ends with a recommendation that may be not to rebuild, and a pilot is measured against a baseline you agree. The finance page lists the questions any modernization proposal should answer with your figures.
The global numbers earn one slide: the one that says this is a common condition, not a failure of your team. More than half of technology spend on standing still, a third to a half of engineering hours on upkeep, decade-old runtimes in a quarter of production, skills in fewer hands.
After that slide, stop quoting other people's figures. Spend two weeks producing your own split, hours, version list and cost of delay for one initiative. Then the conversation moves from "is this a problem?" to "which workflow first, and what will it cost to wait?"
Tell us about it on a 30-minute call. We'll suggest a first scope and what a technical review would need to confirm.