Who owns an integration once it works?

Integration proposals almost always describe the work: which systems, which data, how long. They very rarely describe what happens afterwards. Yet afterwards is where nearly all the problems live, because an integration differs from other projects in one way: it sits between two systems, at least one of which will change without asking you.

In short

• An integration is not an object you can build and forget. It is a relationship between two systems that both keep moving.
• The biggest risk is not a bug in the code — it is the unanswered question of who will notice that transfers stopped.
• Handover happens not when code is delivered but when somebody on your side knows what to do when something goes wrong.
• Settle before the work: who holds access, who may change the rules, who receives the fault signal.
• An agreement about changes on the other side is a separate thing, and usually nobody has one.

Why integrations break months later

A freshly built integration generally works. It gets tested, launched, and for a while everyone can see the data moving. The problem arrives later and usually not because of you: the other system is updated, a field format changes, a new mandatory field appears, or request limits tighten. Your integration was not told.

What happens next depends on one thing: whether anyone notices. A well-designed integration stops loudly — an error appears, a queue builds, somebody gets a signal. A poorly designed one carries on with partial information, and that surfaces two weeks later when somebody misses a batch of orders.

Five agreements worth making up front

• Who holds access on both sides, and what happens when a key expires. This is the most common reason integrations stop, and the most easily avoided.
• Who receives the fault signal. Not "there is a log" but a specific person or address that a message reaches.
• Who may change the field rules. If only the supplier can, every small change becomes an order.
• What to do when the other side announces a change. Who reads their notices? Usually the answer is nobody.
• How long data may disagree before it counts as a problem. Without that number you can neither monitor nor argue.

What a real handover looks like

Delivering code is not handover. Handover has happened when somebody on your side can answer four questions without the supplier: where to check whether transfers are working; what an error message means; how to retry a failed transfer; and what to do when a new field has to be added.

A practical test before signing acceptance: ask the supplier to deliberately break a transfer in a test environment and show you what that looks like from your side. If nobody sees anything, the integration has not been handed over, whatever the documents say.

What "monitoring" means when it is sold

Monitoring can mean three very different things, written identically in proposals. One: errors are written to a log somebody could read if they thought of it. Two: a fault sends a message to a specific person. Three: somebody is obliged to respond within an agreed time. The third is a service; the first two are a technical capability. It is worth asking which one is being bought.

Illustrative scenario, not a description of a client project

Imagine an integration between a shop and accounting that runs flawlessly for eight months. Then the accounting supplier updates its interface and one field starts coming back in a different shape. The integration cannot read it, so it skips those orders — and tells nobody, because that was never agreed. It surfaces ten days later through a discrepancy in the accounts. Technically the integration was built well; what was undefined was ownership. This is an example of how we judge scope, not a promise about uptime.

What to do if an integration already runs

• Find out who would notice a fault today. If there is no answer, that is the only work that matters this week.
• Check when access keys expire and who will renew them.
• Find the log and read it once — it frequently already contains errors nobody has seen.
• Write down the field rules if they live only in the supplier's head.
• Agree who will read the other side's change announcements.

None of these is technical work, which is precisely why they so often go undone. But they decide whether in a year the integration is a working piece of infrastructure or a quiet risk that gets remembered on the day of the incident.