Every mid-market company has one. The system that runs something the business cannot stop doing — billing, scheduling, dispatch, inventory — written by somebody who left, on a stack nobody hires for, with a database schema that has grown a decade of exceptions. It works. Everyone is slightly afraid of it. And every proposal to modernize it starts with a rewrite that would take eighteen months and cannot be paused.
That is the shape of the problem. What follows is how the work actually goes when it goes well, and the honest test for when the right answer is to leave it alone.
The rewrite is not the plan. It is the thing that keeps not happening
Big-bang replacement fails in a predictable way, and it is worth naming because the failure is structural rather than a matter of effort.
A rewrite has to reach feature parity before it can ship anything. Feature parity with a system that has absorbed ten years of edge cases means discovering those edge cases, and the only complete specification of them is the running code plus the people who know which parts are load-bearing. So the project spends its first several months in archaeology, produces nothing shippable, and burns exactly the political capital it needs later. Then something urgent happens, the team gets pulled, and the half-built replacement becomes a second system to maintain.
Now there are two systems. This is worse than one.
Put a seam in front of it instead
The alternative is unglamorous and it works: stop trying to replace the system and start intercepting it.
You put an interface in front of the legacy system — an API, a queue, a thin service, whatever fits — and route traffic through it. On day one that interface does nothing but pass calls through. Nothing has changed and nothing has broken. But you now have a place to stand.
From there, one capability at a time moves behind the interface. Reads before writes. Reporting before transactions. The pieces nobody would notice going wrong before the pieces that would end up in a newspaper. Each move is small enough to ship on a Tuesday and reverse on a Wednesday, and the legacy system keeps running the parts that have not moved yet.
The pattern has a name — strangler fig, after the plant that grows around a host tree until it is self-supporting — and the important property is not the metaphor. It is that every intermediate state is a working system. There is no month where the business is running on something half-finished, because there is no half-finished thing.
Where AI has changed the calculus
Here is what is genuinely different about the last two years, and it is not that AI can read legacy code.
The reason legacy systems survive is that the cost of putting a seam in front of them never quite justified itself. You would spend three months building an integration layer to enable… what, exactly? Slightly better reporting? The business case was always thin.
AI integration changes that arithmetic, because the thing you want to connect — a model that reads a request and acts on it — needs precisely that seam and cannot work without one. Suddenly the integration layer is not overhead on a modernization project. It is the deliverable, it pays for itself in the workflow it unlocks, and modernization becomes a side effect of doing something the business already wanted.
That is the honest version of “AI as a modernization driver”. Not that the model rewrites the system. That the model finally gives you a reason to build the interface you should have built in 2019.
What to do first, in order
Sequencing is most of the value, so here is the order that survives contact with a real system.
- Find out what actually calls it. Not what the documentation says. Turn on logging at the boundary and watch for a full business cycle — a month if there is month-end processing. Every modernization plan that skipped this step discovered an undocumented nightly job in production, usually at the worst moment.
- Write down what must never break. Two or three things, named, with the consequence attached. “Invoices go out on the 1st” is a constraint. “The system should be reliable” is not, and cannot be tested against.
- Put the seam in and change nothing else. Ship a pass-through. Prove it is invisible. This is the step people want to skip because it delivers no features, and it is the step that makes every later step reversible.
- Move a read first. Something with no write path and a human who will notice if it is wrong. You are testing the process, not the capability.
- Only then move something that writes. With the old path still live and a way back.
The test that saves the most money: before any of this, ask what happens if the system stays exactly as it is for another three years. If the answer is “it costs us some manual work and mild embarrassment”, that is not a modernization project. It is a budget line for the manual work.
When the honest answer is to leave it
Not every legacy system should be touched, and a firm that only ever recommends work is not giving you advice.
Leave it alone when the system is genuinely stable, the people who understand it are not leaving, and nothing you want to build next needs to talk to it. Stability plus institutional knowledge plus no integration pressure is a system that is fine, however unfashionable its stack.
Leave it alone when the real problem is the process rather than the software. If the process varies by whoever is doing it, no new system fixes that — it encodes the variation and makes it harder to change.
Leave it alone when the vendor is about to make the decision for you. If the platform has an announced end-of-support date, the migration is happening on their calendar and a modernization project now competes with it for the same people.
And be honest about the case where it should have been replaced two years ago but the window has closed: if the only person who understood it has already gone, the first phase is not modernization, it is reconstruction, and it needs to be scoped and staffed as such rather than smuggled in under a different name.
What this looks like as work
This is labour and judgement rather than a product with a license key. The platforms involved — the cloud accounts, the model providers, whatever queue or gateway sits in the middle — you hold in your own name and pay for directly, the same way you would license a database. What Leverage Automated does is the sequencing, the seam, and the part where somebody has to be accountable on the Tuesday it goes wrong.
If you have a system you cannot turn off and something you want to connect to it, the useful first conversation is not about the stack. It is about which capability moves first, and what must never break while it does.
Related reading: What API integration costs you after it ships — the maintenance bill that does not appear in the quote, which is most of what a seam costs over time. And From ChatGPT chaos to integrated AI — what happens when the model is a place people go rather than something wired into the work, and your AI agents need a manager, not just an API key — who owns the thing once it is running. And technology due diligence: what actually moves the number — how a buyer reads the same deferred maintenance from the outside. The service page for this work is AI integration.