Rewrite or keep: how to decide

Every system a few years old provokes the same reaction in whoever arrives: this needs to be rewritten.

Sometimes it does. But a rewrite carries a well-known trap: the old system, however bad it looks, holds years of business rules nobody documented. Each odd condition buried in the code is usually the scar of a real problem that happened once and never again, precisely because someone put that condition there.

A rewrite starts clean and rediscovers those rules one at a time — in production, with the client complaining. That is what turns a six-month estimate into two years.

Before deciding, a few questions separate an annoyance from a problem:

• What exactly hurts? Is it expensive to change, does it break often, is it slow, or does it merely use a technology nobody likes any more?
• How often does this system change? Software that is barely touched has little to gain from a rewrite, however ugly it is inside.
• Are there automated tests? Without them, both keeping and rewriting are bets — except the rewrite bets everything at once.
• Are the business rules documented anywhere other than the code?
• Who maintains it today? If the knowledge sits with one person, that is the urgent risk, and new technology does not solve it.

There is a middle path that tends to be ignored because it is unexciting: isolate. Instead of rewriting everything, fence the old system in, put a layer in front of it and replace one piece at a time, with the system running throughout. It is slower on paper and faster in practice, because each step delivers value and can be reverted on its own.

What usually does justify a rewrite:

• The technology no longer receives security updates and there is no migration path.
• The data model blocks a change the business needs now, not in three years.
• The cost of maintaining it, measured in real hours, already exceeds the cost of replacing it.
• There is no longer anyone, in the market or in the company, able to maintain it.

What usually does not: the language being out of fashion, the code being ugly, or the current team not having written it. None of those three appear on the client's invoice.

It is worth saying that rewriting is not wrong — it is expensive. The right question is not whether the system deserves a rewrite, but whether that is the best use of the engineering budget right now, compared with everything else that is also waiting.

When the honest answer is to keep it, keep it well: tests, documentation and gradual reorganisation are worth more than a rewrite postponed indefinitely and argued about in every meeting.