Nine signs your legacy system is costing more than a rebuild

The nine signs

Very few organisations replace a working system because they want to. They replace it because the cost of keeping it has become intolerable — usually long after the tipping point. These are the signals we see in technical audits.

1. Only one person can safely change it. The bus factor is one. Every change queues behind a single individual, and their holiday is a business risk.
2. It runs on unsupported software. An out-of-support OS, database, framework or runtime means no security patches. This is a live liability, and increasingly a problem for your cyber insurance and your enterprise customers' supplier assessments.
3. Staff keep spreadsheets to compensate. Shadow systems are a precise map of where the software fails. If three departments maintain their own version of the truth, the system has already lost.
4. Integration is impossible or manual. No API, no export, so someone rekeys data between systems. This cost is invisible on any budget line but enormous in aggregate.
5. Small changes cost disproportionately. When "add a field to a form" is a two-week estimate, the architecture is telling you something.
6. You cannot recruit for it. If the skills are scarce or the technology is obsolete, your supply of maintainers is shrinking and getting more expensive.
7. No test coverage, so nobody dares refactor. Fear of change is the terminal stage. The system calcifies, technical debt compounds, and every release is a gamble.
8. It cannot do something the business now needs. Mobile access, real-time data, self-service for customers, multi-currency, an audit trail. Strategy is being constrained by software.
9. Downtime is frequent or recovery is untested. If you have never restored from backup, you do not have a backup — you have a hypothesis.

One or two of these is normal. Three or more, and the economics have probably already flipped.

How to work out whether replacing is cheaper

Most of the real cost is invisible because it sits in salaries rather than invoices. Add up the annual figure honestly:

Compare the annual total against a phased replacement amortised over three years. In audits, the manual workaround line is almost always the largest and almost always the one nobody had quantified.

Do not do a big-bang rewrite

The instinct is to build a replacement in parallel and switch over one weekend. This is the most reliable way to fail, for consistent reasons:

• The old system's behaviour is not documented, so nobody knows the full requirement — the requirement is the code, including twenty years of undocumented edge cases.
• Nothing is delivered for a year or more, so the project has no way to prove value and loses its sponsor.
• The business keeps changing during the build, so the target moves.
• Cutover concentrates all risk into one irreversible weekend.

The strangler pattern, in plain terms

Replace the system in slices, with old and new running side by side. Each slice is small enough to deliver, test and reverse.

1. Put a boundary in front. An API layer or reverse proxy so callers no longer talk to the legacy system directly. Nothing changes functionally; you have created a seam.
2. Pick the highest-pain, lowest-risk slice. Often reporting — read-only, so mistakes are cheap, and usually where the manual effort is worst.
3. Build that slice properly in the new stack, reading from the existing data store initially. Route traffic to it through the boundary.
4. Repeat, slice by slice, moving data ownership across as each area stabilises.
5. Retire the legacy system when the last slice moves — by which point it is a formality rather than an event.

This is slower in total elapsed time and dramatically more likely to finish. Value arrives from the first slice, and every step is individually reversible.

What to do first

Before committing budget to either maintenance or replacement, get an honest technical assessment. A two-week audit should give you:

• A written view of code quality, architecture, dependencies and security posture
• What is genuinely salvageable and what is not
• An estimate for maintaining as-is versus phased replacement
• A recommended first slice, with a cost

Insist on owning that document, and on being able to hand it to any supplier. If an assessment can only be acted on by the firm that wrote it, treat it as a sales proposal rather than an audit.

We do these as standalone engagements — see web application development and how we work, or ask about an audit.