Integration that keeps systems in step

• Scheduled syncs that move only what changed, so running one again is safe.
• API integrations over REST, SOAP and OData, inside the vendor's rate limits.
• File feeds over SFTP for systems that only speak in exports.
• Event-driven flows from webhooks, where the source supports them.

• Idempotent loads: running the same batch twice changes nothing.
• Retries with back-off, then an error queue that holds the record and the reason, not a stack trace.
• Logs that name the record, not just the batch.
• Alerts when volumes look wrong, not only when a job fails outright.

• Which system owns each field, so two systems never overwrite each other.
• How quickly a change has to arrive: seconds, hourly or overnight. Faster costs more to run and to support.
• What identifies a record on both sides, and what happens when one side has no match.
• What a person is told when something fails, and who that person is.
• How much history the first run carries over, and whether that is better done as a one-off migration.

• Someone re-keys the same data into two systems every week.
• A nightly export that has to be checked by hand before anyone trusts it.
• Duplicates appearing in one system after a change in the other.
• An integration nobody can explain, because the person who built it has left.

The extraction routes we use for migrations work for integrations too: reading the database, parsing the exports, or using the calls the application makes to its own back end. Where a system can only be read, we say so up front and design around it.

Compare the extraction routes

• An interface specification: what moves, when, in which direction, and what happens when it fails.
• Integration code, deployed and documented.
• Monitoring and alerting wired to whoever needs to know.
• A runbook your team can follow without us.