When to rewrite, and when not to

Every sufficiently old system reaches a point where someone proposes replacing it. The proposal is usually sincere and usually wrong, because the discomfort driving it is real but the diagnosis is not.

What the old code actually contains

Legacy systems are ugly in part because they are correct. Years of edge cases, regulatory quirks, customer-specific behaviour and bug fixes are encoded in code nobody documented, often by people who have left.

A rewrite starts from the specification somebody can describe today, which is the clean subset. The messy remainder is rediscovered one production incident at a time, over about eighteen months.

Ask which parts actually change

Pull the commit history and find which files have been touched in the last year. In most systems, change concentrates in a small fraction of the codebase. The rest is stable, which is another way of saying it is working.

Pain is felt in the parts that change. There is no return on rewriting the parts that do not, however unpleasant they look.

Replace incrementally instead

Put a seam around one painful area, move it behind an interface, and reimplement it there. Run both paths against real traffic until the new one is uninteresting. Then take the next area.

This is slower in a plan and faster in reality, because value arrives continuously and you can stop whenever changes stop hurting — which often happens well before the whole system has been replaced.

When a rewrite is right

There are real cases. The platform is end-of-life and unsupported. The language has no hiring pool. A compliance requirement cannot be met within the existing design. The system is small enough that a rewrite is a few weeks.

Notice what those have in common: an external constraint, not an aesthetic judgement. "The code is bad" is a feeling about a codebase. "Our runtime stops receiving security patches in November" is a date.

Be honest about the estimate

If a rewrite is genuinely the answer, plan for considerably longer than the original build. That one is unintuitive and reliably true: the original was built against evolving requirements, while the rewrite has to match a moving target that is still shipping features.