---
id: KB-IN-011
url: https://app.codecontract.io/help/integrations/what-to-ask-your-it-team-before-integrating
idioma: en
categoria: integraciones
audiencia: administrador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-006, KB-IN-002, KB-IN-017]
citadoPor: [KB-IN-012, KB-IN-013, KB-IN-019]
---

# What to ask your IT team before integrating

_Five questions that save three months of meetings and an integration nobody uses._

**Responde a:** preparing an integration with our erp · what do i need to integrate two systems · meeting it before an integration · integration readiness checklist

Most integrations that fail do not fail for technical reasons: they fail because nobody agreed beforehand what gets synced, in which direction, and who wins when the two systems disagree. That is settled in a half-hour conversation, not in code.

## The five questions

1. **Which data exactly, and in which direction?** — "Sync suppliers" is not an answer. "Tax ID, name and document status, from here to the ERP" is.
2. **Who wins if both change?** — The question almost nobody asks and the one behind every later mess.
3. **How often?** — Instantly, hourly or nightly. It changes the work and the cost.
4. **What happens when it fails?** — Because one day it will. Who finds out and what they do meanwhile.
5. **Who maintains it a year from now?** — If the answer is "whoever built it" and that person could leave, you have an open problem.

> [!IMPORTANT]
> The second is decisive. Without a clear rule on who wins, the first time the systems disagree someone will fix it by hand in both places, and from then on nobody trusts either.

## What to bring to that meeting

| Bring | What for |
| --- | --- |
| The concrete case, not "integrate" | An integration without a use case never finishes |
| Who suffers the manual work today | They will know whether the result is any good |
| How much time is lost now | The only way to know whether it pays |
| And the option of not integrating | Sometimes a monthly file export is enough |

> [!WARNING]
> The last row is not rhetorical. Many integrations are proposed to save work that happens twice a month; maintenance costs more than that work. Check before you start, not after.

## The three approaches, by effort

**En corto**

- Notifications to your system when something happens: fastest to set up.
- Queries from your system when it needs the data: fine-grained control.
- Two-way synchronisation: the most powerful and the most demanding.

> [!NOTE]
> Starting with the first and seeing whether it suffices is almost always the right call. You can extend later; unwinding a badly designed two-way sync is far more expensive.

**Do we need a developer?**

For the first, barely. For the third, yes and on an ongoing basis.

**How long does it take?**

The technical part, days. Agreeing what gets synced, as long as you take to decide.

**What if we have no IT team?**

Then manual export and import is probably the right answer.

## Ejemplos

**A company wants two-way supplier sync with its ERP.**

- Answers the five questions and finds it only needs document status flowing to the ERP
- Sets up one-way notifications

→ It ships in days instead of months, and maintenance does not hinge on one person.

**Integration is requested without knowing which fields are needed.**

- Brings the specific flow and the field list
- States what triggers what and how often

→ IT estimates on data rather than on an intention.

**IT asks about the upgrade calendar and nobody has checked it.**

- Checks when each system changes before starting

→ The integration is not born obsolete.

**It is built and nobody knows who maintains it.**

- Names an owner and a deputy from the start

→ The integration is not orphaned.

**There is no test environment and testing happens in production.**

- Asks for a separate environment for testing

→ Go-live does not pollute real data.

**Who does what is agreed verbally.**

- Writes the split down before starting

→ Later doubts are settled by reading.