Legacy system modernisation means changing software the business depends on without stopping the business. Usually that is not a rewrite: it is replacing one workflow at a time behind the existing interface, so each step is small enough to reverse if it goes wrong.
The decision
The dividing line is whether the system does the right things badly, or the wrong things well. Code that is ugly but correct should be repaired. A data model that no longer matches how the business works cannot be repaired, because every change fights it.
| Symptom | Points to |
|---|---|
| Messy code, correct behaviour | Repair, refactor gradually |
| Slow, but the logic is sound | Repair — usually a smaller job than it feels |
| Every new feature needs a workaround | The model is wrong — replace |
| Platform out of support, cannot be patched | Replace, and treat it as urgent |
| Nobody dares change it | Depends — often a testing problem, not a rewrite |
| Vendor gone, no source code | Replace, and start now |
Method
The new system takes over a piece at a time while the old one keeps running. Users see the same interface until the piece behind it is proven, and any step can be reversed on the day.
This finishes more often than a rewrite because it delivers value from the first step, and because no single step is large enough to be a crisis. It also survives a change of budget or priority halfway through — the parts already moved stay moved.
Questions
Repair when the system does the right things and is merely hard to work on, because a rewrite throws away years of accumulated correctness for a cosmetic gain. Rebuild when the underlying model is wrong for how the business now works, when the platform is out of support and cannot be secured, or when nobody can safely change it. Difficulty is a repair problem. Being wrong about the domain is a rebuild problem.
Often, and we will look before answering. We spend a short paid period reading the code, running it, and finding out what it actually does before we commit to a position — a system that looks alarming from the outside is sometimes perfectly sound underneath. What we will not do is recommend a rewrite by reflex, because it is the most expensive advice in this industry and the easiest to give.
That is the normal case rather than the exception. The system itself is the documentation: we read the code, watch it run against real work, and interview the people who use it daily, because they know the exceptions the original developer encoded. What comes out of that is a written description of current behaviour, which is worth having even if you then decide to change nothing.
No, and you should not. Big-bang replacements are how these projects fail — everything changes on one weekend, and any problem is a crisis. The alternative is to move one workflow at a time behind the existing interface, so the old and new systems run together and each step is small enough to reverse. It takes longer on paper and finishes more often.
We’ll tell you whether it’s a repair or a replacement — including when the answer is to leave it alone.