AI for Legacy Code Migration: What Agents Can Modernize, and Where Rewrites Still Fail

AI legacy code migration means using coding agents to read, document, test and translate old systems so they can be replaced in pieces rather than rewritten in one high-risk program. The headline evidence is real but narrow. Amazon's CEO Andy Jassy wrote in August 2024 that its AI assistant cut the average Java 17 upgrade from about 50 developer-days to a few hours and saved the equivalent of 4,500 developer-years of work. That was a version upgrade inside one language, not a COBOL core rewritten as Java. The position taken here: AI has made understanding legacy code cheap, and that changes the economics of every modernization decision. It has not made behavior equivalence cheap, and that is where most programs still succeed or fail. Executives who fund AI to translate code before they fund the tests that prove the translation is right are buying speed on the easy half of the problem.

Key Takeaways

• AI is strongest at comprehension: documenting undocumented code, mapping dependencies and turning old programs into plain-language specifications. Morgan Stanley says its in-house tool has reviewed about 9 million lines of legacy code.
• Mechanical upgrades within a language are where the public evidence is strongest. Amazon reports shipping 79 percent of AI-generated upgrade code reviews without further changes.
• Translation across languages, such as COBOL to Java, is improving but unproven at scale. A 2026 academic benchmark found general models compiled less than half of their COBOL output.
• The hard parts are unchanged: business rules buried in code and data, proving the new system behaves like the old one, performance on new infrastructure, and the last 20 percent of edge cases.
• The right sequence is characterization tests first, then incremental replacement behind a strangler facade, with parallel runs and human review of translated business logic.
• Not every system should be migrated. Some should be wrapped with APIs, some translated, some rewritten and some retired.

Why Legacy Code Is an Executive Problem Again

Every large organization carries code nobody wants to touch: COBOL batch jobs, Java applications three major versions behind, stored procedures holding pricing logic, frameworks the vendor stopped supporting years ago. The problem was always visible. What changed is that the cost of addressing it has started to move.

The scale of exposure is clearest in government. The US Government Accountability Office reported in July 2025 (GAO-25-107795) that it had reviewed 69 federal legacy systems and identified the 11 most critical, run by 10 agencies and ranging from 23 to 60 years old. Eight of the 11 use legacy programming languages, seven have known cybersecurity vulnerabilities and four run on unsupported hardware or software. Of the 10 critical systems GAO flagged in 2019, agencies had completed only three modernizations by February 2025. GAO also notes that agencies typically spend about 80 percent of IT budgets on operating and maintaining existing systems.

The cost of waiting shows up in a crisis. In April 2020, as unemployment claims surged, New Jersey Governor Phil Murphy publicly asked for volunteers who knew COBOL to help keep the state's benefits system running, as reported by CNBC at the time. The code was not broken. The skills to change it quickly were missing.

The market noticed when the economics looked like they might shift. On February 23, 2026, Anthropic published a post arguing that Claude Code "can automate the exploration and analysis phases that consume most of the effort in COBOL modernization." IBM shares fell about 13 percent that day, their largest one-day drop since 2000, according to Reuters. IBM's response, voiced by senior vice president Rob Thomas, was that translating code is a fraction of the modernization problem and that much of the mainframe's value sits in the platform, not the language. Both sides are partly right, and the distinction between them is the decision this article is about.

For the broader framing of modernization options before AI entered the picture, see the executive guide to legacy modernization.

What AI Does Well in Legacy Migration

Comprehension and documentation of undocumented systems

The largest proven gain is in reading code, not writing it. Most legacy programs fail on understanding long before they fail on translation: the original authors have left, the documentation is decades out of date and the business rules exist only in the code.

Morgan Stanley built an internal tool, DevGen.AI, on OpenAI models and launched it in January 2025. It translates legacy code such as COBOL into plain-English specifications that developers then use to rewrite the system. The bank told the Wall Street Journal in June 2025 that the tool had reviewed about 9 million lines of code and saved an estimated 280,000 developer hours. The bank was explicit that full automated translation was less mature, and that developers stay in the loop.

Thoughtworks reports a similar pattern in a client case study for an automotive manufacturer with 15 million lines of COBOL. Its tool combines a language model with a knowledge graph built from the code's syntax tree. Reverse engineering a 10,000-line module dropped from about six weeks to about two. The same case study records that the client's subject-matter experts found the first generative AI outputs only 60 percent accurate, which is why the tool grounds the model in structural analysis rather than raw prompts. The projected saving of 60,000 person-days is a projection, not a realized figure.

