Rewrite it, or keep patching it?

The rewrite is always more attractive than it deserves to be, and for a structural reason: you are comparing a system whose every flaw you have had to live with against one that exists only as an idea. The old system has years of accumulated ugliness on display. The new one has none, because it has nothing.

That comparison is unfair, and it is the single most expensive unfairness in this industry. It is also not an argument for never rewriting. Some systems genuinely should be replaced. The question is which signals tell you apart.

Why rewrites go wrong

Three failure modes, and they compound.

The old system knows things nobody wrote down. Years of small fixes encode requirements that were never documented: the edge case in the tax rule, the customer whose data is shaped differently, the report someone in finance depends on. A rewrite starts from the description of the system, not from the system, and the description is always shorter than the truth.

The business does not stop. The old system has to keep running and keep changing while the new one is built, so for the length of the project you are paying for two of everything — and every change made to the old one is a change the new one now also needs.

The second system gets everything the first one lacked. Freed from the constraints that produced the original, teams put in the flexibility, the abstraction, and the configurability that the first version was criticised for lacking. The result is usually harder to change than what it replaced.

Four signals it is genuinely time

1. The cost of a change is rising, not flat. Not “changes are expensive” — expensive and stable is a system you can budget for. Rising is the signal: the same size of change costing more each year means the structure is working against you, and that does not improve on its own.
2. A load-bearing part is understood by nobody currently employed. Not undocumented — genuinely unknown. If a change to that part is approached by trial and error, you do not have a system, you have a fossil that happens to respond to inputs.
3. It blocks something the business has already decided to do. A second country, a second brand, an acquisition, a regulator’s deadline. The decision is made and the system cannot get there. That is a rewrite with a reason attached to it, which is the only kind that survives contact with a budget review.
4. The platform underneath is out of support. A runtime with no security patches, a database version the vendor no longer fixes, a framework nobody maintains. This one has a clock on it and the clock is not yours.

Note what is not on that list: the code is ugly, the previous team was careless, or the technology is unfashionable. Those are all true of most working systems, most of the time.

Four signals it is not

• The current team did not build it. Unfamiliarity reads exactly like bad design for the first few months. Wait longer before deciding.
• One part is painful. Replace that part. A system is not a single object, whatever the invoice implies.
• It is slow. Measure first. Performance problems are usually specific, local, and much cheaper to fix than to rebuild around.
• A rewrite is more interesting. Honest, common, and not a business case.

The option in between

Most systems do not need replacing; they need parts of them replaced, in an order, while they keep running.

Put the new system in front of the old one, route one capability at a time through the new path, and delete the old path once nothing calls it. Each step is small, reversible, and useful on its own — and if the money runs out halfway, you are left with a working system rather than two half-finished ones. It is slower in total than a clean rewrite that goes perfectly, and faster than every rewrite that does not.

Whichever you choose, the useful discipline is the same: write down what the old system does that nobody has documented, before you start. That list is the actual specification. It is also the thing every failed rewrite discovered too late.