Use AI to Migrate a Framework Version

A framework version migration is close to AI's best-case scenario. The rules are known, the transformation is mostly mechanical, and you can verify the result against tests that already exist. React class components to hooks, Python 2 to 3, an ORM major version, a UI library upgrade: these are patterned changes repeated across hundreds of files. That repetition is exactly what a model handles better than a bored human doing find-and-replace at 4pm. The catch is that "mostly mechanical" hides the 5 percent that will break production if you let the model run wide.

Why migrations are where AI actually shines

Most AI coding tasks are open-ended. A migration is not. There is a source pattern and a target pattern, and the job is to apply the rule everywhere without introducing drift. The model does not have to be creative. It has to be consistent, and it never gets tired on file 240 the way a person does.

Better still, you have an oracle. The old behavior is the spec. If the tests passed before and pass after, the migration is correct for what the tests cover. That makes migrations far safer than net-new features, where correctness is a judgment call. This is the same reason characterization tests belong before any AI refactor: the existing behavior is the contract you are migrating against.

How to scope a framework migration for AI

Do not point the model at the whole repo and say "upgrade this." Scope it.

• Split the migration by pattern, not by folder. "Convert every class component with no lifecycle methods" is one clean batch. Components with componentDidMount are a different batch with different risk.
• Do the trivial batch first, fully, and merge it. Prove the loop works on low-risk files before you touch the hairy ones.
• Keep each batch small enough to review as a diff. A migration PR with 900 changed files is unreviewable, which means unsafe. Scope the task so it can succeed.
• Write the transformation rule down as a spec the model follows on every file. Writing the spec before the prompt is what keeps file 1 and file 200 consistent.

Where migrations quietly go wrong

The mechanical part is easy. The failures cluster in the edges:

Behavior that changed between versions, not just syntax. Python 2 division and Python 3 division are not the same. The model will happily "migrate" a line that now returns a different number. Only a test catches that.

Deprecated APIs with subtle new defaults. A library upgrade where a flag flipped from true to false will pass compilation and fail in production. Read the changelog yourself and feed the known-dangerous changes to the model as explicit warnings.

Half-migrated state. If the migration stalls, you now have two dialects in one repo. That is worse than not starting. Decide up front whether a partial migration is acceptable or whether it must be all-or-nothing per module. This is the same discipline as the strangler pattern for legacy code: controlled boundaries between old and new, never a blurry middle.

Verify before you trust

The migration is not done when the code compiles. It is done when behavior is proven unchanged. Run the full suite. Run it again. Where coverage is thin, add characterization tests before you migrate that area, not after. And review the generated pull request for the changes that compile fine but smell wrong, because those are where the 5 percent lives.

This is the kind of work I run through Bootspring: a bounded, spec-driven migration where the model does the mechanical volume and the gates catch the edges. For scoring how much migration risk a repo actually carries before you start, ReformCode is the tool I reach for.

The takeaway

Framework migrations are the task most worth handing to AI, because they are repetitive, patterned, and testable. Win by scoping tightly, batching by pattern, and treating the existing tests as the spec. The model does the volume. You own the 5 percent at the edges, because that 5 percent is the only part that can take down production.