Why this decision usually goes wrong
The conversation about a legacy system almost never starts with analysis. It starts with an event: a freeze during month-end close, a complaint from sales, a vendor announcing end of support, or a new director who worked with a different platform. From there the discussion becomes a contest between two narratives, "this system cannot cope any more" and "replacing it will halt the operation", and whoever holds more influence in the room wins.
Both sides are usually partly right, which is why the contest cannot be settled by argument. It is settled by measurement. There are four measurements.
The four criteria that decide it
1. Total cost of ownership, not the licence fee
Most companies do the annual-invoice arithmetic. The correct arithmetic adds five lines: licence and support, internal hours spent on manual workarounds, vendor hours on customisation and fixes, cost of rework caused by system error, and the opportunity cost of decisions not taken because the data will not come out.
In practice the last three lines usually outweigh the first two. Once they appear on the spreadsheet, "cheap" systems stop being cheap and the discussion changes tone.
2. Density and quality of the data the system holds
A legacy system holding ten years of production history with good integrity is a strategic asset regardless of how ugly its interface is. A modern system with an incomplete dataset and no audit trail is a liability that photographs well.
The operational question: if this system were switched off tomorrow, how much of the history would remain usable, and how long would reconstruction take? The answer changes the risk calculation of replacement completely.
3. Degree of coupling with the operation
Measure how many critical processes run through it, how many people depend on it daily, and how many business rules exist only inside it, undocumented anywhere else. That last number determines the real risk of substitution, and it is almost never established before the replacement contract is signed.
4. Vendor dependency risk
It is not only the incumbent that locks you in. Replacement frequently swaps a known dependency for a new and larger one, with the aggravating detail that the exit cost has not been tested yet. Ask, of both options: who owns the data, the integrations and the documentation, and what would leaving cost in 24 months.
The decision tree
| Situation | Decision | Why |
|---|---|---|
| Sound data, high coupling, ownership cost under control | Sustain and discipline | Replacing destroys value. The gain sits in governance, data contracts and interfaces, not in a new platform. |
| Sound data, high coupling, high ownership cost from manual workarounds | Integrate and automate around it | The system is not the problem, the gap between it and everything else is. An integration layer captures most of the value at a fraction of the risk. |
| Poor data, low coupling, few critical processes | Replace | Little to lose and little to migrate. It is the only configuration where replacement is clearly the best choice. |
| Poor data, high coupling | Neither replace nor integrate yet | Fix the data and document the rules first. Replacing here is the classic recipe for the project that blows through time and budget. |
| End of support announced | Depends on data and coupling, not on the announcement | End of support is a deadline, not a criterion. It sets when to decide, never what to decide. |
The right question is not "is this system any good?". It is "what exactly are we buying when we replace it, and why do we believe this will not happen again?".
Three frequent traps
- Mistaking user dissatisfaction for system inadequacy. A good share of complaints about a legacy system are really complaints about a badly designed process the system merely reflects. Swapping the platform without redesigning the process moves the problem to a prettier screen.
- Treating data migration as a technical task. It is a business task. Every undocumented rule has to be reconstructed by someone who knows the operation, and that person already has a full-time job.
- Accepting the promise that "the new one comes integrated". It comes integrated with the vendor’s own ecosystem. Integration with the rest of your operation remains a project, with its own cost and timeline.
What to do over the next two weeks
- Establish total cost of ownership across the five lines above, with real numbers rather than vendor estimates.
- Measure the system’s data quality: completeness of the fields that matter, duplication, and divergence against a second source.
- List the business rules that exist only inside the system. If the list passes ten undocumented items, your replacement risk is underestimated.
- Ask both options under consideration for the exit clause in writing. Whoever will not provide it has already answered the question.
With those four findings in hand, the decision usually stops being controversial. Not because the answer got easy, but because it stopped depending on who speaks loudest in the meeting.
If the decision has been stuck for more than a quarter
Usually what is missing is not information but a criterion every side of the table accepts. That is exactly what we structure in a 90-minute session with your executive team, at no cost and with no company deck.
Book the 90-minute session