When a rewrite makes sense
A rewrite can be justified when the current system truly blocks operation or future change, and targeted improvement would cost more than rebuilding the foundation.
Comparison
A clean restart sounds attractive. Operations often need something else.
For running applications, risk management and targeted improvement usually matter more than a dramatic restart.
A rewrite is a common first reaction when the current application feels painful. But rewrites carry delay risk, knowledge loss, and hidden dependency surprises.
Incremental improvement is not always elegant, but it is often safer and cheaper when the system still supports important operations.
When incremental improvement is the smarter move
Incremental improvement is usually better when the app still serves the business but needs stabilisation, simplification, and focused changes in the most problematic areas.
How to decide
The decision should not be based only on price or technology taste. What matters is operational fit, change speed, and long-term cost.
- operational criticality
- depth of technical debt
- risk of losing domain behaviour
- time and budget available for parallel rebuilding
Practical conclusion
For most running applications, the sensible first step is discovery and incremental improvement. Rewrites should be a consequence of evidence, not frustration with inherited code.
Who this is for
- operational criticality
- depth of technical debt
- risk of losing domain behaviour
- time and budget available for parallel rebuilding
Who it is not for
- abstract technology debates with no business context
FAQ
How do we know incremental work is no longer enough?
Usually when architecture is systematically blocking change, security, or operation, and partial fixes keep getting more expensive without improving the situation.
Can the two approaches be combined?
Yes. Many projects replace selected subsystems while stabilising and keeping the rest of the product live.
Why are rewrites so often underestimated?
Because hidden dependencies, edge cases, and accumulated domain logic are almost always larger than they appear at first glance.
Do you always start with an audit?
For inherited or legacy application situations, yes. It is the safest basis for deciding between refactor, stabilisation, and rewrite work.
Next step
Have a similar situation?
Share the context and I will tell you whether the project is a fit.