Most software projects do not need a rewrite.
They need clearer ownership, fewer bad assumptions, better boundaries, better deployment discipline, and someone willing to untangle the ugly parts without pretending the past never happened.
I say this because rewrite conversations nearly always sound exciting at the start and expensive later. They create the feeling of progress long before they create any actual value. Everyone gets to imagine a cleaner system, a better stack, and a fresh start. Then reality shows up.
Why rewrites are so attractive
Rewrites are attractive because legacy systems are annoying.
The code is messy. The naming is inconsistent. There are old dependencies nobody likes. Nobody fully trusts the tests. A few important behaviors only exist because some production bug happened six years ago and somebody patched around it at 2 a.m.
So people look at the mess and think the problem is the codebase itself.
Usually it is not.
Usually the real problems are weaker than that and more awkward to admit: unclear product decisions, poor technical leadership, slow feedback loops, missing observability, weak release processes, or too much business logic living in the heads of a few people.
A rewrite does not magically fix any of those.
What usually happens with rewrites
The old system already contains thousands of small decisions the business depends on, whether anyone documented them or not.
That is why rewrites so often miss edge cases, break workflows, or take far longer than expected. The new system is clean partly because it has not earned the same scar tissue yet.
This is the part people underestimate. The mess in a mature system is often evidence of contact with reality.
If you replace that system all at once, you are not just replacing code. You are replacing years of discovered behavior, half-understood exceptions, workarounds for external systems, and business rules nobody wrote down properly.
That is a risky thing to do in one move.
What I would usually recommend instead
Most of the time, I would rather see a system improved in place or replaced in slices.
That can mean:
- carving out one bounded area at a time
- introducing cleaner APIs around ugly internals
- moving the worst parts behind a more stable boundary
- replacing one workflow or subsystem first instead of the whole platform
- paying down operational pain before touching everything else
That is less dramatic than a rewrite announcement, but it is normally the safer and more honest engineering choice.
Patterns like incremental replacement and the strangler fig approach keep showing up for a reason. They let you modernise without pretending the business can stop while engineering chases elegance.
When a rewrite can make sense
I am not saying never.
Sometimes the platform really is boxed in. Sometimes the runtime is dead, the deployment model is indefensible, the security posture is unacceptable, or the architecture is so tightly coupled that meaningful change is harder than replacement.
But even then, I would treat a rewrite as a last resort, not a default sign of ambition.
If a team wants a rewrite, I want to know:
- what business problem it solves that incremental change cannot
- what parts of the current system are genuinely beyond repair
- how the team will preserve critical behavior during the transition
- how they will stop the new system becoming the same mess two years later
If those answers are weak, the rewrite case is weak too.
My view
Most rewrite proposals are really frustration proposals.
The team is tired of the current system, and a rewrite feels cleaner than doing the slower work of understanding it, stabilising it, and improving it piece by piece.
I get the appeal. I really do.
But if I am advising on risk, cost, delivery, and long-term maintainability, I will usually back incremental change over a full rebuild.
Most software projects do not need a rewrite.
They need disciplined engineering and fewer excuses.
