ARTICLE
Rebuild or refactor an existing system? Four tests
Rebuilding is not the default answer. When the problem lies in the process rather than the technology, or the core data structure still holds up, working on what exists often pays better than a rebuild. This article offers four tests you can apply yourself.
The short answer
If the core data structure still supports the business, fix in place first. If every new feature means changing the foundations, or nobody, not even the original developer, can explain where the data goes, a rebuild is the cheaper option. The test is not how old the system is but whether it can still be changed safely.
Four tests
1. Does the data structure still hold up?
This is the decisive one. Looks and flow can be adjusted, but if the original table design cannot express how the business works now, for instance it assumed one contact per customer and you now manage a whole group of them, then every new feature is a patch on a patch.
2. Is the risk of change controllable?
One question settles it: when you change feature A, can anyone say what else it touches? If the answer is that you find out by changing it, the system has lost its maintainability and further spending only builds up risk.
3. Is the problem the system or the process?
A fair share of the complaint that a system is unusable is really a process that was never sorted out, faithfully reflected back by the software. Rebuild in that case and you are back to the same problem six months later. Sorting out the process often saves the price of a whole system.
4. Are the skills and people still available?
If nobody will take on the technology the system uses, or the source code is incomplete, whether it can be changed stops being a technical judgement and becomes a practical limit.
There is a third option: staged replacement
The choice is not only between leaving it alone and rebuilding everything. In practice, the common approach is to build the most urgent part of the process as a new system, connect it to the old one through an API or data sync, and take over the remaining modules once the new system is stable. It avoids the risk of a single cutover and spreads the budget across years.
What to prepare before an assessment
- The table structure of the current system, or at least a list of its main functions.
- Requests raised in the past six months that were not built, and why they were turned down.
- Specific situations users actually report, rather than a general complaint that it is hard to use.
