How to Migrate a Legacy Codebase with Claude Fable 5: The Short Version
Do not point Fable 5 at a legacy system and say migrate this. Even the most capable model will happily rewrite code whose behavior it never fully understood, and you will not find out until production does. The method that works is boring and safe: map the old system, capture what it does today, move it one slice at a time, and prove the new version behaves identically before you switch anyone over.
I have spent fifteen years shipping inside teams at Apple, PlayStation and Schwab, and every painful migration I have seen failed the same way: someone trusted the rewrite before they proved it. Fable 5 makes the rewriting almost free, which means the proving is now the whole job. This is grounded in what Fable actually does well (https://www.anthropic.com/news/claude-fable-5-mythos-5), applied through an agency lens.
Why Fable 5 Changes Legacy Migration
Legacy migration used to be gated by human bandwidth: someone had to hold the whole old system in their head while rebuilding it. Fable 5 removes that ceiling. It holds an entire codebase in context, stays sharp across millions of tokens with file-based memory, and works autonomously for long stretches, which is how it ran a two-month migration in a day in Anthropic's testing. The rebuild is no longer the bottleneck.
The Migration Ladder
Four phases, each a checkpoint you can stop and roll back to. I call it the Migration Ladder. Climb it in order and a migration that used to be a leap of faith becomes a series of small, verifiable steps.
- Map before you move. Have Fable read the entire legacy codebase and produce a written map: what each module does, how data flows, where the dependencies and dead ends are. You are not changing anything yet, you are giving the model, and yourself, an accurate picture of what actually exists.
- Pin the current behavior. Before you touch the code, capture what it does today as tests, golden outputs, or recorded examples. This is your parity contract. Without it you have no objective way to prove the new system matches the old, and matching is the entire point of a migration.
- Migrate in slices. Move one module or one boundary at a time, not the whole system in a single pass. After each slice, run it against the behavior you pinned in phase two. A slice that passes is a rung you can stand on, a slice that fails is contained instead of hidden inside a giant rewrite.
- Prove parity, then cut over. Only switch traffic to the new system once every slice matches the pinned behavior and the two systems produce the same results on real inputs. Keep the old system running in parallel until that proof holds, so cutover is a decision, not a gamble.
The Client-Work Caveats Nobody Mentions
A migration on your own project is one thing. A migration on a client's revenue-critical system is another, and the model's speed can tempt you to skip the guardrails that protect the relationship. Three that are not optional:
- Check data retention before you upload their code. Fable's current policy retains data for 30 days, so read it and clear it with your client before any proprietary codebase goes through the model. This is a contract and trust issue, not just a technical one.
- Never cut over without a rollback. Keep the legacy system running until parity is proven on real traffic. If the new system misbehaves, switching back must be a one-step decision, not a weekend of firefighting.
- Price on the outcome, not Fable's hours. If Fable turns a two-month migration into a two-day one, billing hourly quietly hands all of that value to the client. Price the migration on what a safe, proven cutover is worth to their business, and let the speed be your margin.
How to Know the Migration Actually Worked
The finish line is not when the new code exists, it is when the new code behaves identically to the old on every input that matters. If your phase-two behavior contract passes across every slice and the parallel run agrees on real traffic, you are done. If you cannot point to that evidence, you are not finished, no matter how clean the new codebase looks.
Migrate this way and Fable 5 turns your riskiest kind of project into your most repeatable one: map, pin, slice, prove. That is a productized offer an agency can sell with a straight face, because the client is buying a proven cutover, not a hopeful one. If you run a migration on the ladder, tell me how it went in the CCC community.
Frequently asked questions
Can Claude Fable 5 really migrate a whole legacy codebase?
Yes. Fable 5 holds an entire codebase in context and stays sharp across millions of tokens with file-based memory, which is how it ran a two-month migration in a day in Anthropic's testing. The limiting factor is no longer the rewrite, it is proving the rewritten system behaves identically to the original, which is work you still own.
What is the safest way to migrate code with Fable 5?
Use a phased approach: map the legacy system first, capture its current behavior as a test or parity contract, migrate one slice at a time, and prove parity before cutting over. Each phase is a checkpoint you can roll back to, which turns a risky single rewrite into a series of verifiable steps.
Should I let Fable 5 rewrite the entire system in one pass?
No. A single giant rewrite hides failures until cutover. Move one module or boundary at a time and validate each slice against the behavior you captured up front. A slice that fails is contained, whereas a failure buried in a full rewrite can take longer to find than the migration saved.
Is it safe to run a client's codebase through Fable 5?
Only after you check the data-retention policy and clear it with the client. Fable's current policy retains data for 30 days, so any proprietary code going through the model is a contract and trust matter, not just a technical one. Confirm it in writing before you upload anything sensitive.
How should an agency price a Fable 5 migration?
Price on the outcome, not the hours. If Fable compresses a two-month migration into two days, hourly billing hands all that value to the client. Charge for a safe, proven cutover based on what it is worth to the client's business, and let the model's speed be your margin.
How do I know a Fable 5 migration is actually finished?
When the new system matches the old on every input that matters. If the behavior contract you captured before migrating passes across every slice and a parallel run agrees on real traffic, it is done. If you cannot point to that evidence, it is not finished, however polished the new code looks.
Last reviewed by Duncan Rogoff on July 4, 2026
