I do recommend rewrites sometimes. Just not nearly as often as people hope I will.
Most rewrite discussions start from pain, not clarity. The system is annoying, the code is messy, delivery is slow, and everybody wants the emotional relief of starting again. I understand that impulse. But in consulting work, “I am tired of this codebase” is not the same thing as “a rewrite is the best decision.”
When I absolutely do not recommend a rewrite
I do not recommend a rewrite when the real problems are things a rewrite will not solve.
That usually means:
- poor product decisions
- weak ownership
- slow review and release processes
- missing tests and observability
- confused business rules
- a team that has not really understood the current system yet
If those are the issues, then rebuilding the software usually just recreates the same mess in a newer stack.
I also do not recommend a rewrite when the business cannot tolerate a long, risky period of duplicated effort. If the team needs continuous delivery, predictable change, and stable operations, then a big-bang rebuild is often the wrong shape of work.
And I definitely do not recommend a rewrite just because the code looks old. Old is not the same thing as broken.
When I do recommend a rewrite
I recommend a rewrite when the current platform is genuinely boxed in and the team can explain why incremental replacement is not enough.
That usually involves some combination of:
- unsupported or unpatchable runtime dependencies
- architecture that makes safe change nearly impossible
- deployment or security posture that is no longer acceptable
- infrastructure constraints that block the business from moving
- cost of incremental change that is consistently worse than replacement
Even then, I still want a serious plan.
If a team wants me to back a rewrite, I want to know:
- what problem this solves in business terms
- which parts must be rebuilt and which do not
- how critical behaviour will be preserved
- how migration risk will be controlled
- how the team avoids building a second messy system with better branding
If those answers are vague, I assume the rewrite case is weak.
What I usually push for instead
Most of the time, the right answer is controlled replacement rather than a full reset.
That might mean:
- replacing one bounded subsystem first
- wrapping unstable internals behind cleaner APIs
- separating the highest-risk workflows before anything else
- improving deployment, testing, and observability before touching architecture
- removing the worst operational pain before chasing elegance
That work is less exciting than announcing a rewrite. It is also usually more responsible.
My view
I recommend rewrites when the current system is genuinely beyond safe or sensible improvement.
I absolutely do not recommend them when the team is really trying to escape frustration, poor discipline, or years of unclear decisions.
That distinction matters.
Because a rewrite can be the right call.
But most of the time, disciplined change beats a dramatic restart.