AI has made writing migration code much faster. Published migrations at Airbnb, Google, and Salesforce took 2x to 13x less time than each company's own manual estimate. AI has not made it faster to prove that the new code does what the old code did. So the business case for legacy modernization now turns on one question: how cheaply can you verify behavior?
One caution comes first. Most measured wins are framework and version migrations, such as moving tests to a new library or upgrading Java. Those projects started with tests that defined the correct behavior. A 30-year-old billing system often has none. For old systems, the tests are the first deliverable, not a given.
The Old Math: Pay to Maintain, Because a Rewrite Is a Gamble
The US federal government is the best-documented example. The Government Accountability Office reported in 2019 that about 80% of federal IT spending went to operating and maintaining existing systems. Its 2025 report found the same share: about $83 billion of planned fiscal 2025 spending at the 24 largest agencies.
The 2025 report covers the 11 most critical federal legacy systems. They are 23 to 60 years old and cost about $754 million per year to run. Eight of the 11 use outdated languages such as COBOL. Of the 10 systems GAO flagged in 2019, agencies had modernized only three by February 2025.
The reason is risk. Flyvbjerg and Budzier studied 1,471 IT projects. The average cost overrun was 27%. One project in six overran its cost by about 200% and its schedule by about 70%. A legacy rewrite is among the riskiest IT projects, because the old system holds business rules that nobody wrote down.
So the old decision was simple. Maintenance is expensive but known. A rewrite is a gamble. Most companies chose maintenance.
The New Numbers: Migrations in Weeks, Not Years
Several leading engineering teams have published measured results for large AI-assisted migrations.
| Company | Migration | Manual estimate | With AI | How they checked it |
|---|---|---|---|---|
| Airbnb | About 3,500 React test files, Enzyme to React Testing Library | 1.5 engineering years | 6 weeks | Jest, lint, and TypeScript checks on each file, with automatic retries |
| Salesforce | 57,000 unit tests to Jest | 6 years | 9 months | A two-month dual run of old and new pipelines |
| int32 to int64 IDs in Ads, thousands of files | Hundreds of engineer years (Google's estimate) | About 50% time saved (engineer estimate) | Only changes that pass unit tests, then code-owner review | |
| 39 migrations by 3 developers over 12 months | n/a | 74% of code changes written by the model, about 50% time saved | Tests and human review | |
| Slack | 15,000+ tests, Enzyme to React Testing Library | 10,000+ engineer hours | 80% of selected files converted, 22% of developer time saved | Every change checked by a person before merge |
Amazon reports the largest number. Its Java upgrade work with its own Amazon Q Developer saved, by Amazon's estimate, about 4,500 developer years and $260 million per year across tens of thousands of applications. It is a vendor measuring its own product, so read it as a direction.
In Google's JUnit 3 to JUnit 4 migration, 87% of the 5,359 files the model changed were committed with no human edit. At Airbnb, 75% of the files passed all checks in the first four hours.
The trend behind these results is steep. METR measures the length of software tasks, in human working time, that a model completes with 50% success. In its data, that length has doubled about every 4.2 months since 2023. GPT-4 handled tasks of about 4 minutes in 2023. Claude Opus 4.6 handled tasks of about 12 hours in early 2026.
Each new model generation can finish a larger change on its own. The size of the slice you can hand to an agent keeps growing.
What Stays Hard
Look again at the last column of the table. Every team checked the AI's code with machines before a person looked at it: tests, type checks, lint, or a parallel run of the old and new systems. The fast part is writing the new code. The slow part moved to four other places.
- Knowing what the old system does. A test migration has a clear target, because the old tests define the behavior. An old billing system often has no tests. Its behavior lives in the code, in the data, and in the heads of a few people.
- Proving the new system does the same. You need characterization tests that record the old system's outputs for real inputs, then run against the new code. For the most critical rules, formal verification can prove a property instead of sampling it.
- Reviewing the volume. Spotify reports that its latest backend Java migration took three days, and that reviewers now face 76% more pull requests. In Spotify's words, "the bottleneck moves from coding to decision-making." Our post on how Meta and Shopify verify AI-generated code covers review at that volume.
- Moving the data and cutting over. Data migration, parallel runs, and switchover planning are still mostly human work. We found no published measurements showing large AI savings there.
The New Business Case
The old business case compared two numbers: the yearly cost to maintain, and the cost of a rewrite times a large risk factor. The new case splits the rewrite into parts that changed by different amounts.
| Cost item | Before AI | Now |
|---|---|---|
| Understanding and documenting the old code | Months of senior time | Days. Agents read and document the code, and people check it |
| Writing characterization tests | Large, and often skipped | Much faster. Agents write tests that record current outputs |
| Writing the new code | The largest item | 2x to 13x faster in published cases |
| Review | Proportional to code written | Now the bottleneck. Plan reviewer time explicitly |
| Data migration and cutover | Large | Still large |
| Risk of hidden behavior | High | Lower, if the tests come first |
Two changes follow. First, the project gets cheaper overall, so systems that were not worth a rewrite a few years ago may be worth one now. Second, the order of work changes. Tests come first, because they make every later step safe and fast.
The essay The Commanding Heights by Will Manidis and Joe Roberts expects new owners to buy older companies and rebuild them around AI. Whoever does that will meet this business case first.
A Playbook for Legacy Modernization With Agents
- Map the code. Have agents read the codebase and write documentation: modules, data flows, business rules, and external interfaces. Engineers who know the system check the result.
- Start read-only. Add a read-only API over the legacy database or service, so new tools can use the data without touching production.
- Pin the behavior. Record real inputs and outputs. Turn them into characterization tests before any code changes.
- Change one slice at a time. Agents change one module per pull request. Every pull request must pass the characterization tests, the build, and type checks before a person reviews it.
- Prove the critical rules. For money, permissions, and compliance rules, add property tests or formal proofs.
- Run old and new in parallel. Compare outputs on live traffic before you switch, as Salesforce did with its two-month dual run.
- Budget review time. Plan reviewer hours for the volume of pull requests. Review is the new constraint.
Modernize Legacy Code With OpenNash Software Factory
OpenNash Software Factory maps legacy code, proves what it does, and then changes it, one verified pull request at a time. Our forward-deployed engineers run the work with your team:
- Map and document the codebase, including the business rules nobody wrote down.
- Pin behavior with tests before any change, and add formal verification where errors cost the most.
- Ship reviewed pull requests through your own CI, in parallel streams.
- Plan the data migration and cutover with parallel runs.
- Hand over a codebase your team understands again.
Book a call with an OpenNash forward-deployed engineer or email us at hello@opennash.com. In the first session, we review the legacy systems that cost you the most to maintain. Then we show you which ones deliver the highest business value and the fastest ROI to modernize.