Fleet 1.13:Teams are now shipping 5x more PRs with autonomous pipelines.See what's new →
FleetFleet
Use case

AI Agents for Legacy Code Migration

Legacy migrations stall because the scope is large, the risk is high, and there is always something more urgent. A team might decide to migrate from one framework to another, from one language version to another, or from one architectural pattern to another — and then watch the migration ticket sit open for two years while the codebase grows in both directions.

The underlying problem is that migration work is repetitive but not mechanical. Each file or module needs to be converted following the same pattern, but edge cases require judgment. This combination — high volume, repetitive, with judgment required for exceptions — is precisely where an agent-based approach makes a difference.

How it works with an agent fleet

A migration agent is assigned a set of files or modules to migrate. It converts each one following the pattern documented in the migration guide, runs tests, and opens a PR for review. Exceptions are flagged for human review rather than guessed at.

# Assign migration of a specific module
fleet task assign backend-dev "Migrate internal/auth from v1 to v2 API (see migration-guide.md)"

The agent prompt references your migration guide directly. For each module, the agent converts, tests, and opens a PR. Modules that fail tests after conversion are left with a comment explaining the failure rather than a broken PR.

The fleet pattern

Migration work is broken into per-module tickets. The watcher dispatches a developer agent for each ticket. Each PR is small enough to review safely. A tech-lead reviews for pattern adherence and flags anything that requires architectural judgment. Humans handle the exception cases; agents handle the volume.

Guardrails that matter here

  • Agent stops and publishes a blocker event rather than guessing on ambiguous migration cases
  • All tests must pass after migration before a PR is opened
  • Human architectural review required before merge — the agent converts, the engineer verifies correctness

Who this is for

Teams undertaking a large-scale migration where the pattern is clear but the volume is high. The migration needs to be well-documented before agents can execute it; Fleet accelerates execution, not planning.

Frequently asked questions

How do you handle parts of the migration that require judgment calls?

The agent publishes a blocker fabric event describing the ambiguity and stops work on that module. A human resolves the ambiguity, updates the migration guide, and re-assigns the task. The agent handles the clear cases; humans handle the exceptions.

Can agents coordinate on a large migration — for example, migrating the frontend and backend simultaneously?

Yes. Fleet sequences dependent work via the issue body: a frontend migration ticket declares "Depends on #N" pointing at the backend ticket, and the developer agent's `subscription_gate.dependencies_shipped: true` holds it back until the referenced issue is shipped.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.