The Migration You Postponed for Five Years Now Takes Two Weeks. Here Is What Actually Makes It Work.

The Backlog Item Nobody Wanted Just Became the Easiest Win

Every engineering organisation has a list of migrations it knows it should do and keeps postponing: the test library that stopped being maintained, the framework major version two releases behind, the date-handling library everyone agrees is wrong, the language runtime approaching end of support. None of them ships a feature. All of them take months. So they wait, and the cost of waiting compounds as more code is written against the old pattern.

In 2026 that calculation flipped, and the evidence is now public enough to plan around. In an August issue, The Pragmatic Engineer argued that LLM-assisted migrations make previously impractical work feasible, and that teams may simply stop avoiding them. The argument rests on a string of case studies from companies that published their numbers, and the numbers are striking even after the usual discount for self-reported results.

This matters well beyond the large tech companies that wrote the blog posts. Migrations are the part of software maintenance where AI's strengths line up almost perfectly with the task. The intent is already fully specified by the existing code. The target pattern is documented. Success can usually be checked mechanically: the build passes, the tests pass, the old import is gone. That is a much better fit for an agent than an ambiguous new feature, and it explains why migrations have quietly become one of the most convincing returns on AI coding tools.

It also explains why the topic keeps surfacing on Hacker News and engineering LinkedIn. Developers who are sceptical of agents writing new business logic often concede that they are good at this. The more useful debate is not whether AI can migrate code, but under what conditions it does so safely, and what the remaining human work looks like.

What the Published Case Studies Actually Show

Airbnb's write-up is still the reference case. The team moved nearly 3,500 React component test files from Enzyme to React Testing Library in six weeks, against an original estimate of 1.5 years of engineering time. The first bulk run migrated 75% of the files in four hours. Four more days of a "sample, tune, sweep" loop brought that to 97%, and engineers finished the remaining few percent by hand over roughly another week, using the generated code as a starting point.

Asana told a similar story in August 2026. Its migration off Enzyme had started in 2022 and, at the pace it was going, was still roughly five years from finishing. Using OpenAI's Codex with up to four agents in parallel, each pointed at a different directory, the team finished in about a week and a half of engineering time for around $11,000 in model usage and $1,000 in infrastructure. Its own estimate for doing the full scope by hand was about $6 million in fully loaded engineering time, a figure The Pragmatic Engineer described as a back-of-the-envelope number that is probably an overestimate. Even with a generous discount, the ratio is remarkable.

Google has published the most methodical account. Its experience report How is Google using AI for internal code migrations? describes an int32-to-int64 ID migration in Google Ads where 80% of the code modifications in landed changes were fully AI-authored and total time fell by an estimated 50%. A JUnit3-to-JUnit4 migration covered 5,359 files and more than 149,000 changed lines in three months, with about 87% of the AI-generated code committed unchanged.

Amazon's numbers are the largest and the least independently verifiable. Andy Jassy said the company's AI assistant cut the average Java 17 upgrade from about 50 developer-days to a few hours, saving an estimated 4,500 developer-years and $260 million in annualised efficiency gains. Those are internal estimates from a company selling the tool, so treat them as directionally useful rather than precise.

Then there is the case that dominated developer forums this summer. Bun's creator ported the runtime from Zig to Rust using a fleet of Claude agents, and The Pragmatic Engineer's breakdown puts it at about 535,000 lines of Zig, eleven days from planning to merge, 64 agents running in parallel at peak, and roughly $165,000 at API pricing. That is not a test-library swap. It is a language port of a production runtime, and it is the clearest signal yet that the ceiling on agent-driven migrations is higher than most teams assume.

The Counter-Example: Why Uber Went Deterministic

The most useful data point of 2026 may be the one where AI lost. Uber had more than 600,000 JUnit 4 tests spanning 15 million lines of code, and migrated more than 75,000 test classes to JUnit 5 in four months, modifying over 1.25 million lines. The team tried generative AI to migrate several test files at a time and that approach failed. It ended up using OpenRewrite to transform the code deterministically, and kept AI for debugging individual test and build failures. In the team's words, "a deterministic approach proved more practical than an AI-driven migration."

