Rebuild or refactor? How to decide when software is failing

Every engineer who inherits a system wants to rebuild it, and the argument is always persuasive: the code is a mess, progress is slow, and a clean start with what we know now would take a few months.

It will not take a few months. More importantly, the system you want to replace is the only honest record of everything your customers turned out to need — including the parts nobody wrote down.

Why rebuilds overrun so reliably

Not because engineers are optimistic, though they are. Because the estimate is made against the visible feature set, and a system that has been in production for years is mostly invisible.

• The undocumented behaviour customers depend on. A rounding rule, a tolerated edge case, an export format someone's accountant relies on. You find these when they break, which is after launch.
• The bugs that became features. Every mature system has them, and nobody can list them in advance.
• The integrations. Each one was a negotiation with someone else's API, their rate limits and their failure modes. Rebuilding means re-learning all of it.
• Two systems at once. The old one still needs running, patching and supporting throughout, so your capacity is halved exactly when you need it most.
• Feature freeze. Competitors keep shipping while you reproduce what you already had. This is the cost that is never on the slide and is frequently the largest.

The question that actually decides it

Not "is the code bad". Bad code that works, is rarely touched and sits away from where you need to change things is not a business problem; it is an aesthetic one.

The real question is: does the current architecture prevent the specific thing you need to do next?

Only the last two rows describe architecture. The first four describe neglect, and neglect is much cheaper to fix than to replace. Why is my app slow covers the first row, which is the one most often mistaken for an architecture problem.

When a rebuild genuinely is right

Four conditions. One is rarely enough; two or more and the case becomes serious:

1. The platform is end-of-life. A framework or runtime with no security updates is a deadline somebody else set for you.
2. The data model cannot represent the business any more. Schema is the expensive thing to change. If the fundamental shape is wrong — single-tenant where you now need multi-tenant, no concept of an entity the business now runs on — that propagates into everything.
3. You are rebuilding a part, not the whole. Replacing one bounded service is a project. Replacing everything is a bet.
4. The product is genuinely changing. If what you sell is becoming a different thing, the old system is solving the old problem well. That is a legitimate reason and quite different from disliking the code.

Note what is absent: the language, the framework, and the quality of the code. Those are reasons engineers want a rebuild and rarely reasons a business should pay for one.

The middle path that usually wins

Replace it piece by piece while it keeps running. Route traffic through a new implementation for one area at a time, leaving the rest untouched — Martin Fowler's strangler fig pattern, and the approach that survives contact with a system nobody fully understands.

• Value arrives continuously rather than at the end of a long freeze.
• You can stop. Four months in, with three areas migrated and priorities changed, you have three improved areas rather than half a rewrite.
• Each piece is estimated against something you have now read, so estimates get better as you go instead of being one large guess made at the start.
• The business keeps shipping, which is usually what the rebuild was supposed to enable.

Monolith to microservices covers the architectural version of this, including when splitting is not the answer either.

Before you decide, measure

Both options are expensive, and the decision is usually made on feeling. Three things make it a decision instead:

1. Where does engineering time actually go? Roughly, over a month. If 60% goes to one subsystem, that subsystem is the project — not the whole application.
2. Which parts of the code change most? High-churn files are where requirements were least understood and where refactoring pays back fastest. The repository history tells you this directly.
3. What does the schema say about usage? Row counts reveal which features are genuinely used. Rebuilding features nobody uses is a surprisingly common expense — inheriting a codebase covers reading a system this way.

What we do

A short, paid assessment first, because the honest answer is often smaller than either side expects. Then scale and re-architecture work done incrementally behind the running product, so you are never holding two systems and a feature freeze at the same time.

We have told clients their system was fine and needed three specific fixes. That is a smaller engagement than a rebuild and it is the right answer often enough that we start by looking. If you are weighing this alongside changing suppliers, when your agency is not working out covers getting an independent view first.

Frequently asked questions

References

1. StranglerFigApplication — Martin Fowler