---
id: KB-IN-016
url: https://app.codecontract.io/help/integrations/when-you-change-erp-or-provider
idioma: en
categoria: integraciones
audiencia: administrador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-008, KB-IN-003]
citadoPor: [KB-IN-020]
---

# When you change ERP or provider

_What breaks without warning the day another system changes, and in what order to check it._

**Responde a:** we are changing erp what happens to the integration · migrating systems without breaking connections · changing email provider integrations · reviewing integrations after a migration

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.

> [!WARNING]
> 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

**En corto**

- One key per integration, so you can revoke without breaking the rest.
- A note of which integration uses which key and who requested it.
- And a review whenever a connected system changes, not annually.

The "not annually" matters: integrations do not degrade with time, they break with changes. The right trigger is the change, not the calendar.

> [!NOTE]
> 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.

## Ejemplos

**A company migrates ERP and three months later misses data it believed was syncing.**

- Reviews outbound integrations on the day of the change
- Revokes the old system's keys

→ The three-month gap does not recur and a live ownerless access disappears.

**The ERP changes and the integration stops working the same day.**

- Builds the new integration before switching the old one off
- Verifies with real cases during the overlap

→ The ERP change does not cut the flow of files.

**Nobody knows which fields the previous integration fed.**

- Documents the flow before dismantling it

→ The new integration covers the same ground.

**The old system is switched off with unprocessed notifications.**

- Checks what is pending before switching off

→ Nothing is lost along the way.

**The new provider promises the same and does not deliver.**

- Tests the real flow before signing

→ The promise is verified before you depend on it.

**The old system's key stays active months later.**

- Revokes the keys on dismantling

→ Access does not stay open.