There is always a moment when someone says it. Usually a new CTO, sometimes a supplier who has just arrived, and occasionally it is us: we need to rebuild this. It sounds decisive, it is easy to explain to a board, and in most cases it is the most expensive option on the table.

What is inside that old system

A system that has been running for five or ten years contains two things. The first is code, and it usually is not pretty. The second is the exceptions: that one client with their own pricing, the order type that gets booked differently, the correction that runs every Monday morning because an integration once sent something through twice.

None of that is written down anywhere. It lives in the code, and often only there. In a rebuild you discover it all again, one by one, and usually at the moment the new system is already live and someone calls to say their invoice is wrong.

We have watched that happen a few times. Not because the builders could not build, but because they could not know what they did not know.

What we do instead

We replace it in pieces while the old one keeps running. It goes like this:

  • First we measure what actually gets used. Every system contains features nobody has clicked in two years, and those do not need rebuilding.
  • We cut out one piece that stands on its own. A portal, an integration, the invoicing.
  • We build that piece new, next to the old one, and let the old system call it.
  • If it works, the next piece follows. If it does not, we roll back one piece instead of a year of work.

After a while you notice there is not much left of the old system. That moment arrives later than it would with a rebuild, but you were never six months without a working system along the way.

When rebuilding is right

There are exceptions, and there are fewer of them than people think:

  • The technology no longer gets security updates and there is no path to a version that does.
  • The system does something fundamentally different from what the business needs now. That is not a new version, that is a different product.
  • Nobody knows the language or the framework any more, and nobody can be hired who does.

Note that "the code is a mess" is not on that list. That is a reason to clean up, not to start over.

Where the conversation usually stalls

With a rebuild you know the price up front and you get one date. That is comfortable for a budget. With piece-by-piece replacement you get a series of smaller amounts, and part of it works better within a few weeks.

The first shape feels safer. It is not: of all projects that overrun, rebuilds are the champions. You traded the certainty of a date for the certainty that the exceptions are still coming.

If you are unsure what state your software is in, a code scan is usually the cheapest answer: two weeks of reading, and after that you know where you stand. Even if you carry on with someone else afterwards.