Where two systems meet
Moving a message from one system to another is the easy part. The hard part is a disagreement about truth: which system owns the customer record, what happens when both sides edit it, and what "deleted" in one means in the other.
We settle those questions first, in writing, before a single message moves. Then we build the pipe, and the machinery that proves both sides still agree next month.
The actual problem
Your ERP holds a customer table. So does your e-commerce platform, your CRM, and a spreadsheet in accounting. Each one is authoritative to the people who use it. Until one system is named the system of record for each field, every sync is a guess about whose edit survives.
A rep corrects the billing address in one system while the customer updates it in the other. A naive sync keeps one edit and silently discards the other, and nobody notices until an invoice ships to the old address. That collision needs a written rule, decided by a person, not a default buried in a job.
One system hard-deletes the row. The other flags it inactive and keeps years of history against it. Replicate the delete literally and you destroy records you were supposed to keep. Deleted, cancelled and void mean different things in each system. The integration has to translate them, not copy them.
What we build
The pipe is the least of it. These are the pieces that make an integration trustworthy.
For every entity, and often for every field, one system is named the owner. The decision is written down where both teams can read it. When the sides disagree, the owner prevails, and the integration enforces that without a meeting.
Delivery is at-least-once. That is the contract, not the worst case, so a duplicate message will arrive. Every handler we write can process the same message twice and leave the data in the same state. A retry becomes safe, and a replay becomes a repair tool instead of an incident.
A job that compares both sides, row by row, and reports every mismatch with enough context to fix it. You run it after go-live, after an outage, and on a schedule. Drift is not a possibility, it is a certainty. The question is whether you find it before your customer does.
Failed messages do not vanish into a log file. Each one lands in a queue holding the payload, the error, and a retry path for after the fix. A named person reads that queue, and an empty queue means something.
.NET services, with Azure SQL holding integration state. When a screen needs to see a change the moment it lands, SignalR pushes it. The pipeline runs in Azure DevOps, and when the engagement ends, all of it is yours.
How the work runs
Many integrations start life as a nightly export and a prayer. The export is not the sin. Nobody watching it is. A batch job that fails silently on Friday makes for a long Monday, and we would rather you hear about the failure the moment it happens.
Start here
Name the systems, describe the record they fight over, and tell us what the disagreement cost you last time. We will tell you honestly whether it is a problem we should take.