When enterprise integrations fail, they rarely fail cleanly.

We inherited a system syncing financial data between a property development platform and our database. On paper, it “worked”. In reality, it was quietly dropping records and skipping certain transaction types.

This is the worst kind of failure: no outage, no alert, just silent data loss over time.

The bigger problem: there was no architecture or process documentation explaining how the sync worked — or was supposed to work.

Diagnosing issues became detective work. Following whispers of clues in a Cosmos database or an Azure Function log. The answers were buried in the code and effectively owned by no one.

We made a deliberate call: rebuild the integration from scratch.

Not because it was easier — it wasn’t. But because patching it meant accepting an ongoing risk we couldn’t see or control.

What we got instead:

  • Predictable, testable data flows
  • Proper logging and visibility when things go wrong
  • A system the team actually understands and can support

In regulated environments, this tradeoff matters.

“Mostly working” integrations don’t stay mostly working. They accumulate risk quietly until it becomes a real problem.

Sometimes the responsible decision isn’t fixing legacy behaviour. It’s replacing it with something you can actually trust.

“If you can’t explain how your integration works, you don’t have an integration — you have a liability.”