Decision guide
Rewrite vs Incremental Refactor vs Strangler Fig
How should you deal with a legacy system that slows the team down?
Side by side
| Criterion | Full rewrite | Incremental refactoring | Strangler fig |
|---|---|---|---|
| Delivery risk | High: value only at the end | Low | Moderate, contained per step |
| Feature work during the change | Usually frozen or duplicated | Continues | Continues, new features in the new system |
| Risk of losing business rules | High | Low | Moderate; mitigate with shadow comparisons |
| Reversibility | Low until switch-over | High | High per routed slice |
| Fixes a dead platform | Yes | No | Yes, gradually |
When to choose each
Full rewrite
Build a replacement from scratch and switch over when it's complete.
Choose when
- The system is small and well understood
- The platform is truly dead (unsupported runtime with no upgrade path)
- Requirements have changed so much that little logic carries over
Avoid when
- The system encodes years of business rules nobody fully documents
- The business can't freeze features for months
Incremental refactoring
Improve the existing code in place, guided by tests, as you change it.
Choose when
- Problems are spread but the architecture is basically sound
- You can add tests around the hotspots
Avoid when
- The runtime or framework itself must be replaced
Strangler fig
Route parts of the functionality to a new system gradually until the old one can be retired.
Choose when
- Pain concentrates in identifiable modules
- You need to keep shipping features during the migration
- You want each step reversible
Avoid when
- You can't route or intercept traffic by feature
- The system is too small to justify running two
Verdict
Default to incremental refactoring where the architecture is sound and a strangler fig where pain concentrates or the platform must change. Reserve a full rewrite for small, well-understood systems — and decide with evidence (incidents and change cost by module), recorded in an ADR.