Short answers to what readers ask most about this topic.
Framework upgrades and language ports are repetitive, well-specified, and verifiable, exactly the shape AI agents handle well. How to run one safely with a test net.
Matthews Wong
Software Engineer
Key Takeaway
Legacy migrations, framework upgrades, and language ports are bounded, repetitive, and verifiable, which makes them a strong fit for AI agents run in headless batches. The one non-negotiable is a safety net: characterization tests that pin current behavior before a single line changes, so you notice when an agent modernizes a rule out of existence.
Legacy migration is the work nobody wants and every codebase eventually needs: move off the deprecated framework, port the old service to a supported language, bump the dependency that three hundred files still import. It is tedious, mechanical, and risky in the same breath, which is exactly why it is one of the best jobs to hand an AI agent.
The catch is that legacy code is legacy precisely because nobody remembers why it does what it does, and an agent will cheerfully rewrite behavior it does not understand. This guide covers why migration suits agents, how to build the safety net first, and where the work still goes wrong.
Most agent tasks are open-ended, and open-ended is where agents struggle. Migration is the opposite: the destination is defined, the transformation repeats across many files, and success is checkable against the old behavior. That shape plays to an agent's strengths.
Three properties make migration a standout use case:
Before you migrate anything, capture what the code does today. Characterization tests, which assert current behavior rather than intended behavior, turn the old system into an executable specification the agent must preserve. Without them you are trusting the agent's understanding of code nobody else understands either.
Once the net is in place, migration parallelizes cleanly. Headless mode lets you script one agent per module, so a failure in one unit stays isolated instead of derailing the batch:
# One headless agent per module, isolated failures
for mod in $(cat modules.txt); do
claude -p "Port $mod from Enzyme to React Testing Library. \
Keep behavior identical. Run npm test -- $mod until it passes." \
--output-format json >> migration.log
doneGive each agent one module and one passing-test target, not the whole repo. Small, isolated tasks keep failures contained, make progress easy to track in the log, and let you retry a single unit without rerunning everything that already succeeded.
A repeatable migration follows the same arc whether you are upgrading a framework or porting a language. Move in slices, and verify each slice before the next.
The failures cluster around the things legacy code hides. An agent reads syntax fluently but cannot see the tribal knowledge that never made it into the code: the workaround for a vendor bug, the ordering that a downstream job silently depends on.
Simon Willison's work on async code-research agents suggests a useful posture: let agents attempt migrations in throwaway or parallel branches, treat the output as a draft, and keep a human deciding what actually merges. The agent explores; you approve.
Agents confidently modernize undocumented behavior away. A quirk that looks like a bug is sometimes load-bearing, and an agent will clean it up without hesitation. Characterization tests are what catch this: without them the regression ships silently and surfaces in production weeks later.
Once one migration works end to end, the pattern scales, as long as the review gate scales with it.
AI agents are genuinely good at legacy migration, but only inside a harness that assumes they will get the subtle cases wrong. Build the characterization net, migrate in verifiable slices, fan out with headless runs, and keep a human on the merge button. Do that and the migration nobody wanted becomes a weekend of supervised batches instead of a quarter of dread.