“Let's rewrite it from scratch.”
It's one of the most attractive sentences in software.
The old system is difficult.
The code is messy.
The technology is outdated.
A clean new system sounds like a fresh start.
Sometimes it is.
But a complete rewrite can also recreate the same problems with newer technology.
A Rewrite Removes Code, Not Knowledge
Existing software contains more than source code.
It contains years of business decisions.
Rules.
Exceptions.
Workarounds.
Integrations.
Unexpected dependencies.
Things that users rely on but nobody documented.
When you start from scratch, all of that knowledge has to be rediscovered.
That's harder than it sounds.
The New System Can Become the Old System
Imagine rebuilding an application with a modern technology stack.
The new version looks cleaner.
The architecture is better.
The interface is nicer.
But the team copies every existing process and every old assumption.
Three years later, the new system has its own workarounds, technical debt and complexity.
The technology changed.
The underlying problem didn't.
Rewrites Also Take Time
During a rewrite, the business still needs the existing system.
That means running two worlds at once.
The old system continues operating.
The new system is being built.
Data may need to move between them.
Users may need to work with both.
Requirements may change during development.
The longer the rewrite takes, the more opportunity there is for the two systems to diverge.
Sometimes a Rewrite Is Absolutely the Right Choice
This isn't an argument against rewrites.
There are situations where a rewrite makes sense.
For example:
The existing architecture prevents important business changes.
The system is effectively unmaintainable.
The technology creates serious operational or security risk.
The business logic is valuable but the implementation is beyond practical repair.
The cost of incremental improvement is higher than replacing the system.
The important part is proving that the rewrite solves a real problem.
Consider a Gradual Replacement
You don't always have to replace everything at once.
You might identify one important part of the system and replace it first.
Then another.
This can reduce the amount of risk involved.
It also gives the team a chance to learn from the existing system and from real users.
A gradual approach isn't always possible.
But it is worth considering before committing to a complete rewrite.
Ask the Hard Question
Before approving a rewrite, ask:
“What exactly will be better when we're finished?”
Not:
“Will the code be cleaner?”
That's useful, but not enough.
What changes for the business?
Will releases be faster?
Will maintenance become cheaper?
Will a critical workflow improve?
Will the system support something the current one cannot?
Will risk decrease?
If the answer isn't clear, the rewrite may simply be an expensive way of getting new code.