Legacy Systems Are the #1 Barrier to AI Adoption. The Fix Isn't What You Think.

The demo was flawless. The agent parsed unstructured documents, matched them against policy rules, and surfaced a recommendation in seconds. The board loved it. The CTO authorised a production timeline.

Then someone pointed it at the real system. Fifteen years of customer records living in a nightly batch export. No API surface. Ghost schemas from three half-finished migrations. A permissions model that predates the concept of machine identity. The agent that looked unstoppable in the demo had no way to query live state, no way to act on current data, and no way to do the one thing it was built for.

We keep watching this happen. Agentic AI is the most hyped capability in enterprise technology right now, and the conversation is almost entirely about models, prompts, and frameworks. The thing actually killing these projects gets almost no airtime: the infrastructure underneath, and the way companies organise the work to fix it.

It is worth stating the fix plainly before the evidence. Stop treating the foundation as a prerequisite to get out of the way, and start treating it as the project. Sequence the unglamorous infrastructure work first, do it incrementally rather than in one big rewrite, and put the whole path, from legacy foundation through to deployed agent, under a single team's ownership. Everything below is why.

The bottleneck nobody put on the roadmap

Gartner predicts over 40% of agentic AI projects will fail by 2027. The reason is not that the models aren't good enough. It is that legacy systems can't support modern AI execution: no real-time APIs, no modular architecture, no event-driven data, no secure machine identity. Deloitte's 2026 survey says the same thing from the buyer's seat. The top barrier AI leaders name isn't talent or budget, it's integrating with the systems already in place. McKinsey's late-2025 State of AI report puts roughly 30% of organisations in the same camp, citing inadequate infrastructure and legacy systems as a primary barrier to adoption.

The economics are brutal. A Pega/Savanta study of 500+ enterprise IT decision-makers estimates the average global enterprise wastes more than $370 million a year failing to modernise legacy systems efficiently, with roughly $134 million of that coming from slow, resource-intensive transformation projects alone. (Those are modelled figures rather than self-reported losses, but even directionally correct, the scale is staggering.) Companies are spending billions on AI that requires modern infrastructure while spending 40% or more of their IT budgets maintaining the technical debt that blocks that infrastructure from existing. The money flows in both directions and meets in the middle, where it catches fire.

A plumbing problem, not a model problem

When a pilot stalls, the instinct is to look at the AI layer. Wrong model. Wrong prompts. Wrong framework. Hire a better ML engineer. Almost none of that matters if the agent can't reach the data it needs, when it needs it, with the permissions it requires, in a format it can reason about.

Look at what an agent actually needs from its environment. It needs real-time data rather than a CSV that landed in an S3 bucket at 3am. It needs a defined API surface rather than a green-screen terminal to scrape. It needs event-driven triggers rather than a database it polls every five minutes. And it needs an identity layer so the organisation knows what the agent did, why, and whether it was allowed to. Most systems built before 2015 offer none of this, and plenty built after don't either.

This creates a genuine paradox. AI is now the best tool we have for modernising legacy code. Large language models read COBOL, map undocumented schemas, and generate API wrappers in a fraction of the old time. But you can't point those tools at infrastructure that has no API surface or structured data access. You need AI to fix the legacy problem, and the legacy problem blocks you from deploying AI. So nothing moves.

Breaking the deadlock means doing four things, in order, before anyone builds an agent:

• Expose APIs first. If your core platform only emits batch files or proprietary desktop clients, no amount of AI sophistication helps. Wrap legacy systems in API layers, even read-only ones to start. Everything else depends on this.
• Replace batch with event-driven data. Agents don't run on yesterday's data. Moving from nightly ETL to event streaming is not an optimisation. It is a prerequisite for autonomy.
• Decompose the monolith. A single autonomous action in a monolith can cascade unpredictably. Carve out bounded services (the strangler fig pattern, not the big-bang rewrite) so agents have safe, defined domains to operate within.
• Make integration identity-aware. Every action must be attributable, auditable, and permission-bound. Deloitte found only 21% of organisations have a mature governance model for autonomous agents, against the 74% who expect to be running them within two years. That gap is where the serious incidents will come from.

This is boring, expensive work relative to building a demo. That is exactly why it keeps getting skipped, and why the pilot-to-production gap is really an infrastructure gap wearing a different label.

The big-bang rewrite is a trap with a new name

