Short answer. Replace when the system itself is the constraint — when it cannot hold the data you need or cannot give it back. Integrate when the systems are individually fine but do not talk to each other. Most businesses assume the first and turn out to need the second.
By the time a business asks this question the symptoms are familiar. Someone re-keys the same order into two systems. The stock figure in one place disagrees with the stock figure in another and nobody can say which is right. A report that should take five minutes takes a morning, and it takes that morning every month.
The instinct is to conclude that the systems are bad and should be replaced. Sometimes that is correct. More often each system is doing its own job adequately and the failure is in the space between them — which no single vendor is responsible for, and which therefore nobody has fixed.
Replacing a system that was not the problem is expensive twice: once for the project, and again when the same disconnection reappears around the new system eighteen months later.
Two ways this goes wrong
The replacement that rebuilds the same silos. A business consolidates onto a larger platform expecting integration to come for free. It does, for the modules bought together. But the warehouse still runs its own thing, the accountant still wants their format, and one team keeps the spreadsheet they actually trust. Within a year there are four systems again — newer, and more expensive.
The scaffolding on a system that was always going to break. The opposite error. A system that genuinely cannot hold what the business needs gets propped up with syncs, exports and workarounds. Each one is individually reasonable. Together they become a structure nobody fully understands and no one can safely change.
Telling these apart is not a matter of taste. Five questions usually settle it.
Is the data model wrong, or is the data just isolated?
This is the important distinction. If a system cannot represent something the business needs — it allows one address per customer and you need three, it cannot express a partial shipment, it has no concept of a project — then no amount of integration fixes that. That is a replacement case.
If the system holds the right information and simply does not share it, that is isolation. Isolation is far cheaper to fix than replacement.
Can you get the data out?
A system with a usable API, or even a reliable scheduled export, can be integrated. A system that produces only PDFs, or whose export silently drops fields, has effectively taken your data hostage — and that is a strong replacement signal on its own.
This is worth checking against your obligations rather than just your convenience. The ATO expects that you can extract and convert your records into a standard format such as Excel or CSV, and that the information in them is not changed and is protected from being changed. A system you cannot cleanly export from is already a problem independent of this decision.
How much of the cost is retraining people?
Licence and implementation costs are visible and get compared carefully. The cost of thirty people being slower for two months rarely appears in the business case, and it is often the largest number in the whole project.
Integration usually leaves the people alone — everyone keeps working where they already work. That is not a small advantage. It is frequently the deciding one.
What is the switching cost of your history?
Two questions here: how many years of history do you genuinely need to carry across, and how much of its meaning survives the move? Historical data that lands in a new system stripped of its context is not history, it is volume.
If the answer is “we need ten years and half of it will not map cleanly”, then the migration is the project and the new system is incidental to it.
Is there one system everyone already trusts?
If there is, it is usually the right centre of gravity, and the question becomes what feeds it rather than what replaces it. If there is not — if every system has a faction that hates it — the problem may be neither integration nor replacement, but that nobody has agreed on what the business actually needs to record.
What each path actually costs
| Integration | Replacement | |
|---|---|---|
| Upfront cost | Lower, incremental | High, committed early |
| Disruption | Low — people keep their tools | High — everyone relearns at once |
| Where risk sits | Spread across small pieces | Concentrated at cutover |
| Time to first value | Weeks | Months to years |
| Reversible? | Largely yes | Not really |
The last row is the one to sit with. An integration that turns out to be wrong can be unwound. A migration that turns out to be wrong is a second migration.
The option most people do not consider
There is a middle path that gets skipped because no vendor sells it: leave every system exactly where it is, and build a read-only layer that pulls from all of them into one place for reporting.
Nobody changes how they work. Nothing is migrated. No system is replaced. What you get is a single consistent view — the stock number, the pipeline, the month — assembled from the systems that already hold the truth.
It is not a permanent answer to every problem. But it is fast, cheap relative to the alternatives, entirely reversible, and it does something valuable beyond the reporting: after a few months of seeing the data side by side, you will know precisely which system is actually the constraint. That is a far better position from which to decide on a replacement than the one you are in now.
When replacement is genuinely right
Three signals, any one of which is usually decisive:
- The data model cannot represent something the business needs, and no workaround has survived contact with reality.
- The vendor is gone, the product is end-of-life, or security patches have stopped.
- The system cannot give your data back in a usable form.
Absent those, integration deserves the first look — if only because it is the option you can still walk back.
Where to start
Not with a vendor. Start by writing down the three numbers your business argues about most, and tracing where each one actually comes from. That exercise takes a day or two and tends to answer the question on its own.
Praxis Arc Pty Ltd (ABN 44 700 059 025) designs, builds and maintains business systems from Perth, Western Australia.
References
- Australian Taxation Office — Overview of record-keeping rules for business