A rebuild swaps known faults for unknown ones
An old system holds years of decisions. The discount that applies to one group of customers, the export the accounts team runs on the first of each month, the way a part-refund is recorded: each was added for a reason, and few were written down. A rebuild has to rediscover every one of them. The ones it misses appear after launch, as behaviour the business relied on and no longer has.
The old system also keeps running while the new one is built. It still needs fixes and small changes, so for months the business pays for two systems. Estimates for rebuilds tend to run over for the same reason: they cover what people remember the system doing, and the full list only becomes clear once the work is under way.
The frustration usually has a short list of causes
When changes are slow and risky, the cause is rarely the whole system. It tends to come from a few specific conditions:
- There are no automated tests, so every change is checked by hand and mistakes reach users.
- The framework or language version is years behind, so security updates have stopped and newer tools will not work with it.
- One area of the code does too much, and everything else depends on it.
- Nothing is documented, so each developer has to work out how the system behaves before changing it.
- A handful of database queries slow down the pages people use most.
Each of these can be fixed inside the existing system, one at a time, while it stays in use.
When improving is the right route
Improvement makes sense when the foundations still hold:
- The system does the job the business needs, even if it does it awkwardly.
- The data is sound and people trust the figures that come out of it.
- The trouble is concentrated in a few areas.
- The technology is still supported, or there is a clear upgrade path to a supported version.
- You have access to the source code, the hosting and the database.
Under these conditions a rebuild would spend most of its budget recreating what already works.
When a rebuild is justified
Some conditions do call for a replacement:
- The platform has been discontinued and has no upgrade path, so security updates will never arrive.
- The business has changed so much that the system models the wrong thing, and every feature works around its structure.
- You do not have the source code, or the licence does not allow it to be changed.
- Targeted improvements have been tried, and the cost of each change keeps rising anyway.
One of these on its own is often enough. Frustration alone is not on the list, because it says little about what is underneath.
Improvement works best in stages
The first stage makes the system safe to work on. Backups are restored to prove they work, the code goes into version control, accounts and credentials move under the business's control, and a separate copy of the system is set up for testing changes.
The second stage adds automated tests around the parts that handle money and customer data, so later changes can be checked in minutes. Then the framework and language are brought up to supported versions, one step at a time. Then the slowest pages and the most fragile areas get attention.
Each stage is delivered and in use before the next begins. The business sees results early, spends in measured amounts, and can stop or change direction after any stage.
A failing part can be replaced on its own
Between improving and rebuilding there is a middle route. When one part of a system is beyond repair, that part can be rebuilt while the rest stays. A new reporting area can read the same database. A new customer portal can sit beside the existing admin screens.
The old and new parts run side by side until the new one has proved itself, and then the old part is switched off. Repeated over time, this can replace an entire system without a single high-risk launch day, and the business keeps working throughout.
If you rebuild, carry the old system's knowledge across
When a rebuild is the right call, a few habits keep it under control:
- Write down what the current system does before designing the new one, including the manual steps people take around it.
- Move the data early and repeatedly, with checks on totals and record counts, so the final switch is a rehearsed step.
- Launch a smaller first version that covers the essential work, and add the rest in later releases.
- Keep the old system available for an agreed period after the switch.
The decision gets easier with facts
A review of the code, the versions it runs on, the data and the hosting shows which of these conditions apply. It also gives each route a cost, which turns a debate about preferences into a comparison of numbers.
If you have software that has become slow or expensive to change, tell us what it does and where it holds the business back. We will reply in writing with what we would look at first.