ERP integrations that survive the next vendor release
Every integration works on the day it ships. The ones still working two years later share four design decisions.
Key takeaways
- Own an anti-corruption layer so a vendor field rename cannot reach your domain model.
- Make every write idempotent and every job replayable from a stored payload.
- Alert on business outcomes, not on HTTP status codes.
What makes an ERP integration durable?
Four things: an anti-corruption layer that keeps vendor shapes out of your domain model, idempotent writes keyed on business identifiers, stored raw payloads so any window can be replayed, and alerting on business outcomes rather than transport errors.
Never let a vendor field name into your domain
The fastest way to make an integration fragile is to let the vendor payload flow straight through the application. When CustName becomes CustomerName in a minor release, the change lands in forty files.
One adapter, one mapping, one place to change. It looks like ceremony on day one and it is the reason the integration is still running after the third vendor upgrade.
Idempotency is what makes retries safe
Networks fail mid-write. Queues redeliver. Someone reruns yesterday's job. Any of those creates duplicate orders unless every write is keyed on a business identifier the ERP also understands.
With idempotency in place, the recovery procedure for most incidents becomes replay the window, which takes minutes. Without it, recovery is a reconciliation spreadsheet and a difficult conversation with finance.
The four decisions, and what each one buys
| Decision | Buys you |
|---|---|
| Anti-corruption layer | Vendor changes stay a one-file edit |
| Idempotent writes | Safe retries and safe replays |
| Stored raw payloads | Reprocessing without asking the vendor |
| Outcome-based alerts | Alerts people still read after a month |
Reconcile on a schedule, not on suspicion
A nightly reconciliation that counts records on both sides and reports the delta is unglamorous and catches the slow divergence that no alert notices — the one record type that stopped syncing three weeks ago.
It is a day of work and it is the difference between finding a gap yourself and having a customer find it for you.
Version the contract you control
You cannot version the vendor's API, but you can version your own boundary. The adapter that translates their payload into your domain types is code you own, and treating it as a published contract inside your organisation changes how safely it can evolve.
In practice that means the mapping has tests built from real captured payloads, a changelog, and an owner. When the vendor ships a breaking change, the work is scoped to one module with a test suite that already describes the expected behaviour.
It also makes vendor migration thinkable. Two of the integrations we run have survived a change of upstream system entirely, because the application never knew which vendor it was talking to. That was not foresight about the specific change; it was the ordinary benefit of not letting someone else's schema into the domain.
FAQFAQ
Frequently asked questions
About the author
Sofia runs delivery across engineering engagements — discovery, estimation, increments and handover. She writes about migrations, pricing models and the undocumented business logic that turns a clean estimate into an overrun.
- Enterprise migrations
- Project estimation
- Delivery management
- CRM and ERP systems
