The Rewrite Trap and the Staged Evolution Plan
Never go away for a year to rebuild — uplift well-contained pieces of the system instead
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
Fournier's counter to the big-bang rewrite: the pain engineers feel with a legacy system almost never justifies going dark to build a replacement. She replaces the rewrite with a staged evolution plan — carve out well-contained components, uplift them one at a time, keep shipping. Before any of it, run a hard filter: if you could leave the system untouched for a long time without harming the business, the rewrite isn't worth doing at all.
Origin
Camille Fournier, drawn from personally overseeing a number of re-architectures and major system evolutions, and from a blog post of hers on why rewrites fail. She is explicit that she does believe systems sometimes must be evolved — the objection is to the go-away-and-rebuild-it shape.
Core principles
- 01Engineers convince themselves the only cure for a hard-to-support system is to build the new thing off to the side. That story is almost always wrong.
- 02Migration time from old system to new is massively underestimated — especially where external users, UIs or APIs are involved.
- 03You still have to support the old system the whole time you're building the new one.
- 04Legacy systems hide enormous undocumented logic: business rules, data formats, edge cases. You know less about what the old system does than you think.
- 05'Annoying to the engineers' is not a business case. 'The old system literally cannot do the new thing we need' is.
- 06'We can't add features for 6 months / a year / 2 years' should rarely be an acceptable answer.
How to run it
- 1
Apply the do-nothing test
Ask: if I could go away and not touch this system at all for a long period, would it really harm the business? If the users are fine and the system is merely unpleasant to work in, the answer is that a rewrite is not worthwhile. Stop here.
Pro tip This test cleanly separates engineer misery from business need — the two get conflated in almost every rewrite pitch.
Watch out Watch for the cognitive dissonance: a system that doesn't need feature development is precisely the system nobody should spend money rewriting.
- 2
Prove the new work is genuinely impossible on the old system
The legitimate trigger is that you need to do new things and the old system literally cannot support them. Then you're not rewriting for aesthetics — you're buying a path to a system you can keep evolving.
Watch out Language modernization and 'nobody wants to work on this old crappy technology' do not clear this bar on their own.
- 3
Decompose into well-contained uplifts
Instead of touching everything, identify pieces with clean boundaries — e.g. a recommendation system sitting behind a well-contained API — and uplift those individually while leaving the rest (the web framework, etc.) alone.
Pro tip Contained API surface is the selection criterion: pick the components whose blast radius you can actually reason about.
- 4
Budget migration honestly, and dual-run
Explicitly plan for migrating users, customers, data and integrations, and for supporting the old system in parallel throughout. Assume you have missed business rules and data-format quirks buried in the legacy code.
Pro tip Force an inventory of undocumented behaviours before committing to a date — the ones you find are a proxy for how many you haven't.
Watch out Every external consumer — web UI, API client — multiplies the migration cost you are already underestimating.
- 5
Keep shipping while you evolve
Structure the plan so feature development continues throughout. A staged uplift keeps the product moving; a rewrite parks it.
In the wild
Fournier's illustration of the right shape: rather than rewriting the whole application, you acknowledge the uplift is needed, then note that the recommendation system is what really needs it and that it's a well-contained API. You fix that piece without having to change the whole web framework.
→ The painful component gets modernized, the rest of the system stays untouched, and the team never goes dark.
Lenny Rachitsky observes the same trap in product: the urge to rethink an onboarding flow from scratch. Almost always the experiment comes back negative, the team spends time clawing back to where it started, and they discover features they'd forgotten the old flow had.
→ Confirms the pattern is not engineering-specific — rebuilding from scratch systematically underestimates what the old thing did.
Common mistakes
Rewriting a system that is merely annoying
If the system works, users are happy, and it just irritates the engineers, investing heavily in a new version is spending real money to fix a morale problem the wrong way.
Underestimating migration
Fournier calls this the huge huge problem: teams assume they know what's going on so moving over won't be a big deal — and they are notoriously, massively wrong, particularly where external consumers depend on the system.
Assuming you know what the old system does
Legacy systems carry undocumented, weird logic — unexamined business rules, data-formatting behaviour. Replicating the important parts is far harder than expected, and the gaps surface as new bugs and missing features.
Is it for you?
Best for
PMs and engineering leaders facing an internal push to rewrite or re-platform a legacy system, who need a defensible way to convert 'let's rebuild it' into a staged plan.
Not ideal for
Genuinely rare cases where the existing system cannot support the business at all and a hard cutover is the only option — and greenfield work with no legacy to preserve.
From the transcript
“Engineers notoriously notoriously notoriously massively underestimate the migration time for old system to new system”
“by the way you still have to support the old system while you're working on the new system”
“if I could go away and not touch this and not do anything to it for a long period of time without it really harming…”
“my advice would be when you're when you're struggling Mak an evolution plan take pieces potentially of the old system uplift it”
From the episode
The things engineers are desperate for PMs to understand
Camille Fournier (author of “The Manager’s Path,” ex-CTO at