Every enterprise I work with has the same conversation eventually. They have a fifteen-year-old core system — an ERP, a claims processor, a case management platform — that runs the business. AI is on the agenda. Someone has suggested a rewrite. Someone else has suggested ripping it out and replacing it. The actual answer is almost always neither.
The pattern that works is incremental — adding AI capabilities alongside the legacy system rather than into it. Here's how I structure those projects.
Why the rewrite-first instinct usually fails
A legacy system that runs the business has accumulated years of business logic, edge cases, and integrations that aren't documented anywhere. Rewriting it from scratch means rediscovering all of that, usually under pressure, while the old system still has to keep running. The history of these projects is not kind.
The good news: you don't need to rewrite the legacy system to get the value of AI. You need to add intelligence around it, not inside it.
The strangler fig pattern, applied to AI
Martin Fowler's strangler fig pattern — incrementally replacing pieces of a legacy system with new components — adapts naturally to AI modernisation. The variation I use:
- Don't replace anything in the legacy system. Add a new AI layer alongside it that reads from the legacy data and writes back through whatever APIs already exist.
- Start with read-only capabilities. Search, summarisation, suggestion, classification. These add value without changing the system of record.
- Introduce write capabilities through human-in-the-loop. The AI proposes, the human approves, the legacy system records.
- Once trust is established, automate the approval step for safe cases. The AI continues to propose, the system auto-approves the routine ones, humans handle the exceptions.
This sequence reduces risk at every step. You don't bet the business on AI accuracy you haven't proven. You build evidence and confidence incrementally.
The four patterns I see work
1. The AI-powered search layer
One of the highest-value, lowest-risk first steps. The legacy system has thousands of records — customers, cases, contracts, claims. Finding the right one or summarising what's known about it is often slow and inconsistent. An AI-powered search interface that reads from the legacy data (or a replica of it) and provides intelligent search, summarisation, and answer-the-question capability is usually a clear win.
No changes to the legacy system. New capability for users. Easy to roll back if it doesn't deliver.
2. The intelligent triage layer
For systems that handle incoming work — support tickets, claims, applications, leads — adding an AI layer that classifies, routes, and pre-processes incoming items before they hit the legacy system is high value.
The legacy system still does what it does. The AI layer reduces what reaches it, improves the quality of what does, and provides routing decisions that previously took human time.
3. The decision support overlay
When users are working in the legacy system and making decisions — pricing, underwriting, approval, prioritisation — an AI overlay that surfaces relevant information, suggests options, and explains its reasoning can dramatically improve consistency without changing the underlying workflow.
Implementation varies. Sometimes it's a sidebar in the legacy UI (if you can extend it). Sometimes it's a separate tool the user has open alongside. The browser-extension pattern works well when you can't touch the legacy frontend.
4. The agentic process automation pattern
For repetitive multi-step processes that involve the legacy system — running reports, exporting data, updating records in bulk — AI agents can wrap the existing system's APIs (or screen-scrape its UI if necessary) and automate the workflow. This is more sophisticated and carries more risk than the previous patterns, but it's where significant labour savings live.
I'd treat this as the third or fourth project, not the first.
What goes wrong and how to avoid it
Underestimating the data access problem
The most common blocker on these projects isn't the AI side — it's getting access to the legacy data. APIs are missing or limited. The database is locked down. The vendor charges for every integration. Plan for this. Start the data-access conversations on day one, not in week six when you suddenly need them.
Letting the AI write back to the legacy system without a clear contract
If the AI is going to modify data in the legacy system, it should do so through the same APIs and validation that any other client would use. Bypassing those because they're inconvenient is how data integrity incidents happen.
Overpromising the timeline
AI-on-legacy projects tend to look fast in the demo and slow in production. The demo runs against clean test data. Production has the actual legacy mess. Build in a hardening phase between "it works in the demo" and "it's safe to roll out", and resist pressure to skip it.
Not investing in evaluation
For any AI capability that affects business outcomes, you need a way to measure whether it's actually working — not just that it returned an answer, but that the answer was good. Build the evaluation harness early. Without it, you have no way to detect quality drift, no way to compare model versions, and no way to defend the system when someone challenges its output.
How to sequence the work
For a typical legacy modernisation engagement I'll sequence something like:
- Phase 1 (8–12 weeks) — Data access plumbing and one read-only capability (usually search or summarisation). Goal is to prove the integration story and ship something users can feel.
- Phase 2 (12–16 weeks) — Decision support or triage layer. Goal is to demonstrate measurable improvement in a specific business metric.
- Phase 3 (ongoing) — Expand capabilities, automate routine paths, start replacing pieces of the legacy system where it makes sense.
By the end of phase 3 — often eighteen months in — the AI layer has often become substantial enough that replacing parts of the legacy system becomes a smaller, lower-risk project than it would have been to start with. The strangler fig works.
What I'd tell you to do first
Don't rewrite the legacy system. Don't even plan to, yet. Pick one read-only AI capability that adds real value, get it into the hands of real users, and let the lessons from that first ship inform every decision after it. The instinct to start with a big rewrite is almost always wrong, and the cost of getting it wrong is much higher than the cost of starting small.
If you'd like a second pair of eyes on where to start with your own legacy system, get in touch.
More Articles
Where AI Cost Actually Goes in 2026 (and What to Do About It)
Token prices keep falling but enterprise AI bills keep climbing. Here's where the money actually goes in production AI systems — and the patterns that bring it back under control.
MCP: The Quiet Standard That's Finally Making AI Agents Useful
Model Context Protocol has become the de facto way to plug AI agents into enterprise tools and data. Here's what MCP actually is, why it matters, and how to start using it in your own environment.