When to connect your existing tools instead of replacing them
Build or buy is a false choice. The cheapest fix is often neither, and instead involves connecting the tools you already pay for so a person stops moving data between them.
When a business outgrows its systems, the options presented are usually build something new or buy a bigger platform. Both involve replacing software that, in many cases, is working perfectly well at the job it was chosen for.
There is a third option that gets mentioned less because fewer people profit from it: leave the tools in place and connect them. Often it is the cheapest fix available, and sometimes it is exactly the wrong answer. This post is about telling those apart.
What integration actually means
Stripped of jargon, integration means data moves between two systems without a person carrying it. When a sale is recorded, stock adjusts and the invoice appears, with nobody retyping anything.
That is the whole idea. The value is not technical elegance, it is removing the human step where errors and delays enter.
The signal that integration is the right answer
There is a fairly reliable test. Ask whether each individual tool is good at its own job.
If your accounting software handles accounting well, your booking system handles bookings well, and the frustration is entirely about getting information from one to the other, then your tools are fine and the joins are the problem. Replacing good tools to fix a join is expensive and usually disappointing, because the replacement is rarely as good at each individual job as the specialist tool it displaced.
Three more signals point the same way:
- Your team likes the tools they have. Adoption is already solved, which is the hardest part of any software change.
- The manual work is predictable. Export this, reformat, paste there. Repetitive and rule-based work is exactly what automates well.
- Each system holds data the others need, and everyone knows which system is authoritative for what.
When integration is the wrong answer
This is the part that gets skipped, and it is where integration projects go wrong.
- The tool itself does not fit. If people are already working around a system's limitations, connecting it to other things preserves the limitation and adds complexity on top.
- There is no reasonable way in. Older software with no API, no export beyond a printed report, and no database access will resist integration at any price.
- The number of joins is large. Two systems means one connection. Five systems that all need each other's data means up to ten. At that point a single system holding the shared data is usually simpler and cheaper.
- Nobody agrees which system is right. If sales and accounts hold conflicting customer records and neither is authoritative, integration will faithfully synchronise the disagreement.
Three ways to connect things
| Approach | Cost | Best for |
|---|---|---|
| Native integration | Usually included | Common pairings that vendors already support |
| No-code connector | £20 to £100 a month | Simple, low volume, standard triggers |
| Custom integration | One-off build cost | Business specific logic, higher volume, awkward systems |
Always check the native option first. It is free, supported by the vendors, and it will not break when you are not looking. People skip this step surprisingly often and pay for a connector that duplicates something already built in.
No-code tools such as the various automation platforms are genuinely good for simple flows: a form submission creating a record, a payment triggering an email. They become expensive and fragile when the logic gets conditional, when volume is high, or when you need to reason about what happens after a failure.
Custom integration earns its place when the rules are specific to your business, when you need reliable handling of the awkward cases, or when one of the systems is old enough that nothing off the shelf speaks to it.
The cost people forget
An integration is a permanent relationship with someone else's software. That means it can break for reasons entirely outside your control: an API version is retired, a field is renamed, authentication rules tighten.
None of that is a reason to avoid integrating. It is a reason to keep the number of connections deliberate rather than building every one you can imagine, and to budget for them in ongoing maintenance.
One practical detail worth insisting on: an integration should tell someone when it fails. Silent failures are worse than no integration at all, because everyone continues trusting numbers that quietly stopped updating three weeks ago.
An integration that fails loudly is a minor inconvenience. One that fails silently is a data problem you will find out about from a customer.
A sensible order to work through
- Write down every point where a person moves data between systems. Include the weekly report someone assembles by hand.
- Count the minutes each one takes per week. This gives you a ranked list and a budget at the same time.
- Check for a native integration for the top one or two. Free is a good price.
- Try a no-code connector if the flow is simple and the volume is low. It is quick to test and quick to abandon.
- Consider custom work only for the joins that remain, where the logic is genuinely specific to how you operate.
Working in this order tends to solve most of the pain for very little money, and leaves you with a much clearer view of whether anything larger is actually justified. If it turns out the tools themselves are the problem, this comparison of building against buying is the next thing to read.
Frequently asked questions
Usually yes, often by a large margin, because you keep tools your team already knows and avoid data migration entirely. It stops being cheaper when the number of connections grows large or when the underlying tools do not actually fit your process.
There are usually workarounds, such as scheduled file exports or database level access, but they are more fragile and more expensive to maintain than a proper API. If a core system has no reasonable way in and no upgrade path, that is a genuine argument for replacing it.
For simple, low volume flows with standard triggers, frequently yes, and they are worth trying first because they are quick to set up and cheap to abandon. They tend to struggle with conditional logic, high volume, and error handling, which is where custom work becomes worthwhile.