Anthropic has published details on how its own engineers use Claude Code to run large-scale code migrations, the kind of project that used to take years and a budget nobody wanted to approve. Jarred Sumner, co-founder of Bun, used Claude Code to port Bun's entire codebase from Zig to Rust: a million lines of code in under two weeks, with the existing test suite passing in CI before merge. Mike Krieger, co-lead of Anthropic Labs, moved a Python codebase to 165,000 lines of TypeScript over a weekend, using agents, phase gates, and adversarial review rounds to check the work as it went. Neither project was a proof of concept. Both shipped to production.
For an Australian business sitting on a legacy PHP monolith, an ageing .NET stack, or a mainframe job nobody wants to touch, the number that matters isn't the line count. It's the cost. Anthropic reports the Bun migration used around $165,000 USD in API spend, in the same order as a single senior engineer's fully loaded annual cost in Sydney (commonly AUD $180,000 to $220,000 once you count super, on-costs, and the opportunity cost of pulling them off other work). Delivered in weeks rather than a multi-year project, the downside risk changes shape too: a migration that stalls now costs a few thousand dollars and a wasted sprint, not a multi-year programme that quietly eats a budget line and a career.
What the migration actually looked like
Both migrations followed a similar shape. The old codebase became the specification: every function, every edge case, every quirky workaround was already there in working code, so the agent had a ready-made source of truth instead of a requirements document written by someone who left the company two years ago. The work was broken into thousands of small, largely independent units, files, modules, and services that could be migrated and checked in parallel rather than one long sequential slog. The existing test suite acted as an objective referee: when a compiler error or a failed test came back, that became the next task for the agent to resolve, not a meeting to schedule. Mike Krieger's team added an extra layer of adversarial review, diffing every command's output against the original before signing off, so the human check happened at the boundary rather than over every line of every diff.
Why this changes the calculus for Australian teams
Large migrations have always been possible. What's changed is the shape of the risk. A stalled multi-year rewrite is a familiar story in Australian IT departments: a programme that eats two or three years of budget, loses its original sponsor along the way, and gets shelved at ninety per cent parity because nobody can justify the last mile. When the same work compresses into weeks, at a cost in the tens of thousands of dollars rather than millions, the decision changes from a bet-the-department programme to something closer to a scoped project with a clear stop point. A Sydney or Melbourne engineering lead can trial a migration on one service, look at the API spend and the test results, and decide whether to keep going, without having signed up for a multi-year commitment on day one.
Here's what we're telling clients who are weighing up a Claude Code-led migration:
Don't wait for the existential trigger. A year of memory-bug patches, one chronic release bottleneck, or a hiring problem because nobody wants to touch the old stack is now reason enough to scope the work.
Budget in the tens of thousands of dollars for a well-scoped migration, not millions, and treat the downside as deleting the branch and trying again rather than a stalled multi-year programme.
Keep a real, passing test suite in place before you start. It's the difference between an agent that can check its own work against something concrete and one that needs a human reviewing every diff by eye.
Run the first migration on a service you can afford to get wrong, not the core ledger or the customer database, so the trial teaches you something before the stakes go up.
What to check before you commit
Not every legacy system is a good candidate for this approach. Before we scope a migration for a client, we look at three things:
Test coverage on the current codebase. Thin coverage means more manual review at every step, not less agent involvement, and it changes the cost estimate significantly.
How cleanly the business logic separates from platform-specific code. A codebase where the two are tangled together takes longer to migrate safely, agent or not.
Whether the team has the capacity to run a proper parity check before cutover, comparing old and new outputs side by side the way Mike Krieger's team diffed every command's output against the original.
A compliance note for regulated industries
If your legacy system sits inside an APRA-regulated bank or insurer, handles data covered by the Privacy Act, or touches anything AUSTRAC or ASIC would ask questions about, a faster migration doesn't remove the governance obligations, it just compresses the timeline they apply to. We still expect a documented test-and-review trail, a named human sign-off before cutover, and a record of what the agent changed and why, not just a green CI run. For clients in banking, insurance, and government work, that documentation step is usually the same size regardless of whether the migration takes two weeks or two years, so building it in from the start is worth the extra planning meeting.
If your Sydney or Melbourne engineering team has been quietly avoiding a migration because of the cost and the risk, that equation has moved. We help Australian businesses scope whether a Claude Code-led migration makes sense for their stack, starting with a straight answer on test coverage, cost, and where the real risk sits. Book a brainstorm with Automata AI and bring your worst legacy system.
