There is a conversation that happens in almost every business we work with, usually about twenty minutes in.
Someone explains that the CRM does not talk to the finance system. We ask what they have tried. They list the automation platforms — the ones with the connector marketplaces, the drag-and-drop builders, the impressive logo grids. And then they say the sentence: "It does everything except the one thing we actually need."
This is not a failure of those platforms. They are good products solving a real problem. But every marketplace has a catalogue, and every catalogue has an edge — and the systems a business most needs connected have a habit of sitting just past it.
Why the edge is where your problem lives
Connector marketplaces are built on economics. A connector gets built when enough customers want it, which means connectors exist for combinations of popular systems doing popular things.
Your problem is, almost by definition, not that. If connecting your systems were a common requirement, you would have bought the product that does it. The reason it is still a problem is that some part of it is specific to you: a system nobody else uses, a version nobody has upgraded from, a rule that only applies in your industry, or a piece of data that means something different in your business than it does anywhere else.
So the catalogue covers the easy 80% — and the 20% it does not cover is the 20% that was costing you money.
What "no integration" usually turns out to mean
When a supplier says a system cannot be integrated, they are almost always saying one of five much narrower things. They are worth telling apart, because four of them are solvable.
"There is no connector for it." True, and irrelevant. A connector is convenience, not capability. If the system has an API, the connector is a few days of work, not a blocker.
"It has no API." Sometimes true. It rarely means the data is unreachable. Systems that predate APIs almost always have something else: a database you can read, a scheduled export, a file drop, a reporting interface. It is less elegant, and it works.
"It's on-premise." A network problem, not an integration problem. Legitimately requires care around security, and is not an obstacle.
"The vendor won't allow it." Occasionally real, usually a licensing conversation rather than a technical one. Worth reading the contract before believing it.
"The data doesn't map cleanly." This is the only genuinely hard one — and it is hard because it is not a technical problem at all.
The only difficult part
Nine times in ten, the difficulty in an integration is not moving the data. It is that two systems disagree about what a thing is.
Your CRM thinks a customer is a person. Your finance system thinks a customer is an account that pays invoices. Most of the time those are the same, until you meet a franchise group where one account covers eleven sites, each with its own contact, and one of those sites is also a supplier.
No connector resolves this, because it is not a data problem. It is a business decision that nobody has made yet, and software will force you to make it. This is why integration projects surface arguments that have been quietly avoided for years — and why the mapping conversation is worth more than the code that follows it.
A good integration project spends its first week on this and its remaining weeks writing something relatively simple. A bad one skips it, writes something clever, and produces a system that is confidently wrong.
What we actually do when the connector isn't there
The work is unglamorous and reliable:
Find out what the system genuinely speaks. Documented API, undocumented API, database, export, file drop, or in one memorable case a nightly email with an attachment. Something is always available.
Model the difference between the two systems explicitly. Write down what a customer, an order, a product means on each side, and where the definitions diverge. Get the business to agree, in writing, what happens in the awkward cases.
Build the translation as a first-class thing. Not a script on somebody's laptop. A service, with logging, retries, and alerting, that can be reasoned about when it misbehaves.
Make it safe to run twice. Networks fail mid-transfer. Idempotency — the property that processing the same message twice does no additional damage — is the single most important design decision in an integration, and it is the one most often skipped.
Decide what happens when it breaks. Because it will. Does it stop and alert? Queue and retry? Carry on with partial data? These are business decisions with real consequences, and they should be made deliberately rather than discovered during an incident.
The honest counter-argument
We should say clearly: if a connector exists for your situation, use it. Buy the platform, click the boxes, and spend your money on something else. Custom integration is worth building when the alternative is a person doing it by hand, or a workaround that only works because someone remembers to apply it.
The test is the same one that applies to most software decisions. What does it currently cost you to keep these two systems in agreement — in time, in errors, and in the risk that the person who does it leaves? If that number is small, leave it alone. If it is a person's job, or a monthly reconciliation that nobody enjoys, it is almost certainly cheaper to fix than to keep paying.
The gap between systems is where most businesses lose time, and it is the least fashionable part of software to work on. It is also, in our experience, where the return is most obvious.
If something in your business is only connected because a person connects it, we would be interested to hear about it.