Calling aging systems tech debt can undermine modernization funding

Calling aging systems “tech debt” can produce the wrong funding plan

A chief financial officer, or CFO, can fund a program to replace central business systems yet leave it unable to finish. This happens when several dependent systems must change together, but each budget request is treated as a separately adjustable payment against “technical debt.” Each reduction can look prudent on its own. Together, the reductions can keep replacement work running while preventing the old platform from being retired.

The problem starts when a single label gives different kinds of work the same financial treatment. Those activities include replacing aging systems, moving workloads to the cloud, building mobile applications, and using virtualization to run multiple software-defined computers on shared hardware. They also include adopting software as a service, applications operated online by a provider, integrating AI agents that perform tasks through software tools, and moving systems back to on-premises infrastructure controlled by the organization. These changes address different needs, but confusion about them gives vendors room to sell through fear, uncertainty and doubt, or FUD, a practice that extends beyond IBM.

To distinguish those needs, Justin Greis, chief executive officer of consulting firm Acceligence, separates deliberate shortcuts from unauthorized obligations and ordinary technological aging. His firm has a commercial interest in how enterprises define modernization problems and seek consulting help. With that interest in mind, leaders can use his illustrations to ask two questions: can the approved funding support a completed transition, and does reported progress reflect a change in the systems that constrain the business?

Distinguish approved shortcuts, unauthorized obligations and aging

The funding question starts with a clear account of why the work is necessary. Acceligence’s classification asks whether someone took a shortcut and, if so, whether management knowingly authorized it. These questions separate an accepted business compromise from an obligation created without approval. They also leave room for a system that was appropriate when purchased but has since aged.

Under this classification, technical debt begins with a deliberate choice to defer part of an implementation for a business reason. Developers or staff in a security operations center, which monitors and responds to security threats, may recognize that the full implementation exceeds the available time or money. Management accepts the compromise so delivery can proceed, knowing that completing the deferred work later will probably increase the total cost. The organization has accepted both the immediate benefit and the future obligation.

Greis illustrates that choice with a budget of “$X” or a deadline of “two weeks.” These hypothetical constraints explain why a shortcut can be reasonable; they describe neither an actual expenditure nor a delivery promise. The key condition is informed approval. As Greis puts it, “Tech debt, as originally intended, describes a knowing trade. The term is useful precisely because it is so specific.”

Without informed approval, Acceligence calls the obligation “shadow tech debt.” In its example, an individual cuts a corner and leaves the enterprise facing a payment in a year, even though management never accepted that trade-off. The missing authorization creates a governance problem: someone has committed the organization to future expense without giving it the opportunity to decide. Leaders must therefore establish who had authority to accept the obligation and how it became visible.

The size and persistence of that obligation also distinguish it from the smaller workarounds often called shadow IT: technology acquired or used outside approved processes. In Acceligence’s examples, someone might obtain a cloud instance, a rented computing environment, with a credit card, or install a consumer-grade router while waiting a month for an approved enterprise device. Acceligence considers these workarounds generally less likely to create a substantial future enterprise expense. Their consequences still require judgment because unauthorized choices can create different levels of liability.

Aging presents a different reason to invest. A mainframe or an early cloud deployment may have been a suitable, costly purchase at the time, yet need replacement as business requirements and technology change. In Acceligence’s illustration, an investment made in 2000 and reconsidered in 2026 shows that passage of time. Its need for modernization reflects present requirements; it establishes nothing about whether the original implementation involved a shortcut.

For this aging category, Greis coined “tech gravity,” a term Acceligence uses for investments that were appropriate when made but later need renewal. The useful distinction is what caused the work: an approved shortcut calls for an account of the accepted compromise, an unauthorized obligation calls for governance action, and an aging system calls for a modernization decision. Leaders can use these distinctions in a funding discussion without adopting the new terminology. Each category gives management a different decision to make.

Fund the dependencies required for retirement

The distinction affects funding when retiring a platform requires several systems to change together. In Greis’s first illustration, a chief information officer, or CIO, brings a multi-year retirement proposal to the board and describes the platform as a liability that can be reduced over time. The board endorses the proposal, after which the CFO approves a cautious first-year allocation. Work can begin, but the allocation leaves the full commitment open for later decisions.

Permission to begin can conceal disagreement about what finishing requires. The CIO has an approved objective, while the CFO has authorized an initial amount of spending. Those decisions let the team proceed, but leave unresolved whether the dependent systems can make the coordinated transition needed to retire the platform. The proposal therefore needs to connect the spending stages to the conditions for shutting the old system down.

The gap becomes visible two years into Greis’s illustration, when the program is behind schedule. The systems turn out to be more interconnected than the original inventory indicated, and the allocation cannot support moving all the dependent systems together. The discovery increases the need for coordination just as the funding arrangement restricts it. So progress on individual components leaves the old platform necessary.

An inventory helps identify those components, but retirement also requires an explanation of how their dependencies will be removed. Some work may be complete while an unresolved connection elsewhere still prevents shutdown. The budget decision must therefore cover the combination and timing of changes needed to finish. Counting the work affordable within one allocation answers a narrower question.

