Rewrite or refactor?

Every engineer who inherits a system wants to rewrite it. The existing code is unfamiliar, the decisions look arbitrary, and a clean start is obviously better.

Occasionally it is. Usually it is the most expensive way to end up roughly where you started.

What a rewrite actually costs

Not the development time, which is the part people estimate. The parts they do not:

• Every undocumented behaviour the old system has, which users depend on and nobody has written down.
• A feature freeze, or two systems maintained in parallel — both of which are worse than they sound.
• The bugs you already fixed once, arriving again in new code.
• Migration of live data, which is a project in itself.

That third one is the killer. A mature system's apparent ugliness is frequently the accumulated scar tissue of real problems. Rewriting discards the scar tissue and the lessons together.

When refactoring is the answer

When the system works, is understood by at least one person, and the pain is concentrated in specific areas.

Refactoring lets you improve continuously while shipping, keeps the behaviour that users rely on, and can be stopped at any point with value already delivered. It is almost always the lower-risk path.

When a rewrite is genuinely justified

• The platform is end-of-life and cannot be patched or hosted safely.
• The architecture structurally prevents something the business now requires — single-tenant where you need multi-tenant, for instance.
• Nobody who understands it remains, and the cost of relearning exceeds the cost of rebuilding.
• The cost of change has risen so far that small features take months.

Note that none of these is "the code is ugly". Ugly code that ships is more valuable than elegant code that does not exist yet.

The option most people miss

Strangle it. Put the new system in front of the old one, move one capability at a time, and route traffic progressively.

You get the benefits of new foundations without a big-bang cutover, you can stop at any point, and the old system keeps working throughout. It takes longer in total and is dramatically less risky — which, for anything with real users, is the better trade.

Decide with numbers, not feelings

Before committing, measure how much time actually goes into fighting the current system versus delivering new value. If it is a quarter of the team's time, that is a refactoring problem. If it is most of it, you have a real case.

And budget the full picture either way — our note on what software costs to run covers the part that is easy to leave out.

When is a rewrite actually justified?

When the platform is end of life and cannot be hosted safely, when the architecture structurally prevents something the business now needs, when nobody who understands the system remains, or when the cost of change has risen so far that small features take months. Notably, none of those is that the code is ugly.

What is the strangler pattern?

Putting the new system in front of the old one and moving capabilities across a piece at a time, routing traffic progressively until nothing is left on the old system. It takes longer in total than a clean rewrite and is far less risky, because the old system keeps working throughout and you can stop at any point with value already delivered.