10decoders
The Slide That Says 50% Faster
Picture the steering committee. A slide says AI cuts migration effort by half, with a footnote pointing at Google. The budget is trimmed to match, the timeline loses a quarter, and the team is told to move quickly. Six months later the code has been translated in a fraction of the expected time, and the program is late anyway. Nobody lied on the slide. The number was applied to the wrong denominator.
Google's paper on internal code migrations, published on arXiv in January 2025, describes four case studies. In the Int32-to-Int64 migration across its ads codebase, 80% of the code modifications in the landed changes were fully AI-authored, and engineers estimated the total time to be about 50% lower. In a JUnit3-to-JUnit4 migration covering 5,359 files and more than 149,000 lines over three months, roughly 87% of the AI-generated code was committed without any change. Those are strong results, and they are worth taking seriously.
They also come with conditions the slide leaves out. The authors say simple prompting alone is not enough for anything but the simplest migrations. Their pipeline validates by building the changed files and running unit tests, people review the output like any other code, and in most cases a person had to revert at least some of what the model changed. Google also has large test suites and build infrastructure that most enterprise legacy estates lack. The 50% describes a fast code-change step inside an environment where validation already existed. Applied to a whole program with thin tests and undocumented behavior, it counts the wrong half.
AI shortens the step that was rarely the long pole. The estimate has to follow the long pole.
Where the Hours Actually Go in a Legacy Migration
Splitting a migration into workstreams shows quickly where an AI discount belongs. The table below is our working template, built from delivery experience and the Google findings above, not data from a controlled study. The right-hand column rates how badly a program suffers if the workstream is estimated as if AI had shortened it.
| Workstream | Likely effect of AI on effort | Risk if underestimated |
|---|---|---|
| Code translation | Large reduction when scope is clear and the rules are known | Lower |
| Characterization tests for undocumented behavior | Modest. AI drafts the tests, but a person must confirm each expected value against the running system | Critical |
| Parallel run and behavior comparison | Little. Bounded by calendar time and by business cycles such as month-end and quarter-end | Critical |
| Data reconciliation and edge cases | Modest. Rounding, null handling, and encodings still need a human to rule on each difference | High |
| Review of generated changes | Can rise, because output volume rises faster than reviewer headcount | Moderate |
| Cutover and rollback rehearsal | None. The drill takes the same hours whoever wrote the code | High |
Not sure your migration estimate holds up?
10decoders works with engineering and finance leaders on modernization programs that use AI for code conversion. We split your estimate by workstream, test the assumptions on a real module, and show where the schedule is exposed.
Book a Free AI Assessment →Why Validation Cost Does Not Shrink With Translation Cost
Validation is where a migration earns the right to go live, and it scales with how much behavior the old system holds, not with how fast the new code appears. If the legacy estate has few automated tests, someone has to establish what correct looks like before translated code can be judged. That means running the old system, capturing outputs, and agreeing with the business which of those outputs are intended and which are accidents everyone has learned to work around. A model can speed up the drafting of those checks. It cannot decide which quirks the business depends on.
Tests generated from the new code create a quieter problem, because they confirm what the new code does and say little about what the old code did. A translation can change rounding, date handling, or the treatment of nulls and still pass every test it wrote for itself. The comparison has to run against the legacy system's own behavior, on real data, over enough cycles to cover the awkward periods. That calendar time is fixed, and a program that has cut its schedule on the strength of faster coding has usually removed the slack that this work needs.
Perception adds to the risk. METR's 2025 trial found experienced developers working on familiar repositories took longer with AI tools while believing they had been faster. The study covered a different setting from migration, and the tools have moved on since, so it should not be quoted as a migration result. Its narrower lesson holds: how fast the work feels is a poor basis for an estimate. Measure hours from timestamps, and let the pilot, not the team's impression, set the discount.
One Discount on the Whole Program
A vendor or conference number is applied to total effort. Testing, comparison, and cutover keep their old hours or lose them quietly. Contingency is cut to fund the plan.
Discount Only Where It Applies
Effort is divided by workstream and the AI discount is applied to translation alone. Validation hours are written down for the first time, though still as assumptions.
A Pilot Sets the Numbers, Tranches Set the Pace
A measured pilot supplies hours per workstream. Funding is released in tranches tied to behavior-equivalence evidence, and the plan states its expected revert rate.
Checklist: What a Re-Baselined AI Migration Estimate Contains
Review your current business case against these items. Each should be answerable from a document, not from memory.
Fund the evidence, not the percentage of code converted. Conversion is easy to count and says very little about readiness.
What to do this week
01 Split the estimate into five lines
Open the current business case and break total effort into translation, characterization tests, behavior comparison, human review, and cutover with rollback. Apply any AI discount to the translation line only, and write the discount as a range. If the case cannot be split because the original numbers were a single figure, that finding is itself the first result of the exercise.
02 Run a two-week pilot on one real module
Choose a module of moderate size with known business rules and some production traffic. Record hours per workstream from ticket and commit timestamps, and count how many AI-generated changes reviewers corrected or rejected. This produces your own discount and your own revert rate, which will be more useful to a finance partner than any external figure.
03 Count the safety net before you size the work
Measure automated test coverage, the number of documented business rules, and the number of legacy outputs you can capture and compare, such as reports, files, and ledger postings. A thin net means characterization work comes first and the schedule should say so. Ask the business owners which behaviors they would refuse to lose, and list them as acceptance criteria.
04 Release funding in tranches tied to equivalence evidence
Replace a single program budget with tranches, each released on a defined slice passing behavior comparison over a stated period. Include a month-end close in at least one tranche. Keep a contingency line that a program owner cannot spend without a documented reason, because this is the line most often removed when a headline number arrives.
Let 10decoders Re-Baseline Your Migration Estimate
We split your business case into workstreams, run a measured pilot on one of your modules, count the safety net you already have, and give you a revised estimate with tranche gates tied to behavior-equivalence evidence. You leave with numbers your finance team can defend.