Most leaders have watched the AI conversation move at speed and quietly wondered how any of it applies to their own business. The reality for many organisations is a mainframe, a 15-year-old database or an ERP that nobody dares touch. That gap between where you are and where AI needs you to be is real, and it is one of the main reasons AI initiatives stall.
In the latest episode of Optimise, we look at how enterprise leaders can bridge that gap without putting the business at risk.
The legacy trap
Two numbers frame the problem. Around 73% of enterprise IT budgets go on maintaining legacy systems rather than building anything new. And roughly eight in ten enterprise AI initiatives are stalled by siloed legacy data.
The underlying issue is simple. You cannot run modern AI agents on brittle, monolithic databases without an adapted layer in between. The agent has nothing reliable to read from, so it cannot deliver the value you were promised.
Why rip and replace is the wrong answer
The obvious response is to rebuild everything. It is also the riskiest. Full rewrites carry a failure rate of 70 to 80%, and they typically take 24 to 36 months while the business waits for engineers to recreate logic that already works.
There is a second, quieter risk: losing your corporate memory. Decades of edge case rules, client-specific nuances and operational detail are baked into legacy code. Rebuild from scratch and some of it will be missed, or lost during the cutover.
Three pillars of pragmatic modernisation
- An anti-corruption layer. Place an abstraction API layer between your legacy systems and modern AI agents. It translates schemas in real time, so data is not simply moved from one place to another. It exists in both places at once, and nothing is lost.
- The strangler fig pattern. Replace legacy features gradually, subsystem by subsystem, around the edges of what is already live. Think of building a road: you construct the new one while traffic keeps flowing on the old one, and only redirect traffic when the new road is ready. You never close the road first.
- A unified data fabric. Extract, clean and index your legacy relational data into pipelines that AI can retrieve from quickly. Strip away the buzzwords and the goal is a properly built, well-managed data layer for your business.
Comparing the three paths
| Full rip and replace | Surface band-aid (SaaS) | Custom AI middleware layer | |
|---|---|---|---|
| Deployment time | 24 to 36 months | 2 weeks to 3 months | 8 to 12 weeks |
| Business risk | Very high | Low | Minimal |
| AI readiness | 2 to 3 years away | Shallow, limited data access | Immediate |
| IP Ownership | Yours, after a long wait | None | Full |
A SaaS tool sits on top of your business and only goes as deep as it can, which is usually not very deep. It is quick and low risk, but it is a band-aid rather than a long-term foundation.
Why a custom layer wins
Building your own middleware gives you the speed of a quick fix with none of the migration risk. Your legacy code stays untouched, you get zero downtime through a strangler fig approach, and you own the code assets outright. That means no vendor lock-in and no dependence on a SaaS provider’s pricing from one year to the next.
This is not usually something a business can do alone. Unless you are prepared to build an entire new division staffed with people who have done it before, you need an engineering partner with experience in complex, and often regulated, environments.
Your roadmap
- Map your core data dependencies. Identify the main data points and flows in your company.
- Build the anti-corruption layer that will safely expose legacy data to your AI agents.
- Deploy your autonomous AI agents on top of it.
It is a deliberately simple roadmap, and it starts with understanding what you already have.
Watch the full episode
New episodes drop weekly, with shorter clips published across LinkedIn and Instagram. If you want to follow along, subscribe to the Optimise channel and we’ll make sure you don’t miss what’s next.