Repair, wrap, migrate or replace: what to do with the system nobody wants to touch.

Bottom line: there are only four options, the right one is decided by the state of the system rather than by anybody's preference, and the most commonly recommended option — replace it — is the most expensive and fails most often.

I have spent a fair share of two decades on systems that were older than the people operating them. This is the framework I actually use.

Option one: repair

Fix the system where it stands. Recover the documentation, stabilise the platform it runs on, fix the known faults, and put it under proper backup so the next failure is an inconvenience rather than an event.

Right when the system still does the right job and the risk sits around it rather than in it — ageing hardware, no backups, one person who understands it. Cost: the cheapest of the four, call it the baseline. When a business-critical database failed at one client, rebuilding it to running took a month. Repair is usually measured in weeks.

Option two: wrap

Leave the core alone and build modern access around it — automated exports, a web front end, connections into newer tools. The old engine keeps doing what it is good at; people stop having to work the way it demands.

Right when the logic inside is sound but using it is painful, or when it must feed a modern platform it was never designed to meet. Cost: roughly two to three times a repair. The trap: a wrap is a commitment to keep the core alive, so it buys years rather than decades.

Option three: migrate

Move the data and the workflow to a modern platform and retire the old system. Not a rebuild of the software — a re-homing of what it holds.

Right when the platform underneath is dying — an operating system out of support, hardware you cannot buy, a vendor that no longer exists — but the process itself is fairly standard. Cost: perhaps five times a repair, and the real work is the data. Twenty years of records never come out clean, and the cleaning is the project.

Option four: replace

New system, and usually a new way of working. The most expensive option — ten times a repair is not unusual once retraining and the productivity dip are counted — and the one with the highest failure rate, because it is really a change-management project wearing an IT badge.

Right when the business has outgrown the process rather than the software. If the old system does the wrong thing, no amount of repairing, wrapping or migrating will make it do the right one.

How to tell which one you are looking at

• Does it still do the right job? If yes, replacement is off the table for now — you would be paying the maximum to change the thing that is not the problem
• Where is the risk — in the software or around it? Risk around it points to repair. Risk in it points further down the list
• Can you get the data out, complete and intelligible? If nobody knows, find out before deciding anything — it is the fact that separates a migration from a rewrite
• Who understands it? If the answer is one person, their notice period is your planning horizon

The honest bit

The four options are only all available while the system is still running. After a failure the list shortens to whatever can be done under pressure, at a price set by urgency rather than by choice. Most of the expensive legacy disasters I have been called into were cheap problems that were postponed until they were not.

So the real decision is not which option. It is whether the decision gets made deliberately this year rather than by the system itself, at a time of its choosing.

---

Adam Bell runs Innov8 in Hong Kong. He has repaired, wrapped, migrated and replaced systems across four technology eras — and will tell you plainly which one you are looking at, including when the answer is do nothing for six months.