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.