Every engineer who inherits an old system has the same thought in the first week: "it would be faster to rewrite everything from scratch". Sometimes that is true. Most of the time, it is not.
What actually happens
The old system holds ten years of business rules, half of which are documented nowhere. They got there through real incidents, a request from a large client, or a legislative change everyone has since forgotten.
When you rewrite from scratch, you implicitly commit to rediscovering all of those rules. And the deadline you promised does not include that effort, because you cannot estimate something you do not know exists.
An old system is not bad code. It is code that survived reality.
The repeating pattern
- The team estimates the rewrite at nine months.
- After six months, the new system covers 60% of the features but cannot launch, because the remaining 40% contains exactly the cases that tolerate no interruption.
- Meanwhile the old system must still be maintained in parallel, so the cost doubles.
- At month 14, someone proposes "a partial launch" — precisely what should have been done from the start.
The alternative: incremental modernisation
It is not spectacular and it does not look good in a slide deck. But it works.
- Step one: the safety net. Characterisation tests over current behaviour, however ugly the code. They do not describe what the system *should* do, but what it does now.
- Step two: an automated pipeline. If a release takes a day and needs three people, you will not deliver incrementally, whatever your intentions.
- Step three: isolate a component. Pick an area with a clear boundary and move it behind an interface. The old system keeps working.
- Step four: replace it. Write the new implementation, run both in parallel and compare results on real traffic before switching over.
When a full rewrite really is the answer
There are clear cases: the platform the system runs on no longer receives security updates, the language has no suppliers left on the market, or the business domain changed so much that the old rules are irrelevant anyway.
In those situations, the rewrite is a risk decision rather than an aesthetic one. The difference is that you can justify it with arguments, not with the irritation of code you do not yet understand.