The rewrite trap
Big bang rewrites have a poor track record: the business keeps changing while the new system is built, and cutover becomes one unrecoverable bet. The alternative isn't "don't rewrite", it's how you rewrite.
The incremental replacement pattern
- Strangle the legacy: put a facade in front, route new features to the new system
- Domain-by-domain: migrate one bounded context at a time (billing → booking → inventory)
- Dual-write period: run both systems in parallel, compare outputs, fix drift
- Cutover gate: automated parity tests + 2-week shadow traffic + rollback plan
A typical timeline (mid-sized platform)
| Phase | Duration | Risk gate | |-------|----------|-----------| | Facade + first domain | 8 weeks | Parity tests pass | | Core domains (3–4) | 16 weeks | Zero data drift for 2 weeks | | Legacy decommission | 4 weeks | Rollback tested, business sign-off |
What we tell clients
"If you can't define the cutover gate, you're not ready to rewrite. Start with the facade."
The cost of waiting
Every quarter you delay, technical debt compounds. The legacy system becomes harder to strangle, not easier. Delay rarely makes the eventual rewrite cheaper; it usually turns a planned migration into an unplanned rescue.