Inherit a fifteen-year-old ERP and the first big cost shows up before anyone writes a line. Reading it.

The person who wrote the commissions logic left in 2017. The docs describe a version of the system that stopped existing years ago. Billing is the module nobody touches, because the last person who did took down month-end close. It all works, mostly, and nobody can tell you why.

That reading problem is where AI earns its keep in a modernization. It won’t write your new system. It will do in weeks the part that used to eat half the budget.

What AI actually does in a legacy project

Two public numbers are worth knowing before you talk to any vendor, me included.

Morgan Stanley built an internal tool called DevGen.AI and pointed it at its old code starting in January 2025. By June it had gone through 9 million lines of COBOL and Perl and produced plain-English specifications, saving an estimated 280,000 developer hours, according to what Mike Pizzi, the bank’s global head of technology and operations, told the Wall Street Journal. It doesn’t rewrite anything, by design. It extracts the business logic, and engineers rebuild from the spec.

Amazon went the other direction and let AI change the code. Andy Jassy wrote that upgrading an application to Java 17 dropped from about 50 developer-days to a few hours with Amazon Q, that they moved more than half their production Java systems in under six months, and that the savings came to 4,500 developer-years. Keep in mind that’s Java to newer Java. Crossing languages, say Visual FoxPro to Python, is harder and needs a lot more human review.

The third job is the one I care about most. Characterization tests. Before you change a module, you want tests that capture what it does today, bugs included, so you can prove the replacement does the same thing. Writing those by hand against undocumented code used to take forever. Now a model drafts them from the source and your team reviews them.

Anthropic laid out that same sequence for COBOL in February: map dependencies, document, score risk per component, and only then translate. We wrote about the market reaction when IBM lost $31 billion that day.

The five strategies still apply. Their price tags moved.

• API wrapping puts a modern interface in front of the old system. It was already the cheap option, and AI doesn’t change much here.
• Re-platforming (lift and shift) moves the system to the cloud as-is. Version upgrades, the boring part, become close to routine.
• Refactoring cleans up the code without changing behavior. Characterization tests are what make it safe, and those are now cheap.
• Re-architecting splits the monolith. The dependency map stops being guesswork.
• Rebuilding from scratch now starts from specs extracted from the code instead of from someone’s memory.

I’d still argue against the full rebuild for almost any mid-sized company. AI makes it cheaper. It doesn’t make a single launch day less risky.

A month-by-month plan

This is how we structure the work at IQ Source, using the Strangler Fig pattern, where the new system grows around the old one and replaces it piece by piece.

When	What happens	What you have at the end
Month 1	Module inventory, dependency map, AI-generated docs reviewed with the people who use the system daily	A ranked list of modules by pain and by isolation
Month 2	Characterization tests on the first module, an API layer in front of it	A module you can replace safely, with nothing switched off yet
Months 3-4	The new version runs in parallel and gets compared against the old one	First module in production, traffic redirected
Month 5 on	Next modules reuse the map, the tests and the API layer	The old system shrinking, one piece at a time

Which module goes first, the one that breaks most or the one with the fewest dependencies? Who confirms that a weird rule is a bug and not a policy someone asked for in 2014? Do you trust the data enough to move it? Those get answered in month one, by people.

Where AI stops helping

AI tells you what the code does. Whether it should keep doing it is a different question, and only someone from operations can answer it.

Data migration is the other place I’d expect the schedule to slip. Old data carries twenty years of exceptions stuffed into free-text fields, and no model knows which of them still matter.

And keep the team that has maintained the old system in the room. They know where the traps are. Cut them out and you end up with beautifully documented code and none of the context.

If there’s a system in your company nobody wants to touch, put a number on what it costs you first. Our technical debt calculator gets you one, and the full approach is on our legacy modernization page.