That is not a contradiction of the other case studies. It is a boundary. When a migration is mostly mechanical and the same transformation applies across tens of thousands of files, a deterministic rewrite rule is cheaper, faster, perfectly consistent and reviewable once rather than file by file. An LLM, by contrast, may solve the same pattern three slightly different ways across three files, and each of those differences is something a reviewer has to look at.

Spotify reached the same conclusion from the opposite direction. Its Fleet Management system had used deterministic scripts for years, and InfoQ's coverage of its QCon London talk reports that those scripts cut migration time from nearly a year to under a week for 70% of the fleet, while the remaining 30% resisted automation. Its background agent, Honk, was built for that remaining 30%. Spotify's own engineering blog notes that one dependency-updating script had grown to more than 20,000 lines of code just to handle corner cases.

The practical pattern that emerges is layered. Use codemods, OpenRewrite recipes or AST transforms for the uniform bulk. Use agents for the long tail of files where the pattern varies, the context matters, or a human would otherwise have to read every case. Teams that pick one approach for everything either waste money on agents doing work a regex could do, or waste months writing rules for edge cases an agent could handle in an afternoon.

The Real Prerequisite Is a Test Suite You Trust

Read the successful case studies closely and the same precondition appears in every one: an automated way to tell whether the migrated code still does what the old code did. Bun's port worked because its test suite is written in TypeScript and therefore does not depend on the language the runtime is implemented in. The Pragmatic Engineer lists an extremely robust test suite as one of the conditions that made the rewrite possible, alongside an engineer who knew the codebase intimately and a willingness to spend heavily on tokens without knowing the outcome.

Test-suite migrations are the friendliest case of all, which is why they dominate the public examples. The tests themselves define the expected behaviour, coverage can be compared before and after, and a migrated test that passes against unchanged production code is strong evidence that it still tests the same thing. A migration of production code with thin coverage has none of that safety net. The agent will produce code that compiles. Whether it behaves identically is something nobody can confirm.

There is also a darker failure mode. Spotify reported that early agents took shortcuts to get builds passing, including commenting out failing tests and downgrading Java versions. We covered this behaviour in depth in our article on coding agents that make tests pass without making code work. In a migration, where the goal is literally "make the build green on the new version", the temptation for the agent is structural, and the guardrails have to be too: protected test files, checks that test counts do not drop, and coverage gates that compare before and after.

So the first question to ask about a postponed migration is not which model to use. It is whether you can tell, automatically and quickly, if the result is correct. If the answer is no, the first project is characterisation tests around the code being migrated, and that is real engineering work that an agent can help with but cannot own.

Your Infrastructure Is Probably the Bottleneck, Not the Agent

Asana's post contains the line that every engineering manager planning a migration should read twice: "The agent was rarely the bottleneck — our own infrastructure was." The team ran into stale internal documentation and agent guidance that still recommended Enzyme, a lint step that sometimes took more than ten minutes, and mismatches between what passed locally and what passed in CI.

Each of those problems is invisible when humans do the work slowly, and crippling when agents do it quickly. An agent that iterates on a file ten times needs ten fast feedback cycles. Airbnb's long-tail files were retried 50 to 100 times, with prompts growing to between 40,000 and 100,000 tokens and pulling in as many as 50 related files. If each cycle waits on a flaky ten-minute pipeline, the economics collapse, and if local and CI results disagree, the agent optimises for the wrong one.

Asana also found that more scaffolding was not better. Tracked tickets, a running notes file, sub-agent parallelisation and a more detailed conventions prompt were all tried, and the team reported that almost all of it made things worse. Its final instruction was five sentences long. The lesson is not that structure never helps; Bun's port relied on a detailed porting guide and adversarial review agents. It is that the environment the agent works in matters more than the elaborateness of the instructions. We made the same argument in our pieces on agent-ready repositories and harness engineering.

In practice, preparing for an AI migration usually means fixing the build. Make the test command fast and deterministic, make local and CI checks identical, remove flaky tests or quarantine them explicitly, update the documentation and agent instruction files so they describe the target pattern rather than the old one, and give agents isolated environments so parallel runs do not trample each other. Bun learned that last point the hard way when agents running git stash and reset clashed with each other.

Review Capacity Decides How Fast You Actually Finish

Generating the migrated code is now the cheap part. Landing it is not. Google's report notes that its team deliberately limited the number of changes generated per week to avoid overwhelming reviewers, and that in the int32 migration engineers needed to revert at least some of the model's changes in most cases. Spotify's speakers at QCon were blunter: PR review, not code generation, is the new bottleneck, even as Honk reached 1,000 merged pull requests every ten days.

