When to replace a system rather than integrate it

The question usually arrives in the same form: "can you connect this to that?" There is an old system in the middle of the business, something newer at the edge, and a gap between them that somebody is currently bridging by retyping.

Asked for a quote, an honest consultancy should produce two. One to build the bridge. One to retire the old system altogether. They are very different numbers, and the smaller one is not always the right one.

The default is integrate, and the default is usually right

Replacing a working system is expensive in ways the invoice does not show. The data has to move. People who were fast become slow for a while. Ten years of small workarounds, each one somebody's solution to a real problem, have to be rediscovered the hard way.

Integration avoids nearly all of that. The system people know stays where it is, and the retyping stops. If the old system still does its actual job well, and the pain is at the seams rather than in the middle, that is the answer. We build a lot of these, and most of them are the right call.

But "usually" is doing some work in that sentence.

The test: does the system still describe your business?

Every system is a description of the business that bought it. It encodes what a customer is, how a job moves from enquiry to invoice, who is allowed to do what. When it was chosen, that description was roughly true.

Businesses change shape. Systems mostly do not. And the moment the description stops being true, something specific happens: the real process moves out of the system and into the space around it. Spreadsheets appear. A whiteboard becomes load-bearing. The system is still updated, but afterwards, as a record of what already happened somewhere else.

That is the test, and it is worth applying before anyone talks about software. If the system still describes how the business works, integrate. If the business now lives in the workarounds, integration wires the wrong description into everything new, and you will pay to automate the retyping around a system nobody is really using.

If the real process lives in the spreadsheets around the system, integration just automates the workaround.

What pointed us at replacement, when it did

A ticketing tool we retired for a payroll team is a fair example. The tool worked, in the sense that tickets went in and came out. But the team's actual escalation rules changed by time of day and day of week, and their deadlines only made sense counted in working days. None of that could be said in the tool's own language. The process had left the system, so we built one that could say it, and the off-the-shelf licence went.

Set against that: when we built a practice management platform for our sister accountancy firm, Xero, HMRC and Companies House all stayed. Those systems still describe their jobs precisely. They were integration targets, not replacement candidates, and treating them as anything else would have been vanity.

The other case that points at replacement is crowding rather than age. One client's IT strategy review found overlapping tools doing the same job in different corners of the business. Consolidating until every licence earned its keep cut their software spend by 70%. No single system was broken; the estate was.

70%: Software spend cut by consolidating overlapping tools
2: Quotes you should expect: one to bridge, one to replace

The costs each side hides

The comparison goes wrong when it is made between the integration invoice and the replacement invoice, because both numbers are incomplete.

Integration hides a standing commitment. Every joint between two systems is something that can break when either side changes, and the old system's licence, hosting and vendor relationship all continue underneath it. You have not removed the old system's future; you have attached new things to it.

Replacement hides the migration. Moving the data is the part everyone underestimates, and it is also the part that decides whether the project is remembered as a success. When we moved an accountancy practice from Digita to IRIS, the client data was mapped, verified and reconciled before switch-over, and filing carried on uninterrupted. That order of operations is the whole trick. Done the other way round, the same project produces six months of "does anyone trust these numbers?"

How to decide, in an afternoon

You do not need a discovery project to apply the test. You need an honest hour with the people who use the system, and a short list.

01Write down what the system believes: what a customer is, how a job flows, who does what
02Walk the real process and note every point where it leaves the system for a spreadsheet or a memory
03If the two mostly match, quote the integration. If they mostly do not, quote the replacement
04Whichever you pick, cost the part it hides: the standing upkeep of a joint, or the migration

If you get quoted for one option without the other being mentioned, ask why. A consultancy that only ever integrates is avoiding migrations; one that only ever replaces is selling software. The answer should depend on your business, not on their comfort.

We do both, and we have turned down each in favour of the other. If you have a system you are not sure about, the first conversation costs nothing, and "leave it alone, integrate the edges" is an answer we give often and happily.

We work with businesses across Knutsford, Alderley Edge, Wilmslow, Altrincham, Stockport and Warrington, and remotely for clients anywhere in the UK.