---
id: KB-IN-020
url: https://app.codecontract.io/help/integrations/when-your-own-system-gets-updated
idioma: en
categoria: integraciones
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-008, KB-IN-016, KB-IN-018]
citadoPor: [KB-IN-005]
---

# When your own system gets updated

_You do not change programs: it just gets updated. And the integration keeps working, which is exactly what makes it dangerous._

**Responde a:** the erp was updated and the integration fails · version upgrade and changed fields · the integration runs but data is missing · warning the vendor before upgrading

Your IT team or your vendor updates the program over a weekend. On Monday everything works: people log in, orders go out, and the integration keeps sending data. That is why this problem takes weeks to surface, and by then it has polluted the record.

## How an integration breaks while still running

| What changed | What you see | What is really happening |
| --- | --- | --- |
| A field was renamed | Everything looks the same | That value arrives empty and nobody looks |
| A field changed format | The data comes in | It comes in wrong: different dates or amounts |
| A mandatory field was added | Some sends start failing | The good case: it shows |
| How a record is identified changed | Duplicates appear | Each send creates a new one instead of updating |

> [!IMPORTANT]
> The first two rows are dangerous for the same reason: **an integration does not warn about what it stops receiving**. If a field is renamed there is no error: there is a gap, and files keep being created with that value empty for weeks. When someone notices, you must decide whether to fill two hundred cases by hand. The noisy failure — the send that breaks — is actually the best case, because it is found the same day.

## What to do around an update

1. **Find out when it is happening, even if it «does not affect you»** — It is information that rarely reaches whoever owns the integration.
2. **Ask what changes in the data, not in the interface** — What matters to an integration is not in the release notes.
3. **Check one complete case the next day** — A real one, with its data, not a ping.
4. **And scrutinise that week's files** — That is where the gaps will show if there are any.

> [!WARNING]
> The check worth having in place before it happens: **one that looks at whether the value arrives, not whether the send responds**. The integration answering «received» says nothing about what was inside. A simple review — how many of the latest files have that field empty — catches in a day what otherwise surfaces when a client asks why a number is missing.

## If you are the one updating

**En corto**

- Tell whoever maintains each integration beforehand, not afterwards.
- Keep an example of how the data arrived before the update: that is your comparison.
- And if you can, update on a day when someone can look the next morning.

> [!NOTE]
> The same problem appears when the party at the other end updates without telling you. The difference is that you cannot plan for it — only detect it early, which is what the check above is for.

**Can I test the update somewhere first?**

Ask your IT team: if there is a test environment, this is when to use it.

**What if the gap is weeks old?**

Backfill what you can in bulk and record from when it was missing.

**Should the integration be frozen during the update?**

Pausing it briefly is cheaper than cleaning duplicates later.

## Ejemplos

**A company updates its ERP and three weeks later finds files with no order number.**

- Checks one complete case the next day and reviews how many arrive with the field empty

→ The gap surfaces in a day instead of across two hundred files needing review.

**The ERP is upgraded over a weekend and on Monday the integration is broken.**

- Asks IT for the upgrade calendar
- Tests the flow in the test environment before the switch

→ The upgrade is faced with the integration already verified.

**A field changes and the integration starts failing silently.**

- Sets an alert if activity stops arriving

→ The fault is caught in hours.

**It is upgraded and nobody tests anything.**

- Tests a real case straight afterwards

→ The problem is found before the users find it.

**The upgrade changes a data format.**

- Validates the format before writing

→ The bad value does not propagate.

**Unprocessed notifications pile up during the window.**

- Checks what is pending afterwards

→ The window does not leave a hole.