This is the same verification gap we described in our analysis of AI output outrunning QA capacity, concentrated into a few intense weeks. A migration that touches 3,000 files produces hundreds of pull requests, each of which someone with knowledge of the affected area should at least skim. Spotify's responses included a pull-request inbox that prioritises reviews by age, importance and expertise, auto-merging for low-risk changes such as documentation, and standardising the codebase so reviews become more predictable.

Review is also where migration risk concentrates. A mechanically correct change can still be wrong for that particular module: a timezone conversion that subtly changes a billing cut-off, an async conversion that alters ordering, a dependency upgrade that changes a default. Those are exactly the cases a domain expert catches in thirty seconds and a generic reviewer misses entirely. Routing reviews to the people who own each area is slower than spreading them evenly, and far safer.

When you plan an AI migration, budget it like this: a small amount for model costs, a moderate amount for preparing the codebase and pipeline, and the largest share for review, the long tail and post-merge monitoring. Teams that budget only for the first item finish generation in a week and then spend two months unable to merge.

Which Migrations to Hand to Agents First

Not every postponed migration is equally suited to agents, and choosing the order well is a large part of the return. The best first candidates are migrations with a well-documented target pattern, strong existing tests, and changes that are local to individual files. Test-library swaps, assertion and mocking library changes, logging and configuration API updates, deprecated-API removals and minor-to-major framework upgrades with good release notes all fit this profile.

Runtime and platform upgrades with hard deadlines are the next tier, and in the second half of 2026 there is no shortage of them. We have written about .NET 8 and 9 reaching end of support in November and Python 3.10 reaching end of life this month. Microsoft's own Azure blog reports a GitHub Copilot modernisation customer that cut total modernization effort by 70%, and cites a Forrester survey in which 91% of IT leaders said application modernisation is necessary to enable their AI plans. Treat vendor-published figures with care, but the direction is consistent with the independent case studies.

The hardest tier is anything where behaviour depends on subtle semantics: concurrency model changes, ORM or database engine swaps, date and money handling, security libraries, and language ports without a language-independent test suite. These are possible, as Bun showed, but they need the strongest verification, the most experienced reviewers and an explicit plan for running old and new paths side by side before cutting over.

A useful scoring exercise is to rate each postponed migration on three axes: how well its correctness can be checked automatically, how uniform the change is across files, and how much business risk sits in the affected code. High verifiability and high uniformity point to deterministic tooling. High verifiability and low uniformity point to agents. Low verifiability means the first job is building tests, whatever tool does the migration.

Where a Dedicated Team Fits in an AI Migration

The case studies share one more feature that is easy to overlook: each was led by engineers with deep knowledge of the codebase and the time to focus on it. Bun's port depended on its creator. Airbnb, Asana, Google and Spotify all assigned engineers to tune prompts, fix the pipeline, review output and finish the long tail. For most companies, that focused capacity is exactly what is missing. Product teams are fully booked with roadmap work, which is why the migrations were postponed in the first place.

This is where a dedicated development team is a good fit. At Stepto, we run migration engagements in three phases. First, readiness: we assess test coverage, fix slow or flaky pipelines, write characterisation tests where coverage is thin, and update agent instruction files so they describe the target state. Second, execution: we combine deterministic tooling for the uniform bulk with agent-driven migration for the long tail, with guardrails against test tampering and coverage checks before and after. Third, landing: we prepare reviewable pull requests grouped by code owner, handle the files agents could not finish, and monitor production after cutover.

Because our engineers in Serbia work in a time zone that overlaps the full European working day and the US East Coast morning, your code owners can review migration pull requests during their normal hours rather than waking up to a backlog from the other side of the world. Our web application modernization service covers larger rewrites, and if you only need one or two engineers to join your team for a specific upgrade, staff augmentation is the lighter-weight option.

The commercial case is simple. If a migration that was estimated at a year of internal engineering time can now be done in weeks, the most expensive way to do it is to keep postponing it. The second most expensive is to hand it to an agent without preparing the codebase, then spend months untangling the results. If you have a migration that has been sitting in the backlog for too long, talk to us about scoping it.