Integrations
When you change ERP or provider
What breaks without warning the day another system changes, and in what order to check it.
Integrations are built once and forgotten, which is exactly what you want from them. The problem appears when **the other side** changes: a new ERP, a different email provider, a domain migration. Nobody tells the integration, and it fails silently.
What breaks and how you notice
| Change on your side | What stops working | How you notice |
|---|---|---|
| New ERP | Notifications keep going to an endpoint that no longer listens | You do not: that is why you must look |
| Different email provider | Your own sender stops being verified | Emails start going out from the platform sender |
| Domain change | Sending DNS records and custom-domain QRs | Worse deliverability, sometimes broken links |
| Key rotation | Integrations using the previous key | Clear failures, and the easiest of all |
Important
The first row is the dangerous one because it **fails upstream**: the platform keeps sending correctly and it is the destination that no longer picks it up. From here everything looks fine; the gap only appears when someone misses a value in the ERP, weeks later. If you change the receiving system, that integration is reviewed the same day, not when someone complains.
The order to review them
- 1
List what integrations exist and what for
If nobody can enumerate them, that is the first problem, not the ERP change.
- 2
Start with those going outward
They are the ones that fail without noise.
- 3
Check sender and domain
Verifications and DNS records survive migrations badly.
- 4
And revoke the old system's keys
A key for an ERP you no longer run is a live access with no owner.
Watch out
Step four is always forgotten and is the most awkward in an audit: keys issued for a system the company no longer has, still active years later. It is not a theoretical risk — it is an access nobody is watching because nobody remembers it exists.
What to leave in place for next time
The "not annually" matters: integrations do not degrade with time, they break with changes. The right trigger is the change, not the calendar.
Worth knowing
If the integration was built by an outside firm you no longer work with, review it anyway: what you need to know is not how it was made, but what keeps going out and with which credential.
›How do I know an integration still works?
By what arrives on the other side: if the destination does not pick it up, you cannot see it here.
›What if the new ERP does not support the same thing?
Go back to which data and in which direction: it is nearly always less than what was built.
›Do we have to redo the custom sender?
If the email provider or the domain changes, yes: verification belongs to that domain.
A real case
The situation
A company migrates ERP and three months later misses data it believed was syncing.
What you do
- Reviews outbound integrations on the day of the change
- Revokes the old system's keys
What you get
The three-month gap does not recur and a live ownerless access disappears.
The situation
The ERP changes and the integration stops working the same day.
What you do
- Builds the new integration before switching the old one off
- Verifies with real cases during the overlap
What you get
The ERP change does not cut the flow of files.
The situation
Nobody knows which fields the previous integration fed.
What you do
- Documents the flow before dismantling it
What you get
The new integration covers the same ground.
The situation
The old system is switched off with unprocessed notifications.
What you do
- Checks what is pending before switching off
What you get
Nothing is lost along the way.
The situation
The new provider promises the same and does not deliver.
What you do
- Tests the real flow before signing
What you get
The promise is verified before you depend on it.
The situation
The old system's key stays active months later.
What you do
- Revokes the keys on dismantling
What you get
Access does not stay open.
This article answers
- we are changing erp what happens to the integration
- migrating systems without breaking connections
- changing email provider integrations
- reviewing integrations after a migration