Pitfalls one to three: ownership, identifiers and duplicates
First, unclear ownership: if both systems can edit the same field, one will overwrite the other. Decide a single owner for every shared field. Second, no shared identifier: matching customers by name produces duplicates and mismatches, so store a unique key from each system on the other's record. Third, duplicate creation: a customer created in both systems at once, or twice by retries, damages reporting. Add matching rules before create operations and make retries safe to repeat.
- Write a field-by-field ownership table.
- Store cross-system IDs on both sides.
- Make create operations idempotent so a retry does not create a second record.
Pitfalls four to six: scope, timing and platform limits
Fourth, scope creep: trying to integrate every object at once delays delivery. Start with the flow that matters most, usually customers and orders. Fifth, unrealistic timing: real-time sync sounds attractive but is not always needed, and it increases complexity and load. Choose the timing the business needs. Sixth, platform limits: both systems restrict the number of calls and the volume processed in a period. Design for peak volume and test with realistic loads.
Pitfalls seven to eight: errors and monitoring
Seventh, silent failures: records that fail to sync vanish unless someone is told. Build an error queue where a named person sees failed items, the reason, and a way to retry. Eighth, no monitoring: without dashboards and alerts, the first sign of trouble is a customer calling about an order that never arrived. Track counts sent and received, error rates, and delays, and review them regularly.
Managed and advisory services →Pitfalls nine and ten: testing and support
Ninth, thin testing: integrations that pass with five clean test records fail on messy production data. Test with realistic volumes, odd characters, missing fields, and cancellations and amendments. Tenth, no support owner: when the integration fails at month-end, who responds? Name the team and agree response expectations before go-live, ideally within a support agreement that covers both systems.
Implementation and integration services →Choosing the architecture to suit your situation
Prebuilt connectors suit standard processes and small teams. Integration platforms suit organizations with several systems and a need for monitoring and reuse. Custom code gives control but demands engineering ownership. Match the approach to your complexity and your ability to support it, rather than to what is fashionable. Review the choice when your needs change. Whatever you choose, keep the interface documented, with sample messages and a simple diagram, so a new engineer can understand it in an afternoon, and keep credentials and configuration out of individual people's accounts.
Decisions to settle before you build
- Ownership table. Decide who owns each field and what happens on conflict.
- Critical flow first. Pick the one flow that delivers most value and design it well.
- Error ownership. Name who watches the error queue and how quickly they act.
- Test data. Prepare a realistic test set including the ugly cases.
A realistic first 90 days
- Days 1 to 30. Create the ownership table, choose identifiers and matching rules, and select the approach.
- Days 31 to 60. Build and test the first flow with realistic data and failure scenarios.
- Days 61 to 90. Add monitoring and the error queue, go live with the first flow, and plan the next.
A short pre-launch review
- Ownership documented? Every shared field has a single owner.
- Identifiers stored? Each system holds the other's unique key.
- Failures visible? Someone is alerted and can retry failed records.
- Support agreed? A named team will respond when it breaks.
