When you should rebuild software instead of fixing it
Rewrites are expensive and risky. Sometimes they're still the right call. Here's how to decide with evidence.
Trillune Engineering6 min read
Almost every team that inherits struggling software wants to rewrite it. The urge is understandable: the code is unfamiliar, the bugs are frustrating and a clean start feels faster. Usually it isn't. A rewrite has to rediscover every rule the old system learned the hard way.
Signals that favour fixing
- The data model is broadly right, even if the code around it is messy
- Problems cluster in a few modules rather than everywhere
- The framework and runtime are still supported
- The business can't afford a long feature freeze
Signals that favour rebuilding
- The platform or language version is unsupported and can't be upgraded incrementally
- The data model contradicts how the business now works
- Security issues are structural, not isolated
- Every change breaks something unrelated, and tests can't be added without restructuring
The middle path is usually best
Most of the time the answer is incremental replacement: put a stable interface in front of the old system, then move functionality piece by piece — highest-pain areas first. The business keeps running, value arrives early and risk stays contained.
Rebuild when the foundations are wrong. Fix when the foundations are sound but neglected. Replace incrementally in almost every case in between.