The rewrite trap

CTOs know the stats: 70% of big bang rewrites fail or are abandoned. The alternative isn't "don't rewrite", it's how you rewrite.

The incremental replacement pattern

1. Strangle the legacy: put a facade in front, route new features to the new system
2. Domain-by-domain: migrate one bounded context at a time (billing → booking → inventory)
3. Dual-write period: run both systems in parallel, compare outputs, fix drift
4. Cutover gate: automated parity tests + 2-week shadow traffic + rollback plan

Real timeline (£500k engagement)

| 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. We've seen 3-year delays turn a £500k rewrite into a £2M+ rescue.