Rebuild or improve: deciding about an old system

"The system is old, we need a new one." That sentence starts more projects than it justifies. What is interesting is that it is almost never a technical assessment — it is usually a conclusion arrived at after a few years of inconvenience. Before acting on it, four checks are worth running, and none of them needs a supplier.

In short

• Age is not the indicator. The indicator is whether a change can be made without breaking something else.
• Rebuilds are usually chosen for organisational rather than technical reasons, and that is worth saying out loud.
• A new system develops the same problems if what caused them is unchanged: unwritten rules and unclear ownership.
• A partial route — separating one area and replacing that first — almost always exists and is almost never offered.
• The biggest risk in a rebuild is not the code but the data, and the knowledge living in people's heads.

Four checks you can run yourself

First: how long a small change takes. Not a large feature — a new field on a form. If the answer is measured in days, the system is sound. If nobody can answer at all, the problem is not the system's age but that nobody maintains it any more.

Second: what happens when something is changed. If every change breaks something unrelated, the system is too tightly coupled internally. That is a genuine technical argument, but it does not argue for a rebuild — it argues for separation.

Third: whether anyone can explain where the data is kept and how to get it out. If that is unclear, a rebuild is the riskiest available option, because its very first step would be the thing nobody knows how to do.

Fourth: how many business rules are written down. Almost every old system contains rules nobody documented, noticed only when they stop working. The less is written, the more expensive a rebuild — and the more valuable it is to write them down first, whichever route is chosen.

Why rebuilding gets chosen so often

This is no longer a technical point but an honest organisational one. A rebuild is convenient: it avoids deciding why the system is as it is and who is accountable for that. It brings a fresh budget, a new team and a clear narrative about progress. Improvement delivers a less visible result and requires admitting that something earlier was done badly.

This does not mean rebuilding is always wrong. It means that before committing, it is worth answering whether the decision solves a technical problem or avoids an organisational one. If the latter, the new system will look much the same in a few years, in newer technology.

The third route nobody offers

It is almost always possible to separate one area, replace that first, and leave the rest running. Invoicing, customer accounts, reporting — usually some part is separable enough to move without the rest. It is slower than replacing everything and harder to sell as a project, but the risk stays contained: if it fails, one area fails rather than the business.

The added benefit is that the first stage reveals the real pace. After it, the decision about the remaining system can be made with data instead of a forecast.

What a rebuild actually costs

• Data migration. Almost always larger than expected, because old data contains cases the current rules would not permit.
• Double maintenance during the transition: the old system has to keep working while the new one is unfinished.
• Unwritten rules, discovered one at a time, usually after launch.
• User training and a temporary drop in productivity. That is real even when the new system is better.
• Search visibility, if the system serves public URLs. That is separate work, not a side effect.

Illustrative scenario, not a description of a client project

Imagine a company deciding to rebuild an internal system because it is "old and slow". On review the code turns out to be sound, and the slowness comes from two things: a capability of the existing system that was never switched on, and one manual step repeated daily. Both are fixed in days. A rebuild would have taken a year and ended with the same manual practice in a new interface. This is an example of how we weigh the decision, not a promise about the conclusion — another company with the same symptom may have an entirely different answer.

How to frame the decision

• Write down which decision has to be made and by when. "What to do about the system" is not a decision.
• Name who will take it and what information they are missing.
• Run the four checks and write the answers down, even the uncomfortable ones.
• Ask any supplier to describe a partial route. If there is none, ask them to explain why.
• Separate the assessment from the implementation. Whoever will earn from the outcome should not be judging whether the outcome is needed.

That last point matters most and is the least comfortable. If the assessment is done by the prospective implementer, the answer will almost always be the one that gives them more work — frequently without any dishonesty at all, simply because that is how it looks from where they stand.