Our legacy system: repair it or replace it?
Short answer
A big-bang rewrite is the most reliably failing shape of project — modernisation typically overruns by 150%, and the old system still needs maintaining throughout. A two-to-three-week technical audit answers the question with numbers for both options rather than opinions.
Typical duration: 2–3 weeks
$3,800
What this looks like
- Nobody dares change certain parts because nobody knows what else breaks
- The original developers left without documentation
- Every small request is answered with "possible, but risky"
- Maintenance costs rise yearly while features do not
- Vendor quotes to rewrite it differ by multiples
Why this happens
The repair-or-replace question is almost always answered by feel rather than by numbers — and the feel leans towards replacing, because building something new feels more controllable than understanding something old.
The numbers say otherwise. Only about 29.7% of software projects land on time, on budget, and at quality. Median cost overrun on large IT projects reaches 45%, and legacy modernisation specifically tends to reach 150%. Throughout the rewrite the old system must stay alive — so you pay for two systems to end up with one.
What makes the decision possible is not a consultant’s opinion but a direct read of the code: which parts are genuinely dangerous to touch, which are actually healthy, and what each option really costs.
How we solve it
- 01
Reading the code
We read the system directly — quality, unmaintained dependencies, and inherited security gaps. One week.
- 02
Danger map
Which parts are dangerous to touch and why, written so a non-technical reader can follow. A few days.
- 03
Numbers for both options
Estimated cost to repair and to replace, with the risks of each. We say which we recommend and why.
- 04
A staged plan
If the answer is replace, the plan is staged with the old system still running — not a big-bang rewrite.
Numbers from our own work
Our recommendation always carries numbers for BOTH options, not one
We say plainly if we think the system is best left alone
The system map is written to be read by the board, not only by engineers
Mistakes we keep seeing
- Rewriting everything at once and hoping the switchover survives one weekend
- Judging vendor proposals with nobody technical on your side
- Migrating data without reconciliation, then finding the discrepancy months later
Questions we are asked most
Do we have to hand over all our code?
Yes, under an NDA. Reading it directly is the only way to answer the question with numbers; judging from outside only produces the opinion you already have.
What if the answer turns out to be “leave it alone”?
That is a legitimate answer and we have given it. A system that runs, costs a reasonable amount, and rarely changes is sometimes cheapest left alone — and saying so means no follow-on work for us.
Can our own team do the fixing?
Yes, and that is what we recommend when the team is capable. The audit output is written so anyone can act on it, not so that we have to.
Updated 30 July 2026 · Neuraltan
If this is happening to you
Tell us the situation. We will say plainly whether this is worth doing now, and how long it takes.