Tests that pin current behavior

A characterization test records what a system does today, right or wrong, so any change that alters behavior is caught. Writing thousands of them by hand is why legacy programs stall. AI agents can generate them from code paths and production samples far faster, and AWS has added automated test generation to its mainframe transformation service. The value of a generated test depends entirely on whether a human confirms that the behavior it pins is the behavior the business needs.

Mechanical translation within a language

Framework migrations and language-version upgrades are where AI has the strongest public record, because the source and target share semantics. In his August 2024 post, Jassy wrote that Amazon had upgraded "more than 50% of our production Java systems" in under six months and that developers "shipped 79% of the auto-generated code reviews without any additional changes." Coverage of the post at the time reported Amazon's estimate of about 260 million dollars in yearly efficiency gains from better security and lower infrastructure costs. These are a vendor's numbers about its own product, but the task type matters more than the source: version upgrades are bounded, testable and repetitive.

Dependency and library upgrades

The same logic applies to replacing deprecated libraries, patching vulnerable dependencies and moving from one logging or HTTP framework to another. The work is tedious, well specified and easy to verify with an existing test suite. This is also where the debt that technical debt measurement surfaces can be paid down without a full program.

The Public Evidence, Read Carefully

Most published numbers come from vendors describing their own products. They are still useful if read by task type.

The vendor offerings are now mainstream. AWS Transform for mainframe became generally available on May 15, 2025, converting COBOL and JCL to Java and handling CICS, BMS screens and Db2, with later releases adding business-rule extraction and automated testing. IBM's watsonx Code Assistant for Z, announced in August 2023, targets COBOL-to-Java translation that stays interoperable with the rest of a z/OS application. Google Cloud offers a Gemini-based Mainframe Assessment Tool, a Mainframe Rewrite capability in preview, and Dual Run, which replays production traffic against the new system and compares outputs.

The academic picture is more sober. The April 2026 COBOL-Coder paper found that GPT-4o produced compilable COBOL 41.8 percent of the time on the COBOLEval benchmark, while a domain-adapted model reached 73.95 percent. General-purpose models scored near zero translating Java into COBOL. A July 2025 paper from IBM Research on evaluating watsonx Code Assistant for Z translations notes that proving two programs equivalent is undecidable in general, so quality has to be assessed with a mix of rule-based checks, tests and judgement. For how to test agent output systematically, see the agent evaluation and testing guide.

Migration Tasks and How Far to Trust AI

The pattern is simple. The closer the task is to reading, the more AI can be trusted. The closer it is to deciding what the system should do, the more it needs people.

Where Rewrites Still Fail

Business rules buried in code and data

A premium calculation in an insurance system may be split across a COBOL paragraph, a lookup table maintained by an operations team and a manual workaround nobody wrote down. An agent can find the code. It cannot know that the table is edited every January, or that the workaround exists. Thoughtworks argued in March 2026 that these priorities often depend on tacit stakeholder knowledge an AI cannot access.

Behavior equivalence

The new system has to produce the same outputs as the old one, including the old one's mistakes that downstream systems now depend on. A rounding difference in the fourth decimal place is invisible in a code review and very visible in a reconciliation. Equivalence can only be shown empirically, by running both systems on the same inputs. This is the single most underfunded line in most modernization budgets.

Performance and the platform

Mainframe batch jobs were tuned for decades against fixed overnight windows. Translated Java that is logically correct can still miss the window by hours. This is the substance of IBM's February 2026 objection: much of the value sits in the integration of hardware, transaction monitors and data stores, not in the source language.

The last 20 percent

Agents handle the common paths quickly, and progress dashboards look excellent for months. Then the remaining work is the edge cases, the exception handling and the obscure interfaces, and it takes as long as the first 80 percent. Programs that plan resourcing on the early velocity run out of budget at the point where experienced people matter most.

Translating the debt

A line-by-line translation reproduces the old design in a new language. Thoughtworks warns that direct translation risks carrying over existing constraints and outdated decisions. The result is Java that reads like COBOL, which the next team will find as hard to change as the original.

How to Structure an AI-Assisted Migration Program

Characterization tests first

Before any code moves, pin current behavior. Use AI to generate the tests, use production samples as inputs, and have business owners confirm which behaviors are intended. Anthropic's own February 2026 guidance makes the same point: define the target architecture and tests before any code changes.

Strangler pattern

Put a facade in front of the legacy system and route one capability at a time to new code. The old system shrinks gradually rather than being switched off in one weekend. AI speeds up each slice; it does not remove the need to slice.

Incremental cutover with parallel runs

Run old and new side by side on real traffic and compare outputs until differences are explained or fixed. Google's Dual Run and similar tools productize this. The cautionary case is the alternative. UK regulators fined TSB a combined 48.65 million pounds in December 2022 over its 2018 IT migration, finding the bank failed to organize and control the program adequately. Customers were affected until the bank returned to business as usual in December 2018.

Human review of translated logic

Every translated module that touches money, eligibility, safety or compliance gets line review by an engineer and sign-off by a business owner. Generated code that compiles and passes tests can still encode the wrong rule. Developer productivity numbers from AI coding assistants assume this review happens; they do not replace it.

Examples Across Industries

• Insurance policy administration. Decades of products, each with its own rating rules, often live in one system. AI documentation and rule extraction let the insurer move product lines one at a time to a new platform, closing old products rather than migrating them.
• Government benefits. Eligibility logic changes with every legislative session. The GAO findings show the cost of leaving it on unsupported platforms. AI comprehension helps agencies build the documented modernization plans GAO says most lack.
• Retail inventory. Replenishment logic in old batch systems drives stock levels across thousands of stores. Translation is feasible, but the test is whether the new system produces the same orders on a full year of historical data, including holiday peaks.
• Manufacturing execution systems. Plant-floor systems integrate with machines and quality controls, and downtime stops production. Wrapping with APIs and replacing reporting and scheduling modules first is usually safer than touching machine control.
• Bank cores. Core replacement remains the highest-risk case. Commonwealth Bank of Australia's SAP-based core replacement, announced in 2008 with a budget of 580 million Australian dollars over four years, ended up at about 1.1 billion Australian dollars over about five, according to reporting by Finextra and iTnews. For how banks are approaching this now, see mainframe banking modernization explained.

What It Costs Versus a Traditional Rewrite

A traditional rewrite spends most of its budget in three places: discovery and analysis, building and testing the new system, and the parallel running and cutover period. AI changes these unevenly.

The practical result is that AI compresses the front of the program and leaves the back mostly intact. Organizations that budget the savings across every line end up short at cutover. A defensible planning assumption is to take the discovery and code savings and reinvest part of them in testing and parallel running. Then measure the outcome as a business case against the cost of standing still, not against the vendor's headline savings.

The Decision: Wrap, Translate, Rewrite or Retire

The recommendation: start every program with AI-driven discovery across the whole portfolio, because it is cheap and it makes the wrap, translate, rewrite or retire decision evidence-based. Then route only the upgrade and well-understood translation cases to agents first.

The Position, and Its Tradeoff

The position: fund comprehension and testing before translation, and treat AI translation output as a draft that must earn its way to production through characterization tests and parallel runs.

The tradeoff is speed. A program that leads with tests will show less visible progress in its first quarter than one that leads with translated code, and boards often reward the visible progress. The organizations that accept the slower start avoid the more expensive failure mode: a large body of translated code nobody can prove is correct, discovered at cutover.

Frequently Asked Questions

Can AI convert COBOL to Java automatically?

AI can produce Java from COBOL, and vendor services from AWS, IBM and Google offer this. The output still needs characterization tests, parallel runs and human review of business logic. A 2026 academic benchmark found general models compiled less than half of the COBOL they generated, a sign that unverified output is not production-ready.

What is the best first use of AI in legacy modernization?

Documentation and dependency mapping. It is where the evidence is strongest, such as Morgan Stanley's report of about 280,000 hours saved, and it improves every later decision, including which systems not to migrate at all.

How long does an AI-assisted mainframe migration take?

There is no reliable public benchmark. Vendors claim timelines move from years to months, and Toyota Motor North America reported a 50 percent faster mainframe modernization with AWS. The parallel run and cutover phases are still bounded by business cycles, so a migration cannot finish faster than the month-end, quarter-end and year-end runs it must pass.

Is it cheaper to wrap a legacy system than migrate it?

Often, for stable systems that rarely change and still have people who can support them. Wrapping with APIs delivers access without migration risk. It does not reduce platform cost or skills risk, so it is a holding position rather than a destination.

The Bottom Line

AI has made legacy code legible at a cost that was unthinkable a few years ago, and that alone justifies a portfolio-wide discovery effort. It has not made migration safe. The organizations that will get value treat AI as a way to understand and test their systems faster, choose deliberately between wrapping, translating, rewriting and retiring, and fund the parallel runs that prove the new system works before the old one is switched off.