You have a system that's been running for seven years. Slow, dated-looking, and every small change takes a week and breaks something else. The recurring question: patch it or rebuild?
This decision is expensive in both directions, so let me give you criteria instead of opinions.
First: "old" is not itself a flaw
A system running well for 10 years that needs only rare changes is a successful system, not a problem. Age isn't grounds for demolition. Specific things trigger this decision:
Signs patching has become a money pit
1. Every change breaks something else. The clearest indicator. It means the parts are so entangled nobody can predict the impact of a change.
2. Nobody can work on it. The technology is old enough that developers are hard to find, or whoever wrote it left with no documentation. That's an existential risk, not an inconvenience.
3. The technology itself is unsupported. A PHP version or framework no longer receiving updates means new security vulnerabilities have no fix. That's a risk decision, not a technical one.
4. Annual maintenance has become a large share of a rebuild's cost. If you pay 40% of a new system's price every year just to keep it alive, the math is clear.
5. The system now blocks your growth. You want a new branch and it doesn't support branches. You want a mobile app and it has no API. At that point the system is a ceiling on your business.
Signs patching is still smarter
- The system is stable and problems are specific (one slow screen, a missing report). - The technology is still supported and developers are available. - You need a limited set of new features that can be built as separate modules. - Your data is clean and well-structured.
In these cases a rebuild is an unjustified gamble.
The middle path we often recommend
You don't have to choose between "keep everything" and "demolish everything." There's a third approach that works very well: incremental replacement.
You build the new system module by module; each new module runs alongside the old one and talks to it, and once stable the old one is switched off.
Example: start with a new sales module reading from the same existing database. Run it a month, let it settle, then move inventory. And so on.
Why is this safer? Your business never stops, you can fall back to the old module if something breaks, and the cost spreads over months instead of one payment.
The downside: it takes longer than a clean rebuild and needs more careful planning.
The most dangerous part: the data
Whatever you decide, your data is your most important asset — and in migrations most disasters happen here.
Rules we don't break: - A full backup before any step, tested by restoring it. - Migration rehearsed on a copy first, never on live data. - Sample verification afterwards: do balances match? Is the record count right? Are dates correct? - The old system stays available read-only for a period after the move.
Bottom line
Ask: is this system preventing growth, and how does the cost of keeping it alive compare to replacing it? If it's a ceiling on your business and maintenance is draining you, incremental replacement is the safest route. If you want a neutral assessment of your current system before deciding, that's work we do — and the recommendation is honest, even when it's "leave it alone."