Faced with that list, some organisations conclude they need a total platform replacement. Rip it out, rebuild, migrate everything at once. We've watched that approach for 20 years and we know how it ends.

McKinsey and Oxford studied over 5,400 IT projects. Large ones (over $15M) run 45% over budget while delivering 56% less value than predicted, and just 1 in 200 delivered the intended benefits on time and on budget. The catastrophic overruns of 200% or more cluster in exactly the large, monolithic programmes a "rebuild everything" mandate creates. Birmingham City Council's Oracle ERP migration is the canonical recent case, where £38M ballooned to £114M and finance processes were forced back to manual. It isn't an outlier either. A 2020 study found 74% of organisations that start a legacy modernisation project never complete it.

Gartner now formally recommends continuous modernisation over one-off programmes. The approach that works is incremental: expose APIs on the highest-value systems first, add event streaming where agents need live data, and decompose one bounded context at a time. It is slow and methodical, and it works.

Two teams, one gap, and the project that dies in the seam

The most common failure we see isn't technical. It's structural. An organisation recognises it needs both legacy modernisation and an AI capability, so it hires two teams, one to fix the infrastructure and one to build the AI. Reasonable on paper, fatal in practice.

The AI team scopes its agent against an API that doesn't exist yet. The infrastructure team modernises without knowing what the agent actually needs. Both plans look sound in isolation. Then they try to integrate, and the assumptions don't match. The "real-time" data turns out to be overnight batch, the new API returns structures the agent can't reason about, and the identity model was never discussed. Battery Ventures found that 88% of AI agent pilots fail to reach production, with the top blockers being evaluation gaps (64%), governance (57%), and reliability (51%), every one of them an integration problem rather than a model problem. But with two teams, nobody owns the integration layer. It falls into the gap between two contracts.

A mid-market financial services firm hit this wall exactly. They had budget approved for an agentic layer to automate client onboarding decisions. Three months in, it had stalled. The core banking system exposed no real-time API, only a nightly batch export, so the agent had no way to query live account state. A separate vendor had been contracted to add an API wrapper, but that work was scoped independently and hadn't started. The AI vendor was waiting on the integration team, and the integration team was waiting on requirements from the AI vendor. Nobody owned the full path.

Vanrho proposed something different: a single four-week Discovery engagement that mapped the entire stack before any build scoping happened. That meant core banking constraints, data latency, the identity and permissioning model, and the agent's real execution needs, all assessed together by one team. The finding was uncomfortable but decisive. The nightly batch architecture could not be patched to real-time with an API wrapper, and the underlying data access layer had to be re-architected. Surfacing that in week three of Discovery, rather than month four of a build, saved the client from the most expensive kind of failure, the one where the money is already spent before anyone realises the approach was wrong.

From there, one team delivered a modernisation sequence, a revised scope, and a single fixed-price proposal covering both the infrastructure and the AI layer under one set of acceptance criteria. The client reached live agentic onboarding decisions within the revised timeline. The original two-vendor structure would have added an estimated 16 to 20 weeks of coordination overhead and left permanent ambiguity over who owned the seam.

The decisive call wasn't technical. It was organisational: refusing to start building until the full path was mapped, and refusing to split ownership across two teams that would spend more time coordinating than shipping.

The foundation is the whole game

Demand is arriving faster than the infrastructure to meet it. Today 23% of companies already use agentic AI to at least a moderate extent, and 74% expect to within two years. In the UK, AI adoption has jumped from 9% in 2023 to over 23% by late 2025, yet only 33% of use cases reach full production. Across Africa, over 40% of institutions have begun experimenting with or implementing significant GenAI solutions, with usage doubling in just ten months, according to McKinsey's 2025 survey of nearly 400 C-suite executives. The appetite is real and it is global. The readiness is not.

The organisations running production agentic AI in 2028 won't be the ones shopping for the best model or the most impressive demo today. They'll be the ones doing the unglamorous work of exposing API surfaces, replacing batch with event-driven architectures, decomposing monoliths into bounded services, and building identity layers that can govern autonomous action, and doing it under unified ownership.

So the question that decides whether you join Gartner's 40% that fail or the cohort that actually ships has nothing to do with AI. It is whether one team owns the full path from broken foundation to deployed agent, or whether that path is split across two.

Vanrho maps the full path from legacy foundation to deployed agent under single-team ownership: infrastructure and AI, one scope, one set of acceptance criteria. If your AI project is stuck behind systems that can't support it, let's talk about the sequence that unblocks it.