Greis describes the constraint directly: “The problem is that a program like this has a minimum level of commitment below which it cannot complete, and the debt framing gave the CIO no way to say so.” In his illustration, that minimum comes from the systems that must move together and the preparation their transition requires. A funding proposal should explain those dependencies so the board can understand why a smaller allocation may make retirement infeasible.

Without that explanation, each subsequent request can look like another discretionary payment against a long-term liability. The CFO reduces the request, the CIO accepts the reduction, and the team continues with the work it can afford. Repeating this negotiation can sustain activity while deferring the changes required for shutdown. Decisions that appear careful within each budget period can collectively prevent the approved objective from being reached.

The delay matters because the organization continues to carry the old platform’s operating costs and fragile dependencies while paying for the transition. Greis calls indefinite continuation “the most expensive possible outcome.” His argument concerns the combined burden of unfinished modernization and an existing system that remains necessary. Any immediate saving from a reduced allocation needs to be weighed against the additional time during which both obligations continue.

Staged funding can still work, provided the stages preserve a feasible transition. The board can authorize spending over time while maintaining the resources, timing and dependent work required for completion. If it reduces the commitment, the proposal should identify the corresponding change in schedule, scope or feasibility. The CIO must make that consequence explicit when seeking approval, so permission to continue carries a credible route to retirement.

Measure changes in core-system dependence

Even a feasible funding plan needs a progress measure that shows whether the relevant dependencies are changing. Greis’s second illustration examines that reporting problem: an enterprise spends five or six years updating customer-facing applications, moving analytics to the cloud and replacing collaboration tools. Eventually, its inventory shows that a majority of applications have been modernized. The count records substantial delivery, but leaves the business effect unclear.

The business effect depends on which systems those applications still require. Greis identifies the general ledger, policy administration platform, core banking engine and order management system as examples of underlying systems that may remain in place. The relevant platform varies by enterprise, but each can continue supplying essential data or processing transactions for newer applications. Easier replacements can therefore raise the modernization count while leaving these dependencies intact.

In Greis’s illustration, every new application still depends on the unchanged systems for data and transactions. The inventory records a replacement even though the relationship to the old platform persists. As Greis explains, “When something in the core changes, the modern layer breaks. When the business asks for a new capability, the answer still runs through the old platform.” The visible application has changed, while the underlying constraint on business delivery remains.

For engineering and product leaders, that constraint determines how much freedom the replacement actually creates. A requested capability that requires changes to an older transaction system still has to fit that system’s requirements and dependencies. The application team may have met its immediate objective while leaving the wider delivery constraint in place. Progress reporting needs to describe both results so executives can judge what the completed work enables.

The same distinction applies to operating cost and risk. In Greis’s scenario, risk, run cost and the time needed to deliver new capabilities have barely improved despite the rising modernization percentage. The CIO must explain why completed replacements have produced so little change in the outcomes the board expected. An application count alone cannot explain this because it gives each replacement equal weight regardless of its effect on core-system dependence.

A more useful report keeps the count and explains what each replacement changed operationally. The board can then recognize completed work while seeing whether the systems responsible for continuing cost, exposure and delivery constraints remain in place. This reporting choice also influences future budgets: if leaders reward the count alone, they may keep favoring easier replacements. Reporting can then steer investment away from the harder changes needed to alter business outcomes.

Make the consequences clear to funding decision-makers

Because reporting shapes investment, CIOs and IT directors need to connect technical constraints to the decisions executives control. They can draw on what they already know about their systems, but need to make that knowledge usable by the CFO, chief executive officer and board when they set budgets and expectations. A board asking “why is this taking so long?” needs to understand which remaining dependencies determine completion. The answer should connect each necessary change to the commitment and timing it requires.

A clear explanation also depends on teams being willing to describe current conditions openly. Greis says, “The word debt carries an implication of fault and that has distorted how organizations view their own systems. In my experience, teams are far more candid about what they are carrying when describing it does not sound like a confession.” His experience as a consultant gives a further reason to distinguish ordinary aging from an earlier shortcut. A less accusatory description may make the information needed for planning easier to obtain.

That information matters when executives change a proposal. If they assume every funding reduction produces a proportionately smaller improvement, they can set expectations that interdependent systems make infeasible, weakening the expected return on investment. Present-day accountability rests with the decision they are making now: a lower commitment needs an explicit consequence for the schedule, scope or feasibility of retirement. The approval should record that consequence so the delivery promise matches the resources and dependencies the organization has agreed to support.

Key highlights

• Classify the obligation: CIOs need to distinguish approved shortcuts, unauthorized commitments and ordinary system aging before seeking funding. Each calls for a different decision about repayment, governance or modernization.
• Fund a feasible retirement: CFOs and CIOs need to agree on the dependent changes required to shut down an old platform. Staged funding must preserve a path to completion, with budget reductions tied to explicit changes in scope, timing or feasibility.
• Measure changes in business constraints: Modernization reports need to show how completed work changes core-system dependence, operating cost, risk and delivery time. Application counts alone can obscure the constraints that remain.
• Make budget consequences explicit: CIOs need to explain which remaining dependencies determine completion and how funding changes affect them. Board approvals should record those consequences so delivery expectations match the commitment authorized.