Respuesta corta. Sí, NetSuite se integra con Dynamics 365 (Business Central o Finance & Operations) y con SAP (Business One, ECC o S/4HANA). La vía depende del producto de Microsoft o de SAP que usted tenga, de qué registros deben moverse y de quién es el dueño de cada registro. Un primer flujo en producción suele llevar semanas, no meses; un programa híbrido completo con varias sociedades lleva más.
Lo híbrido es una estrategia, no un fracaso
Pocos grupos eligen tener dos ERP. Les sucede. Un grupo en NetSuite compra una empresa que funciona con Dynamics 365 Business Central. Un entorno corporativo SAP escinde una unidad de negocio que pasa a NetSuite. Los servicios compartidos de finanzas se consolidan en un ERP mientras las operaciones locales mantienen el sistema que conoce sus almacenes, sus obligaciones legales y sus reglas fiscales.
Hay mucho material bueno sobre cómo migrar de Dynamics o SAP a NetSuite, y a veces migrar es la respuesta correcta. Pero una migración hecha con prisa, antes de entender el negocio adquirido, es la forma más segura de acabar con un ERP nuevo lleno de datos malos. Si la convivencia va a durar dos o tres años, trátela como el plan y construya bien el puente.
Eso no descarta un único ERP más adelante. Un puente bien diseñado facilita el corte definitivo, porque obliga a responder las mismas preguntas que una migración: qué sistema es el dueño del cliente, cómo se mapean las cuentas, qué códigos de artículo son reales. Cuando llegue ese día, la disciplina de la migración de datos es el proyecto sigue aplicando.
Qué suele tener que moverse entre los ERP
La primera decisión de diseño no es la herramienta. Es qué registros cruzan la frontera, en qué dirección y qué sistema tiene la última palabra sobre cada uno.
| Ámbito | Dirección habitual | Qué decide el diseño |
|---|---|---|
| Clientes y proveedores | Del ERP propietario al otro, rara vez en ambos sentidos | Un dueño por registro, una clave común y qué pasa cuando los dos lados editan el mismo campo |
| Artículos y precios | Desde el ERP que gestiona el catálogo | Mapeo de códigos de artículo, unidades de medida, qué atributos necesita de verdad el lado receptor |
| Pedidos de venta, pedidos de compra, facturas | De donde ocurre la transacción a donde se sirve o se contabiliza | Estados que vuelven, envíos parciales, abonos |
| Posiciones de inventario | Resúmenes, rara vez cada movimiento | Lo actualizada que debe estar la cifra y si basta una foto diaria |
| Operaciones intercompañía | Ambos lados, como asientos que casan | Que las dos patas coincidan en importe, moneda, fecha y contraparte |
| Plan de cuentas y dimensiones | Mapeo, no sincronización | Una tabla de correspondencias mantenida entre las cuentas locales y el plan del grupo; vea un plan de cuentas para varias filiales y monedas |
| Envíos de consolidación | Del ERP de la filial al ERP que consolida | Calendario de cierre, balance de sumas y saldos o nivel de asiento, tipos de cambio |
A veces también hay un CRM en medio: Salesforce enviando pedidos a ambos ERP, o custodiando el maestro de clientes. Eso cambia quién es el dueño del cliente, no la lógica anterior. Mantener un único registro de cliente coherente en dos sistemas es un problema en sí mismo, tratado en un registro de cliente, dos sistemas.
Dynamics 365 con NetSuite: Business Central y Finance & Operations
«Dynamics 365» designa dos ERP distintos, y la integración es diferente en cada uno.
Business Central es el que más vemos junto a NetSuite: una filial o una empresa adquirida trabaja con BC mientras el grupo trabaja con NetSuite, o al revés. Business Central expone una API REST estándar (v2.0). Un detalle importa para dimensionar el proyecto: la documentación de Microsoft indica que las API estándar no se pueden ampliar con campos adicionales; si necesita un campo personalizado, hay que copiar el código AL de la API y publicar una API propia (Microsoft Learn, API v2.0 de Business Central, consultado el 29 de septiembre de 2026). Cualquier personalización del lado de BC aparece, por tanto, en la estimación de la integración.
Finance & Operations (Finance, Supply Chain Management) es un sistema más grande con otra superficie. Las entidades de datos marcadas como públicas se exponen a través de un endpoint OData para crear, leer, actualizar y borrar (Microsoft Learn, OData, consultado el 29 de septiembre de 2026). Para escenarios por ficheros y cargas masivas, Microsoft ofrece la API de paquetes de Data management y la API de integraciones recurrentes (Microsoft Learn, Data management package REST API, consultado el 29 de septiembre de 2026). Cuál encaja depende del volumen y de los plazos, y por eso los proyectos con F&O empiezan por una fase de descubrimiento.
En cuanto a plataformas, Celigo indica que da soporte tanto a Business Central como a Finance & Supply Chain Management, y publica una plantilla de integración Business Central – NetSuite cuyos flujos incluidos son facturas de BC a facturas de NetSuite y cuentas de BC a clientes de NetSuite (Celigo, plantilla Business Central – NetSuite, consultado el 29 de septiembre de 2026). Es un punto de partida, no un diseño híbrido completo: artículos, pedidos, intercompañía y envíos de consolidación siguen siendo alcance que hay que definir.
¿Es MuleSoft excesivo aquí?
A menudo, sí. Si el alcance es un flujo acotado Business Central ↔ NetSuite o Business Central ↔ Salesforce y su grupo no usa ya MuleSoft, una plataforma empresarial orientada a API añade más peso operativo del que el problema necesita. Si MuleSoft ya es el estándar del grupo, con el equipo y el contrato en marcha, construir sobre él puede ser lo sensato, y se lo diremos. Ajuste el peso de la herramienta al paisaje. La versión larga de ese equilibrio está en nuestro marco de decisión Heroku Connect vs Celigo vs MuleSoft.
SAP con NetSuite: Business One, ECC y S/4HANA
SAP también son varios productos, y cada uno tiene una forma de integración distinta.
- SAP Business One es habitual en filiales más pequeñas. Suele integrarse a través de su Service Layer, una API web sobre los objetos de Business One, o de la DI API, más antigua.
- SAP ECC intercambia datos normalmente mediante IDocs, BAPI y RFC, a menudo detrás de un middleware que el grupo ya tiene.
- SAP S/4HANA añade un catálogo publicado de API OData y SOAP, recogido en el SAP Business Accelerator Hub (consultado el 29 de septiembre de 2026).
Lo que no hacemos es presentarnos como partner de SAP. No lo somos. Nuestro punto fuerte es el lado de NetSuite (registros, filiales, intercompañía, SuiteScript, los servicios web REST y SOAP) y la propia capa de integración. En el lado de SAP trabajamos con su equipo o su partner de SAP, contra interfaces que ellos exponen y mantienen. Cuando un entorno SAP no tiene una interfaz estable para los datos que usted necesita, se lo decimos antes de empezar el proyecto, no en la sexta semana.
Aquí hay menos integraciones prediseñadas que para Business Central. La página de SAP de Celigo recoge integraciones como SAP Business Network – NetSuite y Loop Returns – SAP Business One (Celigo, integración con SAP, consultado el 29 de septiembre de 2026), no un flujo empaquetado ERP de SAP ↔ NetSuite. Cuente con que los flujos NetSuite ↔ ERP de SAP se construyan sobre los conectores genéricos de la plataforma o se escriban contra las API.
Cuatro formas de construir el puente
Construimos integraciones de cuatro formas, y la elección depende del caso: el volumen, la latencia que de verdad necesita, si los datos pueden salir de su infraestructura y qué mantendrá su equipo después (nuestro enfoque de integración).
| Vía | Encaja en un puente de ERP híbrido cuando | Cuidado con |
|---|---|---|
| Celigo (iPaaS) | Quiere conectores respaldados por el fabricante y monitorización para flujos de ERP programados o por eventos | Las plantillas cubren una parte; el resto se configura encima |
| n8n (orquestación) | El proceso tiene pasos, ramas y aprobaciones entre varios sistemas, o debe ejecutarse en su propia infraestructura | Orquesta; no es un motor de sincronización de datos |
| A medida, contra las API | Ninguna plataforma encaja, o no quiere una licencia de terceros en medio | El código es suyo, así que la documentación y la monitorización deben entregarse con él |
| Stacksync (sincronización en tiempo real) | Un CRM o una base de datos necesita sincronización bidireccional por debajo del segundo junto a los ERP | Suele ser secundario en un puente entre ERP |
Si su grupo ya tiene un iPaaS empresarial como MuleSoft o Boomi, la comparación se hace a nivel de capacidades: cobertura de conectores para su producto concreto de Dynamics o SAP, cómo se muestran y se reintentan los errores, quién de su equipo puede cambiar un mapeo y cuánto cuesta operarlo. No puntuamos plataformas que no vamos a implantar para usted. Para el equilibrio general entre plataformas, código punto a punto y middleware, vea iPaaS, punto a punto o middleware.
Un matiz sobre el «tiempo real»: no todos los objetos del ERP lo necesitan, ni todas las vías lo ofrecen. Los cambios en clientes y artículos pueden ir a menudo por eventos; los envíos de consolidación siguen normalmente el calendario de cierre; el inventario suele funcionar bien como resumen programado. Indicamos la latencia por flujo, no por proyecto.
Gobierno: fuente de verdad, conflictos y corte
Las integraciones híbridas fallan más por gobierno que por código. Antes de construir, acordamos y dejamos por escrito:
- Un dueño por tipo de registro. Los maestros de clientes, proveedores y artículos tienen cada uno su sistema de referencia. El otro lado recibe una copia, y las ediciones allí se bloquean o se devuelven al origen.
- Reglas de conflicto. Qué pasa cuando los dos ERP cambian el mismo campo en la misma ventana: qué lado gana y a quién se avisa.
- Réplica de solo lectura o doble escritura. Una copia de solo lectura es más sencilla y más segura. Escribir desde ambos lados a veces es necesario, y entonces cada flujo necesita idempotencia y un informe de conciliación.
- Tablas de mapeo con responsable. Cuentas, dimensiones, códigos de impuesto, unidades de medida y sociedades viven en tablas mantenidas, no dentro de la lógica de los flujos.
- Monitorización desde el primer día. La gestión de errores, los reintentos y las alertas se entregan con el primer flujo, y alguien de su lado los ve.
- Un plan de retirada. Si uno de los ERP debe desaparecer, cada flujo tiene fecha de fin y un paso de corte, y el puente mantiene limpios los datos maestros para ese día.
El go-live no es el final. Las integraciones necesitan a alguien que las vigile mientras los ERP siguen cambiando a su alrededor, que es de lo que trata la vida después del go-live.
Forma del proyecto y por qué Atypical
Un proyecto típico sigue este orden:
- Descubrimiento. Qué producto de Dynamics o SAP, qué entidades, interfaces actuales, reglas de propiedad y volúmenes.
- Vía y diseño. Celigo, n8n, a medida o una combinación, con las decisiones de gobierno anteriores por escrito.
- Primer flujo en producción. Normalmente datos maestros o facturas, en producción en semanas, no en meses.
- Ampliación. Pedidos, intercompañía, envíos de consolidación, en el orden que elimine más trabajo manual.
- Operación. Monitorización, reintentos, alertas y cambios a medida que evolucionan ambos ERP, operados por nosotros o entregados a su equipo con documentación.
Somos ingenieros de integración en todo el stack que usan de verdad los grupos europeos del mid-market, no un implantador de NetSuite que intenta sustituir su otro ERP. Somos partner de implantación de Celigo y partner de Stacksync, construimos directamente contra las API cuando ninguna plataforma encaja y trabajamos desde España en inglés, español, portugués y catalán. Hay más sobre el equipo en quiénes somos.