Every enterprise I work with gets to 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, and someone else wants to rip it out and replace it. The right answer is almost always neither.
What works is adding AI alongside the legacy system rather than inside it, one piece at a time. This is how I structure those projects.
Why rewriting first usually fails
A system that runs the business has built up years of business logic, edge cases and integrations that nobody wrote down. A rewrite means rediscovering all of it, usually under pressure, while the old system keeps running. History isn't kind to these projects.
The good news is that you don't need a rewrite to get value from AI. You add the intelligence around the old system and leave its insides alone.
The strangler fig, applied to AI
Martin Fowler's strangler fig pattern replaces pieces of a legacy system with new components over time, and it adapts well to AI work. My version goes like this.
- Don't replace anything in the legacy system. Add an AI layer beside it that reads the legacy data and writes back through whatever APIs already exist.
- Start with read-only features: search, summaries, suggestions, classification. They add value without touching the system of record.
- Bring in writes with a human in the loop. The AI proposes, a person approves and the legacy system records it.
- Once the AI has earned trust, auto-approve the routine cases. It keeps proposing, the system approves the safe ones and people handle the exceptions.
Each step lowers the risk. You never bet the business on accuracy you haven't proven, and the evidence builds as you go.
Four patterns that work
1. An AI search layer
This is one of the best first steps: high value, low risk. The legacy system holds thousands of records (customers, cases, contracts, claims), and finding the right one or pulling together what's known about it is often slow and hit-and-miss. An AI search interface that reads from the legacy data, or a replica of it, and can search, summarise and answer questions is usually a clear win.
Nothing changes in the legacy system, users get something new, and it's easy to roll back if it doesn't deliver.
2. An intelligent triage layer
For systems that take in work, such as support tickets, claims, applications or leads, an AI layer that classifies, routes and prepares items before they reach the legacy system is worth a lot.
The legacy system carries on doing its job. The AI layer cuts down what reaches it, improves the quality of what does, and makes routing decisions that used to take someone's time.
3. A decision support overlay
When people make decisions inside the legacy system (pricing, underwriting, approvals, prioritisation), an overlay that brings up relevant information, suggests options and explains its reasoning can make those decisions much more consistent without changing the workflow.
How you build it varies. Sometimes it's a sidebar in the legacy UI, if you can extend it. Sometimes it's a separate tool open alongside. A browser extension works well when you can't touch the legacy front end at all.
4. Agent-driven process automation
For repetitive multi-step jobs in the legacy system, like running reports, exporting data or bulk-updating records, AI agents can wrap the system's APIs (or drive its UI if they have to) and automate the workflow. It's more sophisticated and riskier than the other three, and it's also where the big labour savings are.
I'd make this your third or fourth project, not your first.
What goes wrong
Underestimating data access
The usual blocker isn't the AI. It's getting at the legacy data. APIs are missing or limited, the database is locked down, or the vendor charges for every integration. Start those conversations on day one, not in week six when you suddenly need the access.
Letting the AI write back without a clear contract
If the AI changes data in the legacy system, it should go through the same APIs and validation as any other client. Skipping them because they're inconvenient is how data integrity incidents happen.
Overpromising the timeline
AI-on-legacy projects look quick in the demo and slow in production, because the demo runs on clean test data and production has the real legacy mess. Plan a hardening phase between "it works in the demo" and "it's safe to roll out", and push back when someone wants to skip it.
Skipping evaluation
For any AI feature that affects business outcomes, you need a way to tell whether the answers were good, not just whether it returned one. Build the evaluation harness early. Without it you can't spot quality drift, compare model versions or defend the system when someone challenges its output.
Sequencing the work
On a typical legacy modernisation engagement, phase one takes 8 to 12 weeks. It covers the data access plumbing and one read-only feature, usually search or summarisation. The aim is to prove the integration and ship something users can feel.
Phase two, 12 to 16 weeks, adds decision support or a triage layer and aims to move a specific business metric in a way you can measure.
Phase three is ongoing. You expand the features, automate routine paths and start replacing pieces of the legacy system where it makes sense. By then, often eighteen months in, the AI layer is substantial enough that replacing parts of the old system is a smaller, safer project than it would have been at the start. That's the strangler fig doing its job.
What to do first
Don't rewrite the legacy system, and don't plan to yet. Pick one read-only AI feature that adds real value, get it in front of real users, and let what you learn from it shape every decision after. Starting with a big rewrite is almost always the wrong instinct, and getting that wrong costs far more than starting small.
Not sure where to start with your own legacy system? I'm happy to take a look with you.
