For systems that should already agree, but do not
Data Integration
Two systems holding the same customer record will drift apart the moment nobody builds a contract between them, and every workaround after that gets more manual. This practice builds the sync layer connecting live tools, whether the gap is a missing API, a batch delay, or master data quietly diverging.
How systems stay in sync without a person in the loop
API contracts, event streams and the conflict rules that keep two tools agreeing.
90 secSample frame · video pending01Before any sync is built
Real-time sync is a commitment, not a default.
Building event-based sync for a report that runs once a month is over-engineering, and tolerating a day of lag on billing data is a real risk. Four questions decide which approach actually fits a given system pair.
How much lag can this data actually tolerate?
A dashboard refreshed nightly may be fine. A support agent looking at stale account status is a genuine problem.
Which system should win when records disagree?
Sync without a conflict rule just moves the disagreement faster. That rule has to exist before any code does.
How many systems will eventually need this record?
A sync built for two systems rarely survives a third arriving unplanned. Design for the likely count, not just today's.
What happens when a sync fails partway through?
Partial failure between two systems is where data quietly diverges. The retry and reconciliation logic matters as much as the happy path.
| Batch export | Real-time sync | |
|---|---|---|
| Freshness | Hours to a day behind | Minutes or less |
| Build complexity | Lower, simpler to reason about | Higher, needs conflict handling |
| Failure visibility | Often noticed downstream | Alerted close to the source |
| Cost to add a system | Rises with each new export | Stabilises after the first few |
| Right for | Reporting and analysis | Operational, customer-facing data |
02Agreed before any code
The ledger that keeps the build honest
Every integration engagement fixes the split before work starts: what you bring, what we build, what comes back, and what never leaves your control regardless of scope.
- Your side
You bring
- The two systems and the record types they both hold
- Whatever manual export or copy-paste bridges them today
- The business rules for which system should win a conflict
- Our side
We build
- An API or event-based sync contract between the systems
- Conflict rules encoded so one source of truth wins
- Error handling for records that fail to sync cleanly
- Your side
You receive
- Records that update in both systems without manual copying
- A sync contract your engineers can extend to a third tool
- A log of every sync failure and how it resolved
Never leaves you
- Which system is authoritative for which field
- Business rules for handling a genuine data conflict
- Approval before a new system joins the sync
Where the line sitsBuilding the sync mechanism is ours to run. Deciding which system's record wins a conflict is a business call that stays with you.
03From two systems to one contract
Four stages, each closing on an artefact
Integrations fail quietly when the conflict rule was never written down before launch. Each stage in this process closes on evidence a stakeholder can check directly.
Define the sync contract
Which system owns which field, and what happens on a conflict, are decided and documented before any connection is built.
A contract with rules attachedBuild the sync mechanism
API calls or event consumers are built against the contract, with retry logic for the failures that will inevitably happen.
A working connection between systemsProve the failure paths
Partial failures, duplicate events and out-of-order updates are tested deliberately, because these are where real drift begins.
A tested response to failureHand over the sync operation
Monitoring, the contract documentation and the conflict rules move to your team, so adding a third system does not require us.
A system your team can extend
04What actually drives the number
Four drivers, not a flat rate card
Integration work is priced against the assessment, not a template, because these four factors change the effort by multiples.
Quality of the APIs already available
A well-documented API costs far less to integrate against than a system with no API at all.
Number of systems joining the sync
Connecting two systems is simple. A third or fourth multiplies the conflict rules that need deciding.
Freshness the business actually requires
Batch sync is cheaper to build. Real-time event streams need infrastructure most teams underestimate.
How much master data has already drifted
Reconciling years of divergence costs more than syncing systems that started clean and stayed close.
05Evidence and proof
Systems that stayed in sync long after handover.
Integration proof is systems that still agree months later, not a demo that worked once. Every record here waits for written client approval before production.
Explore case studiesA ledger and a CRM finally agreed on one customer.
Vela Ledger's billing platform and CRM held slightly different versions of every account. An event-based sync contract ended the manual reconciliation between the two.
- Manual reconciliation hours
- Removed entirely
- Record disagreements found monthly
- Down to near zero
Shipment status updates dropped from a day to minutes.
Orra Systems relied on a nightly export between warehouse and dispatch tools. An event stream replaced it, giving dispatch near-current shipment status.
- Update latency
- A day down to minutes
- Dropped or duplicate events
- Caught before dispatch
We stopped emailing spreadsheets to reconcile accounts. The two systems just agree now, and I no longer think about it.
Sample · pending client approval
06Read this first
When an integration build is the wrong spend
Selling real-time sync to a team that checks a report once a month would cost more than it earns us in trust. The exits are marked before the pitch. When the build is justified, it runs on REST or event streaming infrastructure, with a schema registry keeping every contract honest.
- Data migration
You are moving data once, not syncing it ongoing
A one-time migration needs a different plan than a live, continuous sync contract does.
- Data engineering
The need is analysis, not live operational sync
Feeding a warehouse for reporting is pipeline work, not a real-time integration problem.
Your engineers should own this build directly
If your team understands the systems and just needs capacity, extending it internally is the faster route.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The systems and contract are settled | Conflict rules and priorities | Sync delivery |
| Delivery pod | More systems will join over time | Roadmap decisions each cycle | Engineering, testing, releases |
| Team extension | Your leads already run delivery well | Architecture and standards | Named engineers and continuity |
07Straight answers
Asked before an integration budget commits.
01How is integration different from a data migration?
Integration keeps two live systems continuously in sync through an ongoing contract. Migration moves data once from an old system to a new one, after which the old system is usually retired. The two projects share techniques but solve different problems.
02Do you build custom connectors or use existing tools?
Both, chosen against the systems involved. Well-supported platforms often have a solid existing connector worth building on, while less common or internal systems usually need a custom API or event integration built from scratch.
03What happens when the two systems disagree?
A conflict rule decided during the design phase determines which system wins, and every conflict is logged so patterns of disagreement surface rather than repeat silently. The business, not the code, decides the rule itself.
04Can you integrate systems that have no API?
Sometimes, through database-level sync or scheduled exports where a true API genuinely does not exist. This is treated as a fallback, since it tends to be more fragile than an API-based contract.
05How do you handle sync failures in production?
With retry logic, alerting and a clear log of what failed and why. A sync that fails silently is the actual risk, so visibility into failure is built in from the first version, not added later.
06What does an integration engagement cost?
Scoped builds are priced against how many systems are joining, how good their APIs already are, and how much master data has already drifted. Ongoing monitoring runs as a smaller monthly commitment.
07Will our team be able to add a third system later?
Yes, by design. The sync contract and its documentation move to your engineers at handover, so extending it to a new system does not require bringing us back in.