Rewrites fail more often than they succeed
A rewrite must reach parity with a system that absorbed years of business rules and edge cases, while the original keeps running and changing.
The rewrite abandoned at eighty per cent complete is a genuinely common outcome, and it costs more than the problem it was meant to solve.
Genuine reasons to rewrite
- The business requirements have fundamentally changed
- The original is so poor that understanding it costs more than rebuilding
- It depends on something no longer available or supported
- The data model cannot express what the business now does
Notice that “it uses an old framework” and “it is not how I would have written it” are not on that list.
Usually fixable instead
| Complaint | Actual fix |
|---|---|
| Slow | Query and index work |
| Fragile | Error handling and retries |
| Fails silently | Monitoring and alerting |
| Hard to change | Tests, then incremental refactoring |
| Outdated dependencies | Update them, one at a time |
The incremental alternative
New functionality in a modern structure alongside the old code, with old functionality moving across as it needs changing anyway.
Over a year the system modernises without ever being unavailable and without a single high-risk cutover.
If you do rewrite
- Characterise the existing behaviour with tests first
- Run both in parallel and compare output before switching
- Migrate one component at a time where possible
- Keep the old one running until the new one is proven
- Accept that it will find rules nobody documented