Every IBM i organization has one. The application nobody wants to touch, the integration held together by a script someone wrote in 2016, the module that works fine as long as nobody asks it to do anything new. Leadership knows about it. It shows up in planning conversations every year, gets ranked below whatever has a harder deadline, and rolls forward to the next cycle.
That decision usually gets framed as the safe one. Standing still feels like it costs nothing, at least compared to the risk of touching something that currently works.
New research suggests that framing is wrong, and the gap between what standing still feels like and what it actually costs is large enough to change how the conversation should go in your next budget meeting.
The Number Behind "We'll Get to It Next Year"
McKinsey’s research on technical debt puts a figure on what most IT leaders have long suspected but rarely quantified. Across the organizations McKinsey studied, unresolved technical debt has consistently left businesses unable to bring innovations to market at the speed or budget they intended, and the firm’s CIO survey found that debt-related issues consume roughly 40% of IT balance sheets, with surveyed executives estimating tech debt represents 20% to 40% of the value of their entire technology estate before depreciation.
The part that matters most for planning purposes is where that cost hides. Nearly a third of the CIOs McKinsey surveyed reported that more than 20% of the budget they had allocated for new development gets quietly redirected to resolving problems related to existing technical debt. That is not a maintenance line item. It is innovation budget, approved for one purpose, consumed by a different one before the fiscal year is over.
The upside case is just as concrete. Organizations that manage technical debt deliberately, McKinsey found, free their engineers to spend meaningfully more time on work that actually supports business goals, in some documented cases moving from three-quarters of engineering time spent servicing debt down to a quarter. That is not a productivity tweak. It is close to tripling the useful output of the same team, without adding headcount.
Why the Debt Keeps Growing Even When You're Investing
A natural assumption is that new investment offsets old debt. If the organization is spending on AI, on integration, on new capabilities, the legacy burden should be shrinking as a share of the whole.
McKinsey’s most recent research on CIO technology budgets, published in March 2026, complicates that assumption. New application deployments, especially AI initiatives, tend to introduce their own operating burden: models to maintain, platforms to govern, controls to manage, layered on top of the existing legacy footprint rather than replacing any part of it. The technology estate gets more complex, not less, even as spending goes up. Left unaddressed, McKinsey warns, this dynamic flattens the return on technology spend entirely, because any gains from new investment are offset by the rising cost of simply keeping everything running.
The report draws a distinction that is useful for framing an internal business case: “run” spending, the cost of keeping current systems operational, versus “change” spending, the investment that actually improves the platform. Organizations that keep both categories small, treating cost control as the strategy, are the ones most exposed to this trap. Standing still is not neutral. It is a decision to let run spending quietly crowd out change spending, year over year, until there is no budget left for the initiatives leadership actually wants to fund.
The Debt Is Also Changing Shape
There is a second, less obvious problem. Technical debt management research points to a shift in the composition of technical debt toward the architectural layer. As AI-assisted coding accelerates how fast new code gets written across the industry, Gartner projects that architectural technical debt, the kind embedded in how systems are structured rather than in any single line of code, will account for 80% of all technical debt by 2027.
That distinction matters for any organization weighing a surface fix against a structural one. Architectural debt does not respond to the interventions that feel easiest to approve. A cleaner screen or an updated interface does not touch the way programs, data, and integrations are actually organized underneath. As the industry’s debt shifts further into that architectural layer, the fixes that stop at the surface address a shrinking share of the real problem, and the gap between what gets patched and what is actually costing the organization money keeps widening.
What This Looks Like Inside an IBM i Organization
None of this research was written about IBM i specifically, which is part of what makes it useful. It describes a pattern that shows up everywhere legacy investment has compounded over decades, and IBM i environments are a clear example of the pattern at its most mature. Deep, validated business logic. Integrations that have accumulated for years. A small team that understands why things are built the way they are, and an even smaller amount of that reasoning written down anywhere.
For a CTO or IT director, the McKinsey numbers translate into a specific planning question: what percentage of this year’s development budget, approved for new capability, will actually get absorbed servicing existing problems before the year is out. For the developers doing the work, it shows up as a felt experience the research backs up with data. Hours that were supposed to go toward building something new instead go toward routing around what already exists.
Restructuring the architecture, not just refreshing what sits on top of it, is the only intervention that addresses debt at the layer where Gartner says it is actually accumulating.
That is the distinction between a surface fix and Futurization, our unique approach to evolving IBM i applications by preserving the business logic that runs the company while restructuring the architecture around it, so the platform stops accumulating debt at the rate this research describes.
The Question Worth Bringing to the Next Planning Cycle
Standing still has never been free. It has simply been unmeasured, which made it easy to rank below whatever had a harder deadline that quarter.
The organizations that get ahead of this are not the ones with the biggest transformation budget. They are the ones that start treating technical debt as a line item with a real number attached, rather than a background risk that gets acknowledged and deferred. Once it has a number, it competes for budget attention the way every other line item does, and it tends to win that competition more often than leadership expects.
If your organization has not put a number on what standing still is costing this year, that is the conversation worth having before the next budget cycle locks in.
Reach out to our team at Futurization@ProfoundLogic.com to talk through what that number looks like for your environment.