Quick Summary
- AI speeds up legacy application modernization most where the change is repetitive and a test or compiler checks every edit.
- The strongest published gains are refactors and upgrades within the same language. Airbnb moved about 3,500 test files in six weeks against a 1.5-year estimate.
- Rewrites into another language have the weakest results so far. On one 2026 benchmark, agents succeeded least often at migrating code, and its publisher says every model showed the pattern.
- Retiring or keeping a system is a business decision AI does not change. For rehosting, vendor tools now automate the planning, though the published figures are the vendors’ own.
- Pick the approach first, build the checks second, then pilot on a small batch and measure what the AI actually finished.
Amazon used its own AI agent to upgrade tens of thousands of production Java applications. It estimates the work saved at over 4,500 developer-years.
In 2026, a benchmark of coding agents found that moving COBOL code to Java rarely worked.
Both findings are about legacy application modernization. They point in opposite directions because they describe different kinds of modernization.
That difference matters more than any headline speed-up figure. Whether AI shortens your project depends less on the model you choose and more on the modernization approach you choose. This guide maps the common approaches against the published evidence, so you can see where AI is likely to help a custom software development project and where it is not.
What Is AI Actually Speeding Up in Legacy Application Modernization?
Legacy application modernization means changing an existing application so it can keep running, and keep changing, on current platforms. That can mean moving it, upgrading it, restructuring it or replacing it.
Across the published cases, AI speeds up one kind of work far more than the rest: large volumes of similar code changes, each with a quick way to check whether it is right.
Three Published Cases
Three cases show the pattern.
- Google: In a 2025 case study, Google engineers used an LLM to widen 32-bit ID fields to 64-bit across Java, C++ and Dart code. Three developers ran 39 of these migrations over 12 months. The model generated about 74% of the 595 code changes, and the developers estimated the total time spent fell by half compared with earlier manual migrations.
- Airbnb: Airbnb migrated nearly 3,500 React test files from Enzyme to React Testing Library. It had estimated the work at 1.5 years by hand. It finished in about six weeks.
- Amazon: Amazon upgraded tens of thousands of production applications from Java 8 or 11 to Java 17 with its own code transformation agent. The 4,500 developer-years figure is Amazon’s estimate, based on the number of dependencies migrated, about a product Amazon sells.
What the Three Cases Have in Common
The three have a lot in common. Each change followed a known pattern: a type change, a test framework swap or a version upgrade, all within the same language. And a build or a test suite could say quickly whether each change worked.
The detail behind the Google numbers is worth reading. Counted by whole code change, only about a third came from the model alone. Another 38% were drafted by the model and finished by a developer. A person reviewed every change before it was submitted, and the 50% figure is the developers’ estimate, not a timed measurement. The speed-up came from the model doing the bulk of a repetitive job, not from taking people out of it.
Which Modernization Approaches Benefit Most From AI?
Most modernization plans start from a short list of options. Gartner published seven of them, ordered from easiest to hardest: encapsulate, rehost, replatform, refactor, rearchitect, rebuild and replace. AWS uses a related set for cloud moves, the 7 Rs. It merges refactor and rearchitect, calls replacement “repurchase” and adds relocate. It also adds two decisions that come before any code work: retire the application, or retain it as it is for now.
Here is each option, what AI changes about it, and how strong the published evidence is.
| Approach | What it means | What AI speeds up | Published evidence |
|---|---|---|---|
| Retire or retain | Switch it off, or keep it as it is for now | Usage and dependency analysis that informs the decision | Little. These are business calls |
| Encapsulate | Keep the core and expose it through APIs or a new layer | Reading the old schema and building the new layer | One published case (our own) |
| Rehost or relocate | Move to new infrastructure without changing code | Discovery, dependency mapping, wave planning and network changes | Vendor-reported (AWS testing and pilots) |
| Replatform | Move to a new runtime with minimal code changes | Version upgrades and dependency fixes | Large scale, but vendor-reported (Amazon’s Java upgrades) |
| Refactor | Restructure code without changing what it does | Repeated edits across many files, test migrations | Strongest (Google, Airbnb) |
| Rearchitect | Move the code onto a new architecture | Mapping dependencies and drafting service boundaries | Thin. Architecture choices stay with people |
| Rebuild | Rewrite from scratch with the same scope | Drafting new code, especially in the same language | Low success rates for cross-language rewrites in benchmarks |
| Replace | Swap in a new product | Mapping data and workflows to the new product | Little |
Reading the Table
The pattern is clearest at the refactor end: same-language changes with tests have the best evidence behind them. Cross-language rewrites have the weakest results. Rehosting involves little code, but AWS reports that its migration tool produced wave plans for 500 virtual machines in 15 minutes in its own testing. The middle rows are where most real projects sit, and where the evidence is thinnest.
Why Do Framework Upgrades Go Fast and Cross-Language Rewrites Don’t?
The short answer is feedback. A model gets faster at a migration when it can find out, quickly and cheaply, that an edit is wrong.
What a Working Feedback Loop Looks Like
Airbnb’s migration shows what that looks like in practice. Each file moved through a series of checks: refactor the test, make it pass, then clear lint and type checks. A file only moved to the next step once its check passed. The first bulk run migrated 75% of the files in about four hours. Four days of tuning prompts and retries took it to 97%. The last 3% took about a week of manual work, starting from the automation’s failed attempts.
What Happens When the Agent Cannot See the Tests
In April 2026, Factory published Legacy-Bench, a set of tasks in COBOL, Java 7, BASIC, C89, Fortran and assembly. The agents could compile and run their code, but the tests used to score them were hidden. Factory sells a coding agent, so treat this as vendor research. The method is published, though, and the findings are specific:
- Pass rates ran from 16.9% to 42.5% across the 12 model and agent combinations tested.
- Fixing bugs passed roughly twice as often as writing new features, which passed roughly twice as often as migrating code. Factory says every model it tested showed the same pattern.
- Migration success depended mainly on the target language. Fortran to C++ worked at a reasonable rate. COBOL to Java, Rust or C++ rarely worked.
- In 97% of the failed tasks, the agent believed it had succeeded.
Factory’s own explanation is that migration difficulty depends mainly on the target language. Our reading adds a practical point. In a real rewrite, the check that would catch these errors usually does not exist yet and has to be built first. Until it is, an agent that reports success is not evidence of success, and the errors tend to surface late, in testing or after cutover.
Where the Evidence Is Disputed
Not everyone draws the line in the same place. Centric Consulting argues that AI agents deliver the highest impact on rebuild and replace, refactor, and rearchitect work, because they compress the discovery work that made those options expensive. On refactoring, we agree. The difference is rebuilds and rearchitecting, where Centric’s figures come from its own engagements and press release rather than published measurement. Drafting code is clearly faster in the cases above. Proving that a rewrite behaves like the old system is another matter. We found no published measurement showing it gets faster by the same amount, and the measured gains are strongest where that proof is cheap.
What Does This Mean for an AngularJS, PHP or .NET Application?
Most mid-sized companies are not modernizing mainframes. Their legacy is an AngularJS front end, an old PHP or Laravel version, or a .NET Framework application the team avoids changing. That is useful news, because much of this work is a refactor or an upgrade in the same language, which is the part with the strongest evidence.
Framework Migrations, Such as AngularJS to React
Some of it is still harder than Airbnb’s case. An AngularJS to React migration stays in JavaScript or TypeScript, but templates become components, and that is a design change rather than a find-and-replace. AI helps component by component, provided each component has a test or a visual check behind it. Expect a longer manual tail than a pure test migration.
Encapsulation: Keep the Core, Add a New Layer
Sometimes the best option is not to change the core at all. In one project TOPS Infosolutions has published as a case study, the client’s SQL Server ERP stayed as the source system, and nothing writes to it. We built a Claude-based assistant that reads it through a read-only MCP server with 43 tools. By the case study’s account, ad-hoc management reports that took analysts one to two days now take minutes, and the build took about 4.5 months. That is the encapsulate option: the business got a new way to use the system without a migration. We wrote up how we build MCP servers for AI agents separately.
How Should You Run an AI-Assisted Modernization Pilot?
Treat AI as a way to run one approach faster, not as an approach in its own right. A short pilot tells you more than any vendor’s percentage.
1. Choose the Approach for Each Application First
Use the table above. If an application should be retired, AI will not change that decision. If it should be rehosted, the help comes from migration tooling rather than code generation.
2. Build the Check Before the Change
A build, type checks and a test suite are what made Airbnb’s and Google’s migrations fast. If the application has no tests, write tests that record what it does today, including its odd behavior. These become the standard every AI edit has to meet.
3. Pilot on a Bounded Batch
One module, one service or a few hundred files. Small enough to review in full, large enough to show the long tail.
4. Measure Three Numbers
- The share of the batch the AI completed and that passed every check.
- The share that needed a developer to finish.
- The developer hours spent on that remainder.
5. Budget for the Long Tail
Airbnb’s last 3% took about a week. On older or less consistent code, expect the tail to be bigger.
6. Keep a Person on Review
Google’s developers reviewed every change, even with automated checks in place. A team with experience running Claude Code on real codebases will know which outputs to trust and which to read line by line.
What Will AI Not Speed Up?
Some of the slowest parts of any modernization are not code changes at all.
- Choosing the approach: deciding to retire, keep or replace an application depends on cost, risk and business plans the code does not contain.
- Recovering business rules: AI can explain old code, but someone who knows the business still has to confirm what it is supposed to do. Our piece on what actually gets faster in legacy modernization covers the research on AI-written documentation.
- Data migration and cutover: moving live data, running old and new systems side by side and switching over are planning and operations work.
- Signing off: agreeing that the new system behaves like the old one is still a human decision, and Legacy-Bench shows why the agent’s own verdict is not enough.
A Limit on the Evidence Itself
As of November 2026, we found no independent study that measures total time or cost savings from AI-assisted modernization across many organizations. The big numbers come from companies reporting on their own work or their own tools. That includes Google’s developers’ estimate, Airbnb’s result against its own estimate, and Amazon’s and AWS’s figures for their own migration tools. It also includes Factory’s benchmark and our own case study. They are useful signals. They are not a forecast for your codebase.
Where Should You Start?
In legacy application modernization, start with the approach, not the tool. AI has made refactors and same-language upgrades much faster where tests exist. Cross-language rewrites have the weakest results. For rehosting, the reported gains are in planning and network work rather than code, and deciding what to retire is still a business call.
So the useful first step is an honest inventory: which applications need which approach, and which of them already have the tests that let AI work quickly. That is the same assessment we start with on digital transformation projects, before anyone writes new code.
Frequently Asked Questions (FAQs)
No. In the Google and Airbnb cases, people designed the process, built the checks and finished the work the AI could not. Google’s developers also reviewed every change. On harder tasks, agents often report success when they have failed, so a test suite and a reviewer still decide what ships.
Refactors and upgrades that stay in the same language, where a build or test suite checks every change. That is where the published gains are largest. Rewrites into a different language have the lowest success rates in published benchmarks so far.
Less than with code changes. Rehosting moves an application without changing its code, so there is little code for AI to write. Vendor tools such as AWS Transform now automate discovery, wave planning and network changes, and AWS reports large time savings from its own testing and partner pilots. Testing and cutover still need careful planning.
Not for that reason alone. AI drafts new code faster, but we found no published measurement showing that proving a rewrite behaves like the old system gets faster by the same amount. Check first whether a refactor, an upgrade or a new layer around the existing system gets you the same business result with less risk.
Measure it on a small batch before scaling. Track the share of work the AI completed that passed every check, the share a developer had to finish, and the hours spent on that remainder. Compare those against your own estimate for doing the batch by hand.
Yes, or something that does the same job. If the application has no tests, write tests that record how it behaves today and use them as the standard for every change. Without them, there is no fast way to catch a wrong edit, and that is where AI-assisted projects slow down.
