When Two Systems Won't Talk to Each Other

Somewhere in your business, a person is an integration. They open one system, read a number, open another system, and type it in. They do it every Monday, or every time an order arrives, or whenever someone remembers. The second system is therefore only ever as current as the last time somebody had a spare afternoon, and every retype is a chance to fat-finger a figure that nobody will catch until it matters.

This is the most common automation problem there is, and it's usually described wrongly — as "our systems don't integrate", which sounds like a permanent fact about the software. It rarely is. Here's what "won't talk" actually means, and your real options in order of what they cost.

We do this work (Automation & Integration is one of our services), so read accordingly. The options below are listed cheapest first, and the cheapest one is frequently the one nobody checked.

Four different problems wearing the same sentence

Nobody switched it on. The single most common case. The integration exists, ships with the product, and is sitting behind a settings page nobody has opened. Sometimes it's on a tier you already pay for. Check this before anything else — it costs twenty minutes and it ends the conversation more often than you'd think.

There's a way in, but no one has used it. The system has an API, or a webhook, or at minimum a scheduled export. The capability is there; the work of connecting it hasn't been done. This is the normal case and it's a build, not a rescue.

The data doesn't line up. Both systems are perfectly willing to talk. The trouble is one calls it a customer and the other calls it an account, one stores a full name and the other a first and last, and the IDs have nothing to do with each other. No amount of connectivity fixes this — it's a mapping problem, and it's where the real effort in most integrations goes.

The door is genuinely locked. A vendor portal with no API, no export, and a login somebody types by hand. This one is real, and it's a contract question before it's a technical one: ask the vendor what they offer and at what tier. Occasionally the answer is that you're paying for a system designed to keep your data inside it, which is worth knowing while you still have a renewal date.

Naming which of the four you have takes an hour. Skipping that hour is how businesses end up buying middleware for a problem that was a checkbox.

The options, cheapest first

1. The integration that already exists. Native connectors, marketplace apps, the "connect your account" button. Free or nearly so, maintained by the vendor, and it survives their updates. The limitation is that it does what it does — if you need one extra field, you're moving down the list.

2. Their API, on a schedule or on an event. Most modern systems have one. A small piece of software reads from one and writes to the other, either on a timer or when something happens. This is the workhorse, and it's usually a smaller job than the phrase "custom integration" suggests, particularly when the mapping is straightforward.

3. Webhooks, where the source will push. Better than polling when it's available: the source system tells you the moment something changes instead of you asking every fifteen minutes. Cheaper to run, faster, and fewer moving parts. It does mean handling the case where a message arrives twice or not at all, so it needs a little care rather than a lot.

4. Scheduled export and import. The unglamorous one that's often correct. A file drops somewhere nightly and gets picked up. Nobody puts it in a brochure, but for data that doesn't need to be current to the second, it's cheap, extremely predictable, and it fails in ways you can see. Don't rule it out because it feels old-fashioned.

5. A platform or middleware in the middle. Zapier, Make, Power Automate, or a proper integration platform. You're buying somebody else's connector library and paying per task or per seat. The right call when the connectors cover you and the volume is modest — worth its own decision, because the cost lands in a very different place than a build does.

6. A person. This is where you are now. It is not free, it's just paid out of a different budget. Put the hours a month against it and it usually turns out to be the most expensive option on this list, plus the only one that makes typos.

7. Replace one of the systems. Last, and we'll argue against it. Migration costs you a retraining cycle, a data conversion, and a quarter of everyone's attention, to solve a problem that connecting what you own usually solves for a fraction of it. And if you do migrate, be careful how the result gets described: things get migrated, and what actually landed at the other end is something you check, not something the plan promises.

The question that decides the design

Before any of it: which system is right when they disagree?

Every integration eventually faces the same moment. The address is different in the two systems. Which one wins? If you can't answer that in one sentence per field, you don't have an integration design yet — you have two systems about to fight, slowly, in production, with your team refereeing.

Answer it and most of the rest follows. One-way sync, from the system of record to the one that displays it, is dramatically simpler and safer than two-way, and it is what most businesses actually need once they're asked directly. Two-way sync is a genuinely harder problem and should be chosen deliberately, not drifted into.

What breaks integrations later

Integrations don't fail on day one. They fail in month seven, and almost always for one of these reasons:

• Credentials rotated. Someone changed a password or a token expired, and the automation has been failing politely ever since.
• The API changed. Vendors deprecate versions. They usually email about it, to an address nobody reads.
• A new field appeared. Or a required one started arriving empty, and the mapping had no opinion about that.
• Volume grew. The rate limit that never mattered at fifty records a day matters at five thousand.

Which is why the single most important feature of any integration isn't speed, it's noticing. Every connection should log what it did and raise something a human actually sees when it fails — a ticket, an alert, a message in the channel your team already watches. A sync that quietly stopped two weeks ago is worse than no sync, because everyone is still trusting the numbers.

If you'd rather someone else owned that watching, it's part of what Managed DevOps does. If the thing in the middle is a system nobody understands anymore, that's a takeover before it's an integration.

Where to start

Pick the one connection that costs you the most hours and answer three questions about it: does an integration already exist, does either system have an API, and which one is right when they disagree. That's enough to tell you which of the seven options you're in, and roughly what it'll take.

Or have it done: our free automation map covers exactly this — which of the tools you already pay for can talk to each other, which need something built, and what the manual version is costing you a month. Five working days, free, and yours to keep whether or not you hire us.

The tools you already own usually have a door in them. Most of the time, nobody has tried it.