En este paso decides cómo se conecta cada flujo de tu mapa: conector nativo, iPaaS o middleware a medida. La regla corta: nativo si alcanza, iPaaS si hay que orquestar con lógica ligera, middleware si hay que transformar en serio o el volumen aprieta. Y la decisión es por flujo, no una religión para todo el stack.

Conector nativo: la primera opción, no la última

Son las integraciones de marketplace: instalas, autorizas, mapeas campos y listo. El marketplace de HubSpot supera las 1.500 apps; Shopify y VTEX tienen ecosistemas similares. Sus ventajas son reales: se configuran en horas, el proveedor las mantiene cuando cambia la API, y el costo es predecible (gratis o una suscripción menor).

Sus límites también son reales: mapean los campos estándar y poco más, la lógica de transformación es mínima, y cuando algo falla el log suele ser una caja negra. Usalo cuando el flujo mueve entidades estándar (contactos, pedidos), el volumen es moderado y no necesitas transformar el dato en el camino. Probalo antes de descartarlo: el error más caro es construir a medida lo que un conector de 50 dólares al mes ya resolvía.

iPaaS: orquestar sin construir

Workato, Make, Zapier, n8n. Plataformas donde armas flujos multi-paso con lógica condicional sin escribir (casi) código: "cuando entra un pedido en VTEX, busca el cliente en HubSpot, si no existe crealo, avisa por WhatsApp si supera los 500 dólares".

El punto fuerte: velocidad y autonomía. Tu equipo de operaciones puede mantener los flujos sin depender de un desarrollador. El punto débil: el precio escala por tarea ejecutada, y eso muerde. Un flujo de 3 pasos sobre 20.000 pedidos mensuales son 60.000 tareas al mes: haz la cuenta contra el plan que te cotizaron antes de firmar. Para volúmenes de miles de eventos diarios, el iPaaS suele terminar costando más que un middleware amortizado.

Middleware a medida: control total, responsabilidad total

Un servicio propio —típicamente Node o Python con colas— que se sienta entre los sistemas y hace exactamente lo que tu operación necesita. Es la opción correcta cuando:

• El sistema no tiene conector ni buen soporte de iPaaS. El caso clásico en LATAM: ERPs locales tipo Softland o instalaciones on-premise de SAP Business One.
• Hay transformaciones pesadas: reglas fiscales por país, consolidación de catálogos, lógica de negocio que no cabe en un "if" visual.
• El volumen es alto y sostenido, y pagar por tarea deja de tener sentido.
• Necesitas garantías: colas, reintentos, idempotencia y trazabilidad completa (los pasos 6 y 7 de esta guía).

El costo honesto: de 6 a 12 semanas de construcción con QA incluido, más mantenimiento permanente. Alguien tiene que ser dueño de ese código. Si tu proveedor desaparece y nadie más puede tocarlo, no comprases una integración: comprases una dependencia.

La matriz de decisión, flujo por flujo

Toma el mapa del paso 1 y responde cinco preguntas por cada flecha:

• ¿Existe un conector nativo que cubra tus campos y volúmenes? (Probalo con datos reales, no con la demo.)
• ¿Cuántos registros por mes va a mover este flujo dentro de 12 meses, no hoy?
• ¿Cuánta transformación hay entre origen y destino: mapeo directo, lógica ligera o reglas de negocio?
• ¿Cuánto cuesta cada opción a 12 meses, incluyendo licencias, construcción y mantenimiento?
• ¿Quién lo mantiene cuando cambie la API o el proceso?

El patrón no se elige por moda: se elige por flujo. Un stack sano casi siempre termina siendo mixto —nativo donde alcanza, iPaaS donde orquesta, middleware donde duele.

Un resultado típico para una empresa con ecommerce, CRM y ERP: conector nativo entre tienda y CRM, un flujo de iPaaS para notificaciones internas, y middleware para el ERP. Tres patrones, cero dogma.

Errores comunes en este paso

• Elegir un solo patrón para todo. "Todo con Zapier" o "todo a medida" garantiza pagar de más en la mitad de los flujos.
• Subestimar el costo por tarea del iPaaS. El plan de entrada aguanta el piloto; el volumen real de fin de año lo revienta. Proyecta a 12 meses con crecimiento.
• Construir middleware para lo que un nativo resuelve. Semanas de desarrollo para replicar un conector existente es el clásico de los equipos técnicos con hambre.
• Ignorar quién mantiene después del go-live. Toda integración cambia: APIs que se deprecian, procesos que evolucionan. Sin dueño, se pudre.

Checklist antes de pasar al siguiente

• Cada flujo del mapa tiene un patrón asignado y justificado.
• Costo proyectado a 12 meses por flujo, con el crecimiento esperado de volumen.
• Conectores nativos candidatos probados con datos reales, no descartados por prejuicio.
• Límites de API verificados en ambos extremos de cada flujo.
• Responsable de mantenimiento definido para cada patrón elegido.

Con el patrón decidido, toca la parte que casi todos se saltan y casi todos lamentan: paso 3, modelado y mapeo campo a campo. El índice completo está en la guía de integración de datos.