Every enterprise wants to implement AI right now. Fewer are asking the harder question: what is that AI actually going to run on?
The adoption numbers make the ambition obvious. McKinsey's November 2025 State of AI survey, based on 1,993 respondents across 105 countries, found that 88% of organizations now use AI in at least one business function, up from 78% a year earlier. Only 39% report any measurable enterprise-wide EBIT impact from it, though, and most of that group puts the number under 5%. Just 7% say they've scaled AI enterprise-wide. Adoption is nearly universal. Value at scale is still rare. For many enterprises, closing that gap starts with legacy modernization
That gap has a fairly consistent cause once you look past the platform a company bought. AI performs only as well as the foundation it's built on, and for many enterprises, that foundation was never designed with AI in mind. It was designed decades ago, for a different set of problems, by people who are mostly no longer at the company.
Building that foundation is what legacy system modernization actually means in this context: work across four layers at once, the applications themselves, the data behind them, the infrastructure underneath, and the processes wrapped around all of it. Skip any one of them and the AI initiative tends to stall somewhere it's hard to trace back to a root cause.
Two Kinds of Debt Sitting Underneath Every Layer
Infrastructure debt is what happens when systems can't scale, connect, or move data fast enough to support AI workloads. It's expensive, but at least it's visible. You can see it in a budget line, a latency metric, an integration failure. A lot of it can be worked around too. An API layer or a piece of middleware can connect a legacy system to an AI tool without a full rebuild, and for a well-scoped use case, that's often enough to get something working.
Logic debt is a harder problem, and it's the one most enterprises never budget for. It's the business knowledge that exists nowhere except in code nobody has fully read in years: how a commission is really calculated once every exception and override gets factored in, which conditions quietly trigger a compliance hold, what the system does at month-end that never made it into a runbook. Infrastructure debt slows a project down. Logic debt tends to sink it after launch, quietly, in a way that's hard to trace back to its cause.
Enterprises routinely fund the first kind of debt and miss the second. That's a big part of why AI initiatives that clear every infrastructure hurdle still stall out. A large share of enterprises are still running systems of record built on VB6 from the early 2000s, monolithic ERPs held together with custom scripts, and databases whose schemas only really exist in the memory of one or two employees who are close to retirement. Connecting AI to a system like that without first understanding what it does doesn't make the risk go away. It just pushes the risk downstream, and it does so at machine speed.
Why the Foundation Is Harder to Fix Than It Looks
Ask most IT leaders what breaks when they try to layer AI onto a legacy environment and they'll usually point to data quality or integration gaps first. Those are real problems. By Gartner's count, at least half of generative AI projects were abandoned after proof of concept by the end of 2025, with poor data quality among the leading causes.
But data quality is usually a symptom rather than the disease itself. The deeper issue is that a legacy system's actual behavior and its documented behavior are rarely the same thing. That gap is a big part of why Gartner separately predicts that through 2026, organizations will abandon 60% of AI projects that aren't built on AI-ready data.
None of this means AI has to wait for a full rebuild before it can be useful. It means the risk in connecting AI to a legacy system isn't really the connection itself. It's doing that without first verifying what's actually on the other end, at every layer, not just the data layer that tends to get the most attention.
The Four Layers of an AI-Ready Foundation
Legacy modernization that actually survives contact with production AI works across four layers, and no single one of them is sufficient on its own.
Application modernization rewrites or re-platforms the legacy system, but the real risk here isn't generic technical debt. It's logic loss. A migration that rebuilds the interface but quietly drops a business rule can do more damage than not modernizing at all, because the failure doesn't show up at go-live. It shows up months later, in a decision or a compliance gap nobody can trace back to its source.
Data modernization consolidates fragmented data into a governed structure, but that only holds up if the business rules behind the data (why a record got flagged, why a value got overridden) get captured too, not just the data itself. Clean data without the logic that explains it is still an incomplete foundation.
Infrastructure modernization moves workloads onto cloud or hybrid environments built to scale for AI training and inference. It's necessary, and it's usually the layer companies reach for first, since it maps cleanly onto a budget line and a migration timeline. But elastic compute doesn't say anything about whether the workload running on it is actually correct.
Process modernization revisits the workflows the legacy system was originally built around, many of which were shaped by decades-old constraints that no longer apply. This is where the other three layers actually get put to use, as the basis for a better process rather than just a faster version of the old one.
Treated as four separate initiatives, these layers tend to compete for the same budget and stall each other out. Treated as one connected foundation, with the business logic extracted early and carried through each layer, they reinforce each other instead.
A Legacy Modernization Strategy for AI Transformation
So how do you actually make legacy systems enterprise AI-ready without betting the business on a multi-year rebuild? Enterprises that get this right treat legacy modernization and AI modernization as the same project rather than two separate ones, and tend to follow a fairly similar sequence even when the details differ by industry.
They extract before rebuilding anything. Before a line of legacy code changes, they map what the system actually does, not what the outdated documentation claims it does. This is where most legacy modernization projects quietly fail: requirements get guessed instead of extracted, and the gaps don't surface until after go-live.
They modernize data in parallel rather than waiting. Data-quality work compounds, so fixing it early makes every later step faster and more reliable.
They decouple monoliths and expose APIs where it makes sense. Even a partial move toward service-based architecture creates integration points AI tools can start using right away.
They migrate infrastructure with AI workloads in mind, not just hosting costs, so the elasticity is already there once the AI initiative actually needs it.
They build the AI and data platform layer, meaning the pipelines, governance, and MLOps foundation that turns "we moved to the cloud" into "we can actually deploy and monitor AI models in production."
And they pilot narrow, high-value use cases on the newly modernized foundation, using those pilots to validate the extraction work before scaling further.
The organizations that struggle tend to be the ones that skip straight to the last step, buying an AI platform and pointing it at systems nobody has actually mapped, without doing the earlier steps first.
The Cost of Getting the Sequence Wrong
The budget math already looks bad before AI even enters the picture. Deloitte's 2018 CIO survey found that the average enterprise spent 57% of its IT budget on operations and maintenance, versus just 16% on innovation, a split that still tracks with what most CIOs describe informally today.
The federal government is the clearest documented case. A February 2025 GAO report found that agencies spend roughly 79 to 80% of the government's $100 billion-plus annual IT budget just operating and maintaining existing systems, including 10 critical legacy systems, ranging from 8 to 51 years old, that collectively cost $337 million a year to keep running. As of that report, only 3 of those 10 had been modernized, six years after GAO first flagged them.
Layering AI investment on top of that ratio without addressing what's underneath it doesn't fix the imbalance. It just adds a new, highly visible cost line to an already strained budget. The failure pattern compounds too. RAND Corporation researchers, synthesizing interviews with 65 data scientists and engineers, cite estimates that AI projects fail at roughly twice the rate of non-AI IT projects. Every stalled initiative makes the next one, even a well-architected one, harder to fund and get adopted internally.
Where This Leaves Enterprise Leaders
If your organization is evaluating AI investment right now, the highest-leverage question probably isn't which enterprise AI platform to buy. It's whether anyone actually knows, end to end, what your systems are doing, across the application, the data, the infrastructure, and the process that surrounds them, and whether you can prove it. For many enterprises running on systems built ten, fifteen, or twenty-plus years ago, the honest answer is no, not with real confidence. That gap is the actual barrier between AI ambition and AI results, which is why legacy modernization for enterprise AI has to start with the foundation rather than the model sitting on top of it.
It's also the specific problem we've been solving at Expeed Software. Instead of relying on generative AI alone to infer what a legacy application does, with the hallucination risk that comes with that approach, our deterministic workflow engine extracts every function, subroutine, event handler, conditional branch, and database operation from the source code into a plain-English specification. It then calculates a mathematical Trust Score confirming the extraction is complete before a single line gets rewritten. About 80% of that process is automated. The remaining 20%, the nuanced business context, edge cases, and sign-off, goes to our engineers rather than back into a model.
That's really the difference between modernizing a system and simply re-platforming it. One gives you a foundation AI can safely build on. The other gives you the same unknowns, just running faster.
Curious what's actually in your legacy codebase? Talk to our modernization team about a free assessment.
Frequently Asked Questions
Why is legacy modernization important for AI adoption?
Because AI is only as reliable as the systems and data behind it. McKinsey's 2025 survey shows 88% of organizations already use AI somewhere, but only 7% have scaled it enterprise-wide. Legacy modernization for AI is what closes that gap, by fixing the application, data, infrastructure, and process problems that keep AI stuck at pilot stage.
Why can't enterprises just add AI on top of legacy systems?
In a narrow sense, they can. Integration layers and targeted modernization can support well-scoped use cases without a full rebuild. The risk isn't the connection itself, it's connecting to a system whose business logic nobody has verified, which is part of why Gartner cites poor data quality and unclear business value among the top reasons GenAI projects get abandoned.
How do legacy systems affect enterprise AI adoption?
They compound the problem through fragmented data, undocumented business rules, and IT budgets already stretched thin by legacy maintenance, leaving little room for the modernization work AI actually depends on.
What does "AI-ready" infrastructure actually mean?
More than clean data and modern APIs. Real AI-readiness means addressing infrastructure debt (systems too rigid to support AI workloads) alongside logic debt (business rules that exist only in undocumented code) across the application, data, infrastructure, and process layers. The logic piece stays invisible until an enterprise AI system automates the wrong version of a process.
