The business case for modernizing legacy systems in the AI era

The business case for modernizing legacy systems in the AI era

Last updated: July 2026

Legacy modernization used to be justified by two numbers: run cost and risk. AI adds a third, larger term to the equation, because systems that agents cannot read or act on are excluded from the productivity gains every board is now budgeting for. The baseline is already expensive: CIOs estimate tech debt at 20 to 40 percent of the value of their entire technology estate (McKinsey). Here is how to weigh standing still, wrapping, and rebuilding.

Key takeaways

What does standing still actually cost?

More than the maintenance line item shows. The clearest public benchmark is the US federal government, which spends about 80% of its $100+ billion annual IT budget on operating and maintaining existing systems; GAO's 2025 review of the 11 most critical legacy systems found eight running on outdated languages and seven carrying known, unpatchable security vulnerabilities. Private estates follow the same shape. Stripe's developer survey measured 17.3 hours of a 41.1-hour engineering week going to maintenance, debugging, and bad code, a 42% tax on the most constrained resource most companies have. And McKinsey found that 10 to 20 percent of budget nominally allocated to new products quietly drains into tech-debt remediation. Standing still is not a neutral option; it is a recurring charge with a rising rate.

Why does AI change the modernization math?

Because AI initiatives inherit the estate they land on. MIT's NANDA research found 95% of enterprise GenAI pilots deliver no measurable P&L return, and its diagnosis is integration: tools that cannot connect deeply to existing systems and workflows stall. An agent can only automate a process whose systems expose state through APIs with checkable permissions. A platform that only speaks through a green-screen session or a nightly batch export is invisible to it. That converts modernization from a cost-reduction project into an eligibility question: every roadmap item that assumes AI-assisted operations silently depends on data and systems the AI can actually reach. The cost of standing still now includes the compounding value of everything the estate disqualifies you from building.

Should you modernize or wrap?

Wrap when the core is stable and the need is access; modernize when the system itself has to keep changing. This post covers the investment decision. The engineering side, how to open legacy systems to AI agents without a full rewrite, is a sibling post worth reading alongside it.

When wrapping wins

Wrapping puts an API layer, and increasingly an MCP server, in front of the existing system so newer software and agents can read from it and write to it under governance. It wins when the core logic is correct and rarely changes: think a stable billing engine or a warehouse system that does its one job well. Wrapping costs months rather than years, retires no risk inside the core, and buys you AI eligibility now. It is the right first move for most estates because it generates evidence about which systems actually matter before you commit rebuild money.

When rebuilding wins

Rebuilding wins when change frequency is high, when the platform is decaying, or when the people who understand it are leaving. GAO's markers are a useful checklist: of the 11 most critical US federal legacy systems, eight run on outdated languages such as COBOL and assembly, four sit on unsupported hardware or software, and seven operate with known security vulnerabilities that cannot be remediated without modernization. Any two of those conditions on a revenue-critical system make wrapping a delay tactic, not a strategy.

Why full-exit projects keep failing

The tempting third option, a wholesale AI-powered migration off the old platform, has the worst track record. Gartner predicts more than 70% of mainframe exit projects initiated in 2026 will fail to produce the intended benefits because teams overestimate what GenAI code-conversion tooling can do against complex legacy code. Gartner's own advice for many environments is to use GenAI for modernization in place rather than migration off the platform. Our experience matches: AI assistance compresses the rewrite of a well-understood module, and does nothing for the module nobody understands. Incremental replacement, one bounded slice at a time behind the wrapper, keeps each failure small.

What does modernization unlock for AI adoption?

Three returns, in the order they arrive.

  1. Engineering capacity comes back first. McKinsey found companies that actively manage down tech debt free their engineers to spend up to 50% more time on work that supports business goals. That capacity is what staffs the AI roadmap.
  2. Agent eligibility follows. Once a system exposes clean APIs and permissions, it becomes a legitimate target for the agent-access architecture and the automations that follow.
  3. Compounding delivery speed is worth the most. A production-planning system we rebuilt for a European industrial client in 2025 moved from an overnight batch to a queryable service; the AI-assisted scheduling features that followed a quarter later were a small increment on top, not a second project.

This ordering is why our product engineering teams scope modernization and AI features as one programme, not two: the first pays for the second, and the second justifies the first.

Who should own the modernization decision?

The P&L that the system serves, not the technology function alone. McKinsey's first principle for managing tech debt is to treat it as a business issue: trace ownership of each system's debt to the profit and loss it supports, and reflect the "interest" cost in that unit's numbers. In our engagements this changes behaviour faster than any architecture review, because a product owner who sees the drag in their own margin stops treating modernization as an IT request competing with features. It also keeps scope honest. A business owner funds the slice that unblocks their roadmap; only a central IT budget funds a three-year replatforming with no committed consumer.

How do you build the case?

Price all three terms, not just the first one.

  1. Price the recurring charge. Sum the maintenance line, the Stripe-style engineering tax, and the 10 to 20 percent of new-product budget being diverted. This is what standing still costs per year.
  2. Price the risk retirement. Unsupported components and unpatchable vulnerabilities carry a probable-loss figure your security team can estimate; GAO treats these as first-order modernization triggers, and so should the business case.
  3. Price AI eligibility. List the roadmap items blocked because a system cannot expose state to an agent, and attach the value already claimed for them in board decks. This term is usually the largest and the least often written down.
  4. Then choose the smallest slice that moves all three numbers, wrap the rest, and re-run the case each budget cycle with production evidence instead of estimates.

What happens to this market next?

The market will force this discipline soon enough. Gartner expects 75% of mainframe exit vendors to pivot or cease operations by 2030 as one-size-fits-all migration promises collapse. The durable position is owning an incremental modernization capability inside your own delivery organisation, and the window to build one is the next two budget cycles, while the estate still has people who remember how it works.

see it in practice

See how we ship this

Production case studies where we put these ideas to work.