“If it ain’t broke, don’t fix it.” Great advice, just not all the time, and definitely not when it comes to legacy code or infrastructure that still “somehow works”.
Every CIO wants to modernize, rationalize, and simplify their IT systems, hardware and software included. But it is invariably deprioritized, deferred to the next quarter or next year, which never comes. Sounds familiar? Because it is.
Every piece of code written and deployed was meant to solve a real business problem, at a specific moment in time, in a certain business and operational context. Like any other system, IT solutions can outlast the problem, or at least the context in which they were built.
Legacy burden accumulates in IT more subtly than in other areas. On a factory floor, the difference between old and new machinery, with respect to floor area, power utilization, and output, is easily visible and tangible. It is not the same with software. Code built for a simple purpose gets an addition here, an addition there and dozens of security patches over the years. Middleware layers grow as newer systems need to connect. Over time, the overhead becomes larger than the functionality itself. And it is still called legacy.
The becomes a burden when the cost of maintaining and working around it exceeds the value it delivers. Even then, for a variety of reasons, it does not get replaced.
That tipping point is not theoretical. McKinsey notes that “CIOs estimate that tech debt amounts to 20 to 40 percent of the value of their entire technology estate.”
But why?
There are several answers, but no single answer. In many cases, it is not because someone kicked the can down the road.
One major driver sites outside IT. Business owners are often very possessive of their applications. Systems they funded years ago continue to be seen as assets, even when their relevance has faded. The perception of more applications equals more critical and productive the users are, hangs thick. Decommissioning is perceived as loss, not optimization. No one wants to be seen as not needing a software anymore, so no one agrees to decommission As long as something still works, or appears to, it is difficult to justify replacing it or reallocating budget toward a modern alternative.
On the technical side, the causes are more familiar. Systems are often designed under time, budget, and skill constraints. It is understandable that the design would have been for immediate needs, not long-term adaptability. That is just the nature of the beast.
Documentation is often limited, making it challenging and risky for anyone attempting cleanup or modernization. Sometimes, ironically, modernization efforts layer new systems on top of old ones, leading to parallel architectures that increase complexity. A legacy issue is solved, but two new ones are introduced to be tackled in the future.
The deeper cause of technical debt accumulation lies in where incentives sit for developers. Whether outsourced or developed in-house, teams are rewarded for shipping features, not for reducing complexity. The teams or individuals best equipped to alleviate technical debt, or at least reduce the burden for tomorrow, have no incentive to do so. If anything, the incentive lies in quick fixes.
The cost
In the McKinsey report cited earlier, the firm estimates that 10–20% of budgets intended for new products are diverted to managing technical debt, while companies pay an additional 10–20% on top of project costs due to existing complexity.
As AI use cases are explored, organizations with large technical debt potentially face a double constraint. The sheer cost of maintaining legacy applications eats into the investment that could go into AI, while the complexity and incompatibility of those very applications limit how far AI can go. For CIOs looking for a clear trigger to act, this is it. Technical debt is no longer just an efficiency problem, it is a constraint on future capability.
Resolving technical debt
A large portion of the solution is non-technical, the term technical debt’ notwithstanding. A good starting point is to reframe technical debt as a business risk and an opportunity cost, rather than that of an IT operations’ problem of “keeping the lights on”. Elevating the issue from an operational concern to a strategic one opens up a couple of paths. For one, CIOs can set aside budgets specifically for proactively modernizing legacy systems. Where business teams own the budget, they can be guided to choose between modernizing or decommissioning, especially in the case of redundant applications or diluted use cases. When it becomes a boardroom priority, it becomes everyone’s priority.
Treating the issue strategically allows CIOs to bucket modernization into ongoing priorities instead of a one-time project. For example, a scoring mechanism, devised according to their environment and business priorities, can help take a staggered and structured approach to modernization, instead of large one-time transformation projects.
