Will AI modernize your legacy system, or just rewrite it?

AI can translate a ten-thousand-line legacy application into a modern language. The harder question is whether it knows which strange-looking pieces of that code are bugs, workarounds, or business rules the company cannot afford to lose.

In February 2026 that question moved a share price. Anthropic published guidance on using Claude Code to modernize COBOL, and IBM had its worst trading day since 2000, down 13%. IBM’s reply, repeated across the coverage, was that translating code is not the same as modernizing it⁴⁵.

Both sides have evidence. This is what it says.

Is AI actually good at legacy migration?

At the mechanical end, yes, and at scale.

• Amazon used its own assistant to upgrade more than half of its production Java systems to Java 17 in under six months. It reports the equivalent of 4,500 developer-years saved, and 79% of the AI-generated changes shipped without further edits⁸.
• Morgan Stanley built a tool that reads legacy code and writes plain-English specifications from it. The bank says it saved developers more than 280,000 hours in its first half-year⁹.
• Bupa rebuilt its customer app off an end-of-life framework, with AI reverse-engineering the business logic first. Its CIO reports a project estimated at 18 months delivered in seven. (The account is sponsored content, from Infosys.)¹⁰

Look at what these have in common. Either the behavior being preserved was mechanical, as in a language-version upgrade, or someone turned the code into a written description before any new code was generated. None of them asked a model to rewrite a complex system and infer the business from the old code alone.

What happens when the logic is complex?

Two studies from this year measured it directly.

In the first, Claude Code migrated twelve features of a corporate ERP from Visual Basic 6 to C#. Before the run, a researcher catalogued 160 business rules and 171 database operations by hand, then checked the migrated features against them. Simple features came out 92% equivalent. The two complex ones came out at 47%¹.

The failures were not syntax errors. An approval workflow for meter readings was missing entirely. A purchase request that should wait for approvers was created as open, with the approver email and the bypass rule both gone. Validations that lived in form events, outside the domain classes, did not make the trip. The authors’ conclusion is that teams should state important restrictions explicitly instead of relying on the agent to infer them. Two complex features is a small sample, and they say so.

The second study ran eight telecom and banking scenarios across three models. Single-prompt and chain-of-thought migrations compiled and ran, and passed none of the gold-standard behavioral tests. The best multi-agent setup passed 19.4%². One finding cuts against an easy story: that system correctly extracted about 91% of the rules. It understood them and still failed to carry them across. Part of the gap is plain generation quality, and that part is improving with every model release.

Why can code that compiles still change what the business gets?

Because a large share of legacy behavior is implicit. Federico Tomassetti, whose company builds migration tools for RPG, lists the cases that slip past a compiler in RPG-to-Java work³:

• Division. RPG truncates. Java’s BigDecimal rounds or throws. The difference is a fraction of a cent per record, which shows up in year-end bonus totals.
• A lookup that finds nothing. In RPG the record keeps its previous values, and some programs depend on that. A clean rewrite resets them to zero.
• State between calls. Variables persist across calls in the same job. Only a test that calls the program twice will notice they no longer do.

None of these is hidden. Each is in the code. Each looks, to a reader who has not been burned by it, like an accident of the old platform rather than something the business relies on.

Can tests prove a rewrite is behaviorally equivalent?

They can prove it matches. They cannot tell you whether matching is right.

The standard advice holds: characterization tests before the rewrite, golden datasets, and old and new running in parallel on production data. Engineers who have run mainframe migrations describe equivalence testing as the slowest part of the project, full of manual, stateful steps, and in one account large enough that testing alone was estimated in thousands of days.

Two limits remain once you have done all of it. Tests generated from the old code share its blind spots, since nobody writes a test for behavior nobody knew about. And a perfect equivalence run reproduces everything, including the rounding error that overcharges one customer segment and the workaround for a partner who left in 2014.

Every modernization reaches the same fork, one behavior at a time: keep it identical, or fix it. Equivalence answers the first. Only knowing why the behavior exists answers the second.

What does AI need to know that the code does not say?

The teams that have reported success converged on the same move.

Luciq tried to modernize a decade-old mobile SDK with agents in late 2025. The agent could infer intent from the code, and often inferred it wrongly. Asking it when a user session starts gave different answers depending on which part of the codebase it was reading. The team found about 1,066 behavior patterns the new version had to honor. What worked was a spec-first rewrite, with engineers writing the intent down and agents building against it. Their conclusion: the real limit is whether people can write down what they want built, and review, not generation, became the bottleneck⁶.

An engineer migrating a Scala service to Java reported the same arc. Handing the whole project to an agent failed. Splitting it into modules failed. What worked was one agent writing the business logic and expected behavior into a document, and a second agent implementing from that document, piece by piece, under supervision⁷.

Morgan Stanley’s tool, from earlier, is the same idea at bank scale: get to the written description first.

So the input that decides the outcome is not more code in the context window. It is four facts per behavior: what the rule is, why it exists, whether it still applies, and who depends on it.

What happens when the people who knew are gone?

Spec-first assumes someone can write the spec. For a system built in the last few years, someone usually can. For one that has run for twenty, the reason for a rule is often in a contract, an incident review, an email thread, or the memory of an engineer who has since left.

In the Hacker News discussion of the COBOL announcement, one engineer put the timeline plainly: learning COBOL takes about a week, learning a particular system takes months¹¹. Others pointed out that the people who know those systems are retiring. That is the knowledge a migration consumes, and the one input no model can generate. It is also why an agent left to infer intent tends to treat the odd branch as noise, the failure we covered in why AI tools get your business rules wrong.

So, will AI modernize the system or just rewrite it?

The evidence gives a clear split.

AI is reliable at translation, at mechanical upgrades, and at reading old code and describing it. Its behavioral fidelity on complex, implicit logic is poor today and getting better. Even if it reaches perfect equivalence, that is a faithful copy, not a modernization. Deciding what the new system should do is a business decision, and it needs the reasons.

The projects that worked had the intent written down before generation began. The ones that struggled asked the model to infer it. AI rewrites the code. Modernizing the system still depends on someone supplying the why.

Where organizational memory fits

AppThentic reads a company’s systems, finds the business rules in them, asks the person who owns each rule why it exists, and keeps the answer with its source, owner, date and status. That record is Organization Memory.

Before a migration, that gives the team a rule inventory with a reason and a status on each entry. Rules marked Unknown or Disputed are the questions to settle before generation starts, not after a parallel run finds them. Coding agents read the same record over MCP while they work. See AI coding tools.

Before you hand a legacy system to an agent

1. Pick one module. List every rule in it that involves money, dates, status, region or customer type.
2. Mark each one as a business rule, a workaround, a bug, or unknown, and write down who can say which.
3. Decide keep or fix for each rule before any code is generated.
4. Run old and new side by side on production-shaped data, including the not-found paths and repeated calls.

Step two is where most teams discover how much of their system nobody can explain. If you want to see that list for your own systems, book a walkthrough.

Sources