Codebase-Scale Migrations with Opus 4.8: What Dynamic Workflows Can (and Can't) Do Yet

The flagship use case for Claude Opus 4.8's new dynamic workflows feature is codebase-scale migration — and for engineering teams, it's the capability that most changes what's possible. Anthropic's example is striking: Claude Code with Opus 4.8 can carry out migrations across hundreds of thousands of lines of code, from kickoff to merge, using your existing test suite as the bar for success. A framework upgrade or dependency overhaul that would consume a week of senior engineer time can, in the right conditions, happen in a single session.

But "in the right conditions" is doing a lot of work in that sentence. Dynamic workflows is a research preview with real limitations, and understanding what it can and can't do yet is the difference between a successful migration and a costly mess. This is the practical, honest guide for engineering teams considering it.

What Dynamic Workflows Does Well

Dynamic workflows shines on migrations that are mechanically complex but rule-consistent — the kind of work that's tedious and error-prone for humans precisely because it's repetitive at scale. Updating namespaces across 200 files, migrating a framework version repo-wide, changing a deprecated API pattern everywhere it appears, overhauling a dependency: these tasks follow consistent rules but require touching huge numbers of files without introducing inconsistencies. That's exactly what parallel subagents handle well.

The architecture is what makes this work. Claude plans the migration, dispatches subagents that handle different parts of the codebase simultaneously, deploys adversarial agents to catch inconsistencies and refute incorrect changes, and iterates until the changes converge — then verifies against your existing test suite before declaring success. The Laravel migration example Anthropic cites — updating namespaces across hundreds of files, running tests, fixing failures — compresses from a week of manual work into a single session. For the technical detail on how the subagent orchestration works, see our dynamic workflows deep dive.

The Limits You Need to Know

Now the honest part. First, it's a research preview. That means rough edges, unexpected behavior, and the explicit recommendation — from both Anthropic and independent reviewers — not to point it at production-critical migrations without review. The verification step and adversarial agents reduce errors but don't eliminate them. Treat the output as a very good first draft that needs human review, not as a finished migration you can merge blindly.

Second, it depends entirely on your test suite. Dynamic workflows uses your existing tests as the bar for success — which means if your test coverage is thin, the verification is weak. A migration "verified" against incomplete tests can pass while introducing bugs the tests don't catch. Before running a large migration, ensure your test coverage is comprehensive for the areas being changed. Garbage tests in, garbage confidence out.

Third, it consumes heavy tokens. Running hundreds of parallel subagents over hours requires proportionally more compute. Anthropic raised Claude Code rate limits to accommodate this, but a large migration will consume significant resources. Factor token cost into your decision — for some migrations, the cost may rival the engineer time it saves, though for most large mechanical migrations the trade still favors the AI approach. And finally, availability is limited to Max, Team, and Enterprise plans.

How to Run a Migration Safely

If you want to try a codebase-scale migration with dynamic workflows, here's the safe approach. Start with a non-critical migration to learn the behavior — a side project, a low-stakes internal tool, or a well-isolated module. Ensure comprehensive test coverage for the areas being changed before you start, since the tests are what verify success. Tell Claude Code explicitly to create a workflow for the migration, and give it a precise, unambiguous description of the goal — ambiguity gets multiplied across hundreds of subagents.

When the migration completes, review the output before merging — read the changes, run the full test suite yourself, and spot-check critical paths. Treat it as you would a large pull request from a capable but new team member: trust but verify. As you build confidence in the tool's behavior on your codebase, you can extend it to larger and more important migrations. This measured approach captures the productivity gain while managing the risk that comes with any AI-generated code, a risk we've documented in our AI code security analysis.

Clear task descriptions matter enormously for large migrations. The free Prompt Optimizer helps you write precise migration instructions, and TresPrompt brings prompt optimization into your workflow.

A Realistic Picture of Time and Cost Savings

The "a week of work in one session" framing is compelling, but it's worth grounding in realistic expectations. The time savings are genuine for the right kind of migration, but they come with overhead you should account for. You'll spend time upfront ensuring test coverage is adequate, writing a clear migration description, and setting up the run. You'll spend time afterward reviewing the output, running the full test suite, and spot-checking critical paths. And you'll consume significant tokens during the run itself. The net savings are still substantial for large mechanical migrations — but it's "a week of work compressed into a day of supervised AI execution plus review," not "a week of work done while you sleep with zero involvement."

For cost, the calculation depends on the migration's size and your plan. The token consumption of running hundreds of parallel subagents over hours is real, and for a very large migration it can be meaningful. But weigh it against the alternative: a week of senior engineer time is expensive, and the engineer's time is better spent on design and review than on mechanically updating namespaces across 200 files. For most large mechanical migrations, the AI approach wins on total cost even accounting for tokens — but run the numbers for your specific case rather than assuming it's always cheaper.

How This Changes Team Workflows

Beyond individual migrations, dynamic workflows hints at a broader shift in how engineering teams will operate. Tasks that teams have perpetually deferred — the framework upgrade everyone agrees is needed but no one wants to do, the dependency overhaul that keeps getting pushed to "next quarter," the repo-wide refactor that would improve everything but costs too much engineer time — become feasible when the mechanical work can be delegated to supervised AI. This could unlock a wave of long-overdue technical debt cleanup, because the cost-benefit calculation that kept these tasks deferred has changed.

The role of the engineer shifts accordingly. Instead of spending days on mechanical execution, engineers spend time on the higher-value work of deciding what should change, defining the migration clearly, and rigorously reviewing the results. This is a better use of expensive engineering talent — judgment and design rather than repetitive editing. Teams that adopt this pattern thoughtfully, with appropriate review and good test coverage, can tackle a larger scope of work with the same headcount. As with all AI-generated code, the discipline of review remains essential, but the leverage is real for the migrations that fit the tool's strengths.

Frequently Asked Questions

Can Opus 4.8 really migrate an entire codebase?

Yes, for mechanical, rule-consistent migrations. Dynamic workflows can handle migrations across hundreds of thousands of lines — framework upgrades, namespace changes, dependency overhauls — by dispatching parallel subagents and verifying against your test suite. It's best at repetitive-at-scale work, less suited to migrations requiring deep architectural judgment.

Is it safe to use dynamic workflows for production code?

With review. It's a research preview, and both Anthropic and independent reviewers recommend reviewing outputs before merging production-critical changes. Start with non-critical migrations, ensure comprehensive test coverage, and treat the output as a first draft requiring human review — not a finished migration to merge blindly.

What kinds of migrations work best?

Mechanical, rule-based migrations: framework version upgrades, repo-wide pattern changes, dependency overhauls, namespace updates. These follow consistent rules but require touching many files — exactly what parallel subagents handle well. Migrations requiring deep architectural decisions or business-logic judgment are riskier and need more oversight.

How important is test coverage for migrations?

Critical. Dynamic workflows uses your existing test suite to verify the migration succeeded. If your test coverage is thin, the verification is weak — a migration can "pass" while introducing bugs the tests don't catch. Ensure comprehensive coverage for the areas being changed before running a large migration.

Which plans support codebase migrations with dynamic workflows?

Dynamic workflows is available for Claude Code on Max, Team, and Enterprise plans (admin-enabled for Enterprise at launch). It's not available on Pro plans. The feature is in research preview, so expect ongoing changes as Anthropic refines it.

Disclosure: Some links in this article are affiliate links. We only recommend tools we've personally tested and use regularly. See our full disclosure policy.