There is a moment in most growing businesses where someone says: "the problem is we've got too many systems, we need one platform that does everything."
It is an understandable reaction to a real problem. It is also, most of the time, the most expensive available solution to that problem (and it has a failure mode that the cheaper option does not.
What the problem actually is
The symptom is that a person is carrying data between systems. The phone system knows about the call, the CRM knows about the contact, the diary knows about the appointment, the accounting package knows about the invoice, and somebody with a second monitor is retyping a name and a postcode four times a day.
The instinct is that this is a too many systems problem. It is not. It is a no connections problem. Those look identical from the inside and have very different price tags.
You can tell them apart with one question: is each individual system doing its own job well? If your accounting package is fine at accounting and your phone system is fine at telephony, the systems are not the problem. The gaps between them are.
Why replacement is expensive in ways nobody budgets for
The licence comparison is the easy part and usually the smallest part.
The re-learning. Two to three months of reduced throughput while everybody works out where things are. This is real, it is rarely budgeted, and it lands on the same people who are already busy.
The lowest common denominator. One platform doing eight jobs does most of them adequately and none of them as well as the specialist you replaced. Sometimes adequate is fine. Sometimes the thing you gave up was the thing you were actually good at, and you find out in month four.
The historical data. It never migrates as cleanly as the demo suggests. Custom fields, attachments, old notes, the eleven years of context in the free-text box. You will keep the old system read-only "just for a while", which means you now have nine systems instead of eight.
The single point of failure. Everything on one platform means everything down together, and one vendor with complete pricing leverage at renewal.
What integration costs instead
Connecting two systems properly is a defined project with a fixed scope. It does not disrupt anyone's day job. It can be done one connection at a time, starting with the one that hurts most, and each connection delivers value the week it goes live.
It is also reversible. If a connection turns out to be wrong, you remove it. Removing a migration is not a thing you can do.
The honest downside: integrations are maintenance. APIs change, credentials expire, a provider deprecates a webhook. It is a small ongoing load rather than zero. Anyone who tells you an integration is fire-and-forget has not maintained one.
The order that works
1. Map what actually happens. Not the ideal process) the Tuesday afternoon process, including the workaround somebody invented in 2023 that everyone now depends on. Every hand-off, every re-key, every place work waits.
2. Find the hand-off that costs most. Usually measured in either delay (work waits a day for somebody to notice) or errors (a transposed digit costs a job). Frequently it is the phone-to-CRM gap, because phone systems are the most commonly unconnected thing in a small business.
3. Connect that one. One connection. Live, working, watched for a fortnight.
4. Re-map. Fixing the biggest gap changes which gap is now biggest, and it is often not the one you would have predicted. This step is why the sequence matters more than the list.
5. Repeat until the remaining gaps are not worth closing. There is always a last mile that costs more to automate than it costs to do by hand. Stopping there deliberately is a decision, not a failure.
When replacement genuinely is right
Being fair to the other side, there are cases:
A system that is bad at its own job. If your CRM is genuinely unusable, connecting it more tightly to everything else makes the problem larger, not smaller.
A vendor that will not open up. Some products have no meaningful API, or price it out of reach. You cannot integrate what refuses to be integrated, and that is a legitimate reason to move.
Genuine tool sprawl at cost. Eight subscriptions where three would do, and the consolidation saving is real money rather than a rounding error. This is the strongest financial case and it is worth checking the actual numbers rather than assuming.
A real change of shape. A business that has genuinely changed what it does (new service line, new market, new scale) sometimes has systems fitted to a company that no longer exists.
What these have in common is that the case is specific and survives being written down. "We have too many systems" does not survive being written down. "Our CRM has no API and our phone system cannot pass caller ID, so every call is manually re-keyed" does.
The middle path, which is where most people land
Keep what works. Connect it properly. Replace only the specific component that is failing at its own job, and connect the replacement to everything else.
That gets you the outcome people actually want (one place to look, nothing typed twice, no work waiting for a human to notice) without the three-month productivity hole and without betting the operation on one vendor.
It is less satisfying than a clean sweep. It is considerably cheaper, and it is much easier to stop halfway through if you learn something.
Where AI fits, since it is not the point of this article
Mostly at the edges rather than in the middle. Integrations are plumbing and plumbing should be deterministic (you do not want a model deciding whether to write a record.
Where models genuinely help is in the messy inputs: turning a free-text enquiry into structured fields, matching a supplier invoice to the right job when the reference is wrong, summarising a call so a human reads four lines instead of four minutes. Those are the joins where a rule cannot be written, and they are a small proportion of any real integration.
Getting that proportion right is most of the skill. A project that is 90% plumbing and 10% model is usually well designed. One that is the other way round is usually about to be expensive.
If you want the map of your own hand-offs drawn before anyone proposes a migration, that is exactly what the free AI Opportunity Assessment produces) and the integrations page covers how the build work is scoped afterwards.