AI-assisted migration projects: 2026 patterns

AI-assisted migration in 2026 is a hybrid: deterministic AST-based codemods do the boring 80%, an LLM (usually Cursor agent mode or Claude Code) handles the idiom translation the codemod can't express, and a human senior owns the architectural calls. Test-first verification gates every file. PRs ship file-by-file, not in one heroic branch. The AI does not replace the senior; it makes the senior 4-6x faster on the migration class of work.

What actually changed between 2023 and 2026

Migrations used to mean one of two things. Either a senior engineer wrote a jscodeshift transform, babysat it for a week, and shipped a 4,000-file PR that nobody could review. Or a team did it by hand over six months and quietly gave up at 70% complete.

Both paths still exist. The 2026 pattern sits between them.

The shift is that LLMs got reliable enough to translate idioms (the wet, contextual rewrites that codemods can't express in an AST rule), and codemods got cheaper to author (Cursor and Claude Code can scaffold a working jscodeshift or ts-morph transform in 10 minutes). So the question stopped being "codemod or by hand" and became "where does each tool earn its keep on this specific migration."

The other shift is verification. Test-first migration was always the right move; in 2026 it's also the only way to stay sane when an agent is editing 200 files in a session. If your test suite can't tell you whether useEffect(() => fetch(url), [url]) got translated to the right useQuery shape, no amount of AI helps.

The hybrid pattern in one paragraph

Run a codemod first to do the mechanical 80%. Then point Cursor agent mode or Claude Code at the remaining files, file by file, with a prompt that includes the conversion rules, the test command, and the rollback rule. Open a PR per file (or per small folder) so reviewers can actually read the diffs. A senior makes architectural calls (does this enzyme test get rewritten as React Testing Library or deleted entirely?). Repeat until done.

The five-stage pattern, in order

1. Scope and inventory (humans only, 1-2 days)

Before any AI runs, a senior reads the codebase and writes a short doc:

• What's being migrated (Mocha → Vitest, Enzyme → React Testing Library, Webpack → Vite, Express → Hono, JavaScript → TypeScript, AngularJS → React, REST → tRPC).
• What's explicitly out of scope (we are not touching the integration test runner; we are not rewriting the auth flow).
• Architectural decisions that the AI is not allowed to make: which files get deleted vs. converted, which patterns get standardized, where breaking changes are acceptable.
• A "weird stuff" list: every file or module that doesn't fit the standard pattern. These get hand-converted at the end.

This doc becomes the system prompt for every downstream tool. Skip it and the AI confidently rewrites the one file that was deliberately weird because of a production incident in 2024.

2. Codemod for the mechanical 80% (1-2 days)

Write or generate a deterministic transform that handles the easy rewrites. The right tool depends on the language:

• JavaScript / TypeScript: jscodeshift, ts-morph, or the new oxc-transform from the Oxc team.
• Python: LibCST or the AST module with Bowler on top.
• Go: gopls rename / golang.org/x/tools/go/ast.
• Rust: syn plus a small CLI wrapper.

In 2026 you don't write the codemod by hand. You describe the transformation to Cursor agent mode with three before/after examples, and it scaffolds a working transform you tune over an hour. The codemod handles imports, simple API renames, syntactic rewrites, and anything that's structural rather than contextual.

The codemod is run, the test suite is run, and the PR ships. This is usually the largest single PR of the migration (sometimes thousands of files), but because every change is mechanical, it reviews fast.

3. AI for the idiom translation (the bulk of the time)

This is where Mocha-to-Vitest stops being syntax and starts being judgment. beforeEach and describe map cleanly. But sinon.stub(obj, 'method').returns(x) translates to vi.spyOn(obj, 'method').mockReturnValue(x) only sometimes; other times the right rewrite deletes the stub entirely because Vitest's vi.mock does it at the module level.

A codemod can't know which. An LLM with the test file open, the source file open, and a 5-rule prompt almost always can.

The 2026 working setup:

• Cursor agent mode, with the rules file pinned to the migration scope doc.
• Run on one file at a time. Use Cursor's "compose" or the agent loop to: read file, propose rewrite, run the test command, iterate until green, stop.
• For codebases that don't fit Cursor (monorepo with custom build, or you're already in Claude Code), the same loop in Claude Code works: claude --read src/foo.test.ts --read src/foo.ts --command "npm test src/foo".
• For batch operations across a whole repo, Sourcegraph Cody Batch Changes drives the same loop across hundreds of repos, opens PRs, and tracks rollout. It's the closest thing to a 2026-grade migration orchestrator.

The senior's job during this phase: review every PR, reject the ones where the AI made an architectural choice that should have been a human call, and update the system prompt when a new pattern emerges.

4. Test-first verification (every step, no exceptions)

The migration is only as trustworthy as the tests. Three rules that catch 90% of regressions:

• If a file has no tests, write tests first (with the AI, against the pre-migration behavior), then migrate.
• Every PR runs the full test suite, not just the changed files. AI-assisted migrations love to break shared mocks.
• For migrations that change runtime behavior (Webpack to Vite, Jest to Vitest), add a smoke test that boots the app and hits five real routes. The unit suite passes; the runtime breaks; the smoke test catches it.

This is the part teams skip when they're behind schedule. It's also the part that turns a migration into a six-month incident.

5. File-by-file PR cadence (not one heroic branch)

Long-running migration branches die. They die because main moves, conflicts pile up, and the migration starts blocking feature work. The 2026 pattern: ship to main constantly.

A working cadence:

• Codemod PR: one big mechanical PR, reviewed in a half-day, shipped.
• Idiom PRs: one PR per file or per small folder. Most reviews are 5-10 minutes because the diffs are small and the test suite is green.
• Cleanup PR: at the end, one PR that deletes the old dependency, the compat shims, and the migration scope doc.

For a 400-file migration, expect 30-60 PRs across 2-4 weeks. That sounds like a lot until you compare it to the alternative (one 400-file PR that sits open for a month).

Comparison table: migration patterns in 2026

Pattern	What it is	Best for	Time on a 400-file migration	Risk
Pure codemod (2018 era)	Hand-written AST transform, one big PR	Pure syntactic rewrites (import renames, API renames)	1-2 weeks senior time, all PRs trivial	Misses anything contextual; you ship a half-finished migration with TODO comments
Pure hand migration	Human edits every file	Highly contextual rewrites (test runner with custom matchers)	8-16 weeks, often abandoned	Migration dies at 70%; team carries two stacks forever
AI agent only (no codemod)	Point Cursor agent at every file	Small codebases (<100 files), simple translations	1-3 weeks but expensive on API tokens	Inconsistency across files; agent makes architectural calls it shouldn't
Codemod + AI hybrid (2026)	Codemod for mechanical 80%, AI for the rest, human for architecture	Most real-world migrations	2-4 weeks with one senior, 4-6x faster than pure-hand	Lowest, if test coverage is honest
Cody Batch Changes	Codemod or AI loop driven across many repos	Multi-repo migrations (microservices)	1-2 weeks setup, 1 week rollout	Coordination tax on PR review

What AI does badly in migrations (the honest part)

This is the section the breathless "AI replaces engineers" posts skip.

• Architectural decisions. When the AI hits a file where the right answer is "delete this whole module and replace it with a 30-line version," it will dutifully translate the 400 lines instead. Senior judgment is the only fix.
• Cross-file invariants. If your migration requires that every component that uses LegacyProvider also gets a corresponding useNewContext hook update, the AI working on file 47 doesn't know about file 312. Codemods (or a custom verification script) catch this; agents alone don't.
• Test quality assessment. The AI happily migrates a test that was always wrong. If expect(true).toBe(true) was passing before, it'll pass after.
• Performance regressions. The translated code compiles and tests green and runs 3x slower. Profiling is still human work.
• The political stuff. "Should we keep the legacy module for the on-call rotation that depends on it" is not an LLM question.

You can read the deeper case for senior judgment in our AI-assisted refactoring playbook 2026, which covers a lot of the same prompt-as-spec discipline.

Tooling reference (2026 working set)

Codemod authoring: jscodeshift, ts-morph, LibCST, Bowler, the Oxc transform crate. Cursor agent mode for scaffolding the transform itself.

File-by-file agent loops: Cursor agent mode (the dominant choice for individual repos), Claude Code (better for terminal-driven workflows and large prompts), Aider (good for low-VRAM local model setups), Continue.

Multi-repo orchestration: Sourcegraph Cody Batch Changes. Nothing else is close for "run this transform across 200 microservices and open PRs."

Verification: Vitest, Playwright for smoke tests, Renovate for tracking dependency removal at the end, npm ls or pnpm why to confirm the old package is actually gone.

Observability: turn on production-traffic comparison if you can (record real requests against the old and new code paths). Datadog and Honeycomb both make this easy.

For the broader picture of how Cursor's agent loop is being used in production this year, see how to use Cursor's agent mode in production.

What to do this week if you have a migration on the roadmap

1. Write the scope doc. One page. What's in, what's out, the weird files.
2. Pick the migration class (test runner, framework, language, build tool). Each has a 2026 reference path; don't invent your own.
3. Scaffold the codemod with Cursor or Claude Code using three before/after examples. Ship the mechanical PR first.
4. Stand up the agent loop on the next 10 files manually. Tune the prompt until 8 of 10 PRs pass review without changes. Then scale.
5. Cap WIP at 3 open migration PRs. More than that and reviewers stall.

If you don't have an engineer with the experience to run this loop, that's a real constraint. Every engineer on Cadence is AI-native by default, vetted on Cursor / Claude Code / Copilot fluency in a voice interview before they unlock bookings. Booking a senior at $1,500/week to lead the migration (and a mid at $1,000/week to run the file-by-file PRs alongside) is one of the highest-ROI uses of the platform we see. You can decide your next move with a Build/Buy/Book recommendation tailored to the migration.

The ROI math is unsurprising: a migration that used to consume a senior for three months consumes them for three weeks instead. Our AI-native engineering ROI numbers for 2026 walk through the dollar version.

The honest summary

AI doesn't replace the senior on a migration. It removes the keyboard-time bottleneck. The thinking (scope, architecture, test quality, when to stop) is still entirely yours. What changes is throughput on the file-by-file translation work, which used to be 80% of migration calendar time and is now 20%.

If your team has the senior and the test discipline, the hybrid pattern works. If you don't, hiring or booking one is the prerequisite, not the AI tooling.

Ready to run a real migration with someone who's done this loop before? Cadence books a senior or lead engineer in 2 minutes, with a 48-hour free trial so you can see them ship the codemod PR before you pay for a single day. Get a Build/Buy/Book recommendation if you're not sure which tier fits your migration scope.

FAQ

Does AI-assisted migration actually replace senior engineers?

No. AI removes the keyboard-time bottleneck on file-by-file translation work. Scope, architecture, test quality assessment, and stop conditions are all still senior judgment calls. The honest framing: AI makes one senior 4-6x faster on migration class work, not 0 seniors infinitely fast.

When should I write a codemod vs. use an AI agent?

Use a codemod for anything purely structural (import renames, API renames, syntax rewrites that don't depend on context). Use an AI agent for anything that requires reading the surrounding code to decide what to do (idiom translation, judgment calls about which mock to keep). On most real migrations you do both, codemod first.

What's the right PR size for an AI-assisted migration?

One file, or one small folder, per PR. The whole point of the hybrid pattern is that reviewers can actually read the diff. A 400-file PR generated by an agent is technically smaller than the same migration done by hand, but no one reviews it carefully and bugs ship.

Which tools are worth paying for in 2026?

Cursor (the agent mode is the single highest-impact subscription on a migration), Claude Code (terminal-driven, better for large-context prompts), and Sourcegraph Cody Batch Changes if you're running migrations across many repos. Free tools (Aider, Continue) handle smaller jobs fine. Read more on how the AI hiring process has changed in 2026 for the bigger context on why these tools matter for evaluating engineers.

How do I know the migration is actually done?

Three signals: the old dependency is gone from package.json (or the equivalent), no file imports the old API, and the smoke test plus the unit suite both pass against the migrated branch. If any of those is fudged, the migration isn't done; you've shipped a long-running compat layer.