When a business is frustrated with its systems, the instinct is to replace them. It feels decisive. It also happens to be the option most heavily marketed to you. But before committing to a replacement programme, it is worth asking a narrower question: is this system incapable, or is it merely isolated?
The distinction matters enormously. An incapable system genuinely cannot do what the business needs, and no amount of connection will fix that. An isolated system can do its job perfectly well but cannot tell anything else what it has done — and that failure shows up as symptoms people mistake for incapability.
The symptoms of isolation
- The same record is typed into two or three systems by hand
- Two departments report different numbers for the same measure
- Someone spends the first week of every month reconciling exports
- A question that spans two systems requires a person, not a query
- Nobody can say where a request currently sits
None of these are capability problems. Every one of them is a connection problem — and replacing a system does not automatically solve any of them. Plenty of organisations have replaced an isolated system with a newer isolated system and found the symptoms intact.
What integration actually requires
Integration is not simply moving data between systems. Done properly, it forces a set of decisions that most organisations have never explicitly made.
- Which system is the authority for each field — and what happens when they disagree
- One canonical identifier for the things that matter: a customer, an order, a product
- What a record means, agreed across every department that touches it
- How failure behaves — because an interface that fails silently is worse than none
An integration that fails silently is worse than no integration at all. At least a manual process knows when it has stopped.
When replacement is the right call
Sometimes it is. A system that is genuinely unsupported, that cannot meet a regulatory obligation, or whose vendor has disappeared is a liability regardless of how well you connect it. The point is not that replacement is always wrong — it is that replacement should be a conclusion you reach, not the assumption you start from.