Tienes Dynamics 365 implementado. También tienes un ERP de hace quince años, un WMS propietario y una base de datos SQL que nadie se atreve a tocar. La pregunta no es si puedes conectarlos — es cómo hacerlo sin montar un proceso ETL manual que se rompa cada vez que alguien cambia un campo. La integración de datos en tiempo real entre Dynamics 365 y sistemas legacy es uno de los retos más frecuentes en proyectos de transformación digital en LATAM, y también uno de los que más proyectos paraliza cuando se aborda sin arquitectura clara. Conectar plataformas modernas con sistemas heredados exige decisiones de arquitectura que van mucho más allá de escribir un script de sincronización. Una integración de datos mal planificada puede costar más en mantenimiento que el sistema legado que se intenta reemplazar.
Por qué el ETL manual ya no es una opción viable
Durante años, el modelo estándar fue extraer datos del sistema A, transformarlos en un script, cargarlos en el sistema B. Funcionaba cuando los procesos eran lentos y los datos no necesitaban llegar en minutos. La integración de datos basada en ETL nocturno era suficiente en ese contexto. Hoy, ese esquema tiene tres problemas críticos.
Primero, la latencia es incompatible con decisiones en tiempo real. Un proceso ETL nocturno significa que tu equipo de ventas trabaja con stock de ayer. Segundo, el mantenimiento de scripts personalizados se convierte en deuda técnica acumulada: cada cambio de esquema en el sistema legado rompe el pipeline de integración de datos. Tercero, la trazabilidad es casi nula — cuando falla, nadie sabe exactamente qué registro no se sincronizó ni cuándo.
La sincronización moderna no elimina la transformación; la desplaza a una capa gestionada, monitorizada y recuperable. Un pipeline de integración de datos bien diseñado convierte cada flujo en un activo mantenible, no en una carga técnica.
El mapa del ecosistema: qué tienes disponible en Dynamics 365
Antes de elegir un patrón de conexión, conviene entender qué expone Dynamics 365 de forma nativa. La plataforma ofrece tres superficies principales que determinan el punto de entrada para cualquier arquitectura híbrida de integración de datos.
OData Web API y Dataverse
La OData Web API es la interfaz RESTful estándar de Dynamics 365 Customer Engagement y Dataverse. Permite operaciones CRUD completas sobre entidades, consultas filtradas y expansión de relaciones. Para flujos inbound — cuando un sistema externo necesita crear o actualizar registros en D365 — es el punto de entrada más directo para cualquier proceso de integración de datos.
Dataverse actúa como la capa de datos unificada que subyace a todas las aplicaciones de Dynamics 365. Cualquier dato que llegue a Dataverse está disponible automáticamente para Power BI, Power Apps y Copilot, lo que convierte cada pipeline de integración de datos en una inversión con retorno múltiple.
Webhooks y plugins para eventos outbound
Cuando el flujo es inverso — D365 necesita notificar a un sistema externo — los webhooks nativos permiten publicar eventos en tiempo real hacia cualquier endpoint HTTP. Un cambio en un pedido, una actualización de inventario o una modificación de cliente dispara automáticamente una llamada al sistema receptor, completando el ciclo de integración de datos sin intervención manual.
Los plugins de Dynamics 365 permiten lógica de transformación antes de que el evento salga. Este patrón outbound basado en eventos es el que mejor elimina la necesidad de polling periódico — y con él, la mayor fuente de latencia en arquitecturas legacy de integración de datos.
Dual-write para escenarios Finance & Operations
Para empresas que operan tanto Dynamics 365 Finance & Operations como aplicaciones de Customer Engagement, dual-write ofrece sincronización bidireccional casi en tiempo real entre ambas capas sin código adicional. Su uso debe limitarse a ese escenario específico de integración de datos: forzarlo como puente hacia sistemas externos añade complejidad sin beneficio real.
Tabla comparativa: los tres patrones de integración
Esta matriz resume las variables clave para elegir el patrón correcto de integración de datos según tu contexto. La decisión no es técnica en primer lugar — es de negocio: qué latencia tolera el proceso, qué volumen maneja y qué capacidad tiene el equipo para mantener la solución.
| Patrón | Latencia | Volumen | ¿Requiere API en legado? | Coste relativo | Complejidad de mantenimiento |
|---|---|---|---|---|---|
| API directa con adaptador | Mínima (<1 s) | Bajo-medio | Sí (REST o SOAP) | Bajo | Media (acoplamiento directo) |
| Middleware (Logic Apps / Power Automate) | 1 s – 15 min | Medio-alto | Opcional (conectores preconstruidos) | Medio | Baja (orquestación visual) |
| Change Data Capture (CDC) | Casi real (<60 s) | Alto | No (lee log de BD) | Medio-alto | Alta (requiere acceso a BD) |
Los tres patrones que funcionan en producción
La elección del patrón correcto de integración de datos depende de tres variables: latencia requerida, volumen de registros y capacidades del sistema legado. No existe un patrón universal — existe el adecuado para cada caso.
Patrón 1: API directa con adaptador
Cuando el sistema legado puede exponer o consumir una API REST o SOAP, la solución más limpia para la integración de datos es un adaptador ligero que traduce el contrato del legado al formato OData de Dynamics 365. No hay intermediario adicional, la latencia es mínima y el control es total.
El riesgo es el acoplamiento: si el sistema legado cambia su contrato, el adaptador necesita actualización. Por eso este enfoque de integración de datos funciona mejor cuando el sistema legado es estable o está bajo control del equipo interno.
Patrón 2: Middleware con Azure Logic Apps o Power Automate
Este es el patrón más común en implementaciones medianas de integración de datos. Azure Logic Apps actúa como orquestador: recibe eventos de D365 o del sistema legado, aplica transformaciones, maneja reintentos y enruta hacia el destino correcto. Power Automate cubre casos de menor volumen con una curva de aprendizaje más accesible.
La ventaja principal es la visibilidad operativa: cada ejecución queda registrada, los errores son alertados y los reintentos son configurables. Además, Logic Apps incluye cientos de conectores preconstruidos, lo que reduce el tiempo de desarrollo cuando el sistema legado es SAP, Oracle o cualquier plataforma con conector disponible. Esta visibilidad es especialmente valiosa en proyectos de integración de datos con múltiples sistemas.
Para escenarios donde el volumen de transacciones es alto o la disponibilidad del sistema legado no está garantizada, se añade Azure Service Bus como buffer asíncrono. Los mensajes se encolan, D365 los consume a su ritmo y ninguna transacción se pierde aunque uno de los sistemas esté temporalmente inaccesible. Este patrón asíncrono es fundamental en integraciones de datos con sistemas de alta carga.
Patrón 3: Change Data Capture (CDC) para bases de datos legadas
Cuando el sistema legado no tiene API — un escenario frecuente con ERPs propietarios o bases de datos SQL antiguas en LATAM — el Change Data Capture detecta cambios directamente en el log de transacciones sin necesidad de modificar el sistema fuente. Este enfoque permite una integración de datos no intrusiva sobre sistemas que no pueden ser modificados.
Herramientas como Azure Data Factory con modo incremental o conectores CDC especializados leen los cambios en tiempo casi real y los envían a Dynamics 365 a través de la Web API. Este patrón es el que más se acerca a la sincronización en tiempo real sin tocar el código del sistema legado — una ventaja crítica cuando ese sistema no tiene soporte activo. Para muchos proyectos de integración de datos en LATAM, CDC es la única opción técnicamente viable.
Caso real: retail en México con CDC y Service Bus
Un cliente del sector retail en México operaba con un WMS propietario de más de doce años y Dynamics 365 Sales como CRM. La sincronización de disponibilidad de stock entre ambos sistemas se hacía mediante un proceso ETL nocturno: el equipo de ventas trabajaba con datos de hasta ocho horas de antigüedad, lo que generaba compromisos de venta sobre stock ya agotado. La ausencia de una integración de datos moderna era el cuello de botella principal del negocio.
La arquitectura que implementamos combinó CDC sobre la base de datos SQL del WMS con Azure Service Bus como buffer y la OData Web API de Dynamics 365 como destino. Esta integración de datos permitió eliminar completamente el ETL nocturno. El resultado: la latencia de sincronización pasó de ocho horas a menos de 45 segundos, sin modificar una sola línea de código del WMS.
El impacto operativo fue inmediato: las discrepancias de stock en pedidos confirmados cayeron un 73% en el primer mes. El equipo de ventas ganó visibilidad en tiempo real sobre disponibilidad regional, y el área de logística redujo el tiempo dedicado a reconciliaciones manuales de cuatro horas diarias a menos de veinte minutos. El factor decisivo no fue la tecnología — fue definir el sistema de registro antes de escribir una sola línea de configuración. En proyectos de integración de datos, esa definición previa marca la diferencia entre el éxito y el retrabajo.
Middleware Dynamics 365: cuándo necesitas una capa de integración dedicada
Cuando el ecosistema supera dos o tres sistemas conectados, la arquitectura punto a punto se convierte en un problema. Cada nueva conexión directa añade una dependencia frágil que alguien tendrá que mantener. La integración de datos entre múltiples sistemas exige una capa centralizada que elimine esa fragmentación.
Un middleware Dynamics 365 centraliza la lógica del flujo: transforma formatos, enruta mensajes, gestiona errores y ofrece un único punto de monitorización para todo el ecosistema de integración de datos. Mantener siete pipelines directos cuesta más que mantener una capa de middleware bien diseñada con siete conectores.
En el ecosistema Microsoft, la combinación de Azure API Management + Azure Logic Apps + Service Bus cubre la mayoría de los escenarios enterprise de integración de datos. API Management añade gobernanza, throttling y seguridad sobre las APIs expuestas por D365; Logic Apps orquesta los flujos; Service Bus garantiza la entrega de mensajes.
iPaaS de terceros: MuleSoft, Boomi y Jitterbit frente al stack Microsoft
El stack Microsoft no es la única opción. Muchos equipos en LATAM llegan a un proyecto de integración de datos con Dynamics 365 habiendo ya invertido en plataformas iPaaS independientes — MuleSoft, Boomi o Jitterbit — y la pregunta real no es cuál es mejor en abstracto, sino cuándo tiene sentido seguir con lo que ya tienes.
Cuándo los iPaaS de terceros son la elección correcta
MuleSoft Anypoint Platform es la opción más robusta para la integración de datos cuando el ecosistema de sistemas es heterogéneo y ya existe un equipo con experiencia en Mule. Su modelo de API-led connectivity encaja bien en organizaciones con docenas de sistemas conectados. El coste de licencia es elevado (típicamente desde 50.000 USD anuales), pero se justifica cuando la alternativa es construir conectores personalizados para cada sistema.
Dell Boomi destaca por su facilidad de configuración y su modelo de bajo código, comparable a Logic Apps pero con mayor independencia del proveedor cloud. En el ámbito de la integración de datos, su punto débil frente a Logic Apps es la profundidad de los conectores nativos para el stack Microsoft: la integración con Dataverse y D365 funciona, pero sin la optimización que ofrece el conector nativo de Microsoft.
Jitterbit ocupa un espacio intermedio en el mercado de integración de datos: más accesible en precio que MuleSoft, con conectores preconstruidos para Dynamics 365 y un enfoque orientado a integraciones ERP-CRM.
Criterios de decisión: ¿nativo Microsoft o iPaaS independiente?
La respuesta depende de cuatro factores. Primero, el ecosistema existente: si el 80% de tus sistemas son Microsoft, el stack nativo reduce fricción y coste en la integración de datos. Segundo, la madurez del equipo: Logic Apps tiene una curva de aprendizaje baja para equipos ya en Azure; MuleSoft requiere perfiles especializados. Tercero, el modelo de licenciamiento: Logic Apps factura por ejecución, mientras que los iPaaS de terceros suelen tener costes fijos más altos. Cuarto, el vendor lock-in: si la estrategia es multicloud, un iPaaS neutral es una cobertura válida para cualquier proyecto de integración de datos.
En la práctica, lo que más vemos en LATAM es un escenario híbrido: Logic Apps para flujos de integración de datos dentro del ecosistema Microsoft y un iPaaS de terceros para conexiones con sistemas externos complejos.
Costes reales: qué presupuestar para cada patrón
Estos son los números de referencia que manejamos en proyectos medianos de integración de datos en LATAM, basados en precios publicados de Azure a 2024.
Azure Logic Apps
Logic Apps factura principalmente por ejecuciones de acciones y conectores. En el plan de consumo estándar, cada acción cuesta aproximadamente 0,000025 USD. Un flujo típico de sincronización bidireccional — y por tanto de integración de datos — puede consumir entre 8 y 15 acciones por ejecución. Con 100.000 sincronizaciones mensuales, el coste de Logic Apps se sitúa entre 20 y 40 USD al mes en el plan de consumo. Los conectores premium añaden un coste fijo de 1 USD por conexión al mes.
Azure Service Bus
Service Bus factura por operaciones de mensajería. En el nivel Estándar, el precio es de 0,05 USD por millón de operaciones. Para un escenario de buffer asíncrono con 5 millones de mensajes mensuales en un flujo de integración de datos, el coste es de aproximadamente 0,25 USD al mes en mensajería pura. La mayoría de los proyectos medianos en LATAM operan en el nivel Estándar sin necesidad de Premium.
Azure Data Factory (CDC y pipelines)
Data Factory factura por pipeline runs, actividades de orquestación y unidades de integración de datos (DIU). Cada pipeline run cuesta 1 USD por 1.000 ejecuciones. Un pipeline de captura incremental sobre una base de datos SQL con 500.000 filas diarias puede costar entre 15 y 50 USD al mes dependiendo de la frecuencia de ejecución. Las unidades de integración de datos son el componente de coste más variable en cargas intensivas.
En conjunto, una arquitectura completa con Logic Apps + Service Bus + Data Factory para un escenario medio de integración de datos en LATAM puede presupuestarse entre 200 y 500 USD/mes en costes de infraestructura Azure, sin contar licencias de Dynamics 365 ni costes de desarrollo.
Migración progresiva: cómo convivir con el ETL legacy mientras construyes el nuevo pipeline
El escenario más común en proyectos reales no es “apagamos el ETL y encendemos el nuevo pipeline”. Es: el ETL legacy sigue corriendo en producción mientras construimos el nuevo flujo de integración de datos en paralelo, y necesitamos un criterio claro para el cutover.
La estrategia del pipeline en paralelo
El enfoque que aplicamos en KCP Dynamics es construir el nuevo pipeline de integración de datos en modo shadow: el nuevo flujo procesa los mismos eventos que el ETL legacy, pero escribe en un entorno de staging separado. Durante dos o cuatro semanas, se comparan los resultados de ambos sistemas registro a registro. Cuando la tasa de discrepancia cae por debajo del umbral acordado — típicamente menos del 0,1% — se activa el cutover.
Este modelo tiene tres ventajas. Primero, el riesgo de pérdida de datos es casi nulo: el ETL legacy sigue siendo el sistema de registro hasta que el nuevo pipeline de integración de datos demuestra paridad. Segundo, el equipo gana confianza en la nueva arquitectura con datos reales. Tercero, los errores de mapeo de campos aparecen en staging, no en producción.
Criterios de cutover
Los criterios que recomendamos documentar antes de iniciar la migración progresiva de integración de datos son: tasa de discrepancia por debajo del umbral acordado, prueba de carga superada con volumen equivalente al pico de producción, runbook de rollback validado por el equipo operativo y ventana de mantenimiento acordada con el negocio para el cambio definitivo. Una vez activado el nuevo pipeline, el ETL legacy se mantiene en modo monitor durante al menos dos semanas adicionales antes de desactivarlo definitivamente.
Seguridad y compliance en la capa de integración
La conversación sobre cómo conectar sistemas suele terminar cuando el flujo funciona. Ese es el momento en que debería empezar la conversación sobre cómo protegerlo. En LATAM, las regulaciones de protección de datos están endureciéndose: la LGPD en Brasil, la Ley Habeas Data en Colombia y sus equivalentes en México y Argentina imponen requisitos concretos sobre el tratamiento de datos personales en tránsito. Cualquier arquitectura de integración de datos debe contemplar estas regulaciones desde el diseño inicial.
Autenticación y autorización en APIs de Dynamics 365
Toda conexión con la Web API de Dynamics 365 debe autenticarse mediante OAuth 2.0 con Azure Active Directory. El patrón recomendado para integraciones servidor a servidor es el flujo de credenciales de cliente, que elimina la dependencia de credenciales de usuario individuales. Nunca uses credenciales de usuario en un pipeline automatizado — es el vector de fallo más común cuando alguien cambia su contraseña, y también uno de los mayores riesgos de seguridad en proyectos de integración de datos.
En Azure API Management, configura políticas de throttling por suscripción para respetar los límites de API documentados de Dataverse: 6.000 peticiones por minuto por organización en el nivel estándar.
Cifrado en tránsito y en reposo
Todo el tráfico de integración de datos entre sistemas debe viajar sobre TLS 1.2 como mínimo. En entornos donde el sistema legado no puede negociar TLS moderno, el middleware actúa como terminador SSL. Nunca expongas endpoints de integración sin cifrado, aunque sean internos a la red corporativa.
Para datos especialmente sensibles, considera cifrado a nivel de campo antes de que el dato entre al pipeline de integración de datos. Azure Key Vault centraliza la gestión de claves y secretos, eliminando credenciales hardcodeadas en configuraciones.
Compliance LATAM: lo que el pipeline debe documentar
Las regulaciones de privacidad en LATAM no solo afectan al almacenamiento — afectan al tránsito. Cualquier pipeline de integración de datos que mueva datos personales entre sistemas debe tener documentado: qué datos viajan, por qué canales, con qué cifrado y durante cuánto tiempo se retienen los logs.
En la práctica, esto significa que los logs de Azure Logic Apps que contengan datos personales deben tener políticas de retención configuradas y, en algunos casos, enmascaramiento de campos sensibles. La integración de datos compliant no se improvisa: el compliance no se añade al final del proyecto — se diseña desde la arquitectura.
Conectores nativos vs. conectores personalizados: dónde está el límite
Dynamics 365 incluye conectores nativos para el ecosistema Microsoft y para plataformas comunes como SAP, Salesforce o Workday. Son el punto de partida correcto para cualquier proyecto de integración de datos: reducen el tiempo de implementación y el riesgo técnico inicial. Pero tienen límites que conviene conocer.
Los conectores nativos fallan de forma silenciosa con mayor frecuencia que las soluciones personalizadas bien construidas. Para sistemas legados propietarios que requieren integración de datos crítica, un conector personalizado sobre la Web API de D365 ofrece más control y mejor trazabilidad a largo plazo.
La decisión correcta no es “nativo vs. personalizado” como principio general. Es: ¿qué nivel de control operativo necesito sobre este pipeline específico de integración de datos? Si un fallo en esa conexión detiene un proceso crítico de negocio, invierte en una solución personalizada con manejo de errores explícito.
Sincronización en tiempo real: qué significa realmente y qué no
El término “tiempo real” se usa con demasiada libertad en las demos. Antes de definir la arquitectura de integración de datos, conviene acordar con el negocio qué latencia es aceptable para cada flujo. No todos los datos necesitan sincronización en tiempo real — y forzarla donde no es necesaria añade complejidad y coste sin beneficio.
Una guía práctica para clasificar flujos de integración de datos por latencia requerida:
- Tiempo real estricto (<1 segundo): disponibilidad de stock en punto de venta, aprobaciones de crédito. Requiere webhooks o CDC con procesamiento en streaming. La integración de datos en este rango es la más exigente técnicamente.
- Casi tiempo real (1-60 segundos): actualización de pedidos entre CRM y ERP. Azure Service Bus con consumidores reactivos cubre este rango de integración de datos.
- Near real-time (1-15 minutos): sincronización de maestros de clientes, actualización de precios. Logic Apps con triggers programados de alta frecuencia resuelven este escenario de integración de datos.
- Batch controlado (>15 minutos): consolidación contable, reportes de cierre. Azure Data Factory en modo incremental. Este modelo de integración de datos sigue siendo válido para flujos no críticos.
Clasificar cada flujo de integración de datos antes de diseñar la arquitectura reduce el sobredimensionamiento técnico — uno de los factores que más infla el coste sin aportar valor real.
Errores frecuentes en proyectos de integración Dynamics 365 en LATAM
En proyectos reales con clientes en manufactura, retail y servicios financieros, los patrones de fallo en integración de datos se repiten. Conocerlos de antemano es la diferencia entre un proyecto que entra en producción en el plazo previsto y uno que lleva seis meses de retraso.
Ignorar la gobernanza de datos desde el inicio
La integración de datos no es solo mover registros de A a B. Es decidir quién es el sistema de registro (system of record) para cada entidad. Si tanto el ERP legado como Dynamics 365 pueden modificar el maestro de clientes, necesitas una política de resolución de conflictos antes de escribir una sola línea de código. Sin esa política, la sincronización en tiempo real crea inconsistencias de datos más difíciles de resolver que el problema original.
No planificar el manejo de errores
Un pipeline de integración de datos que funciona el 95% del tiempo es un pipeline roto. El 5% de fallos sin manejo explícito se convierte en datos perdidos, registros duplicados y reconciliaciones manuales que consumen más tiempo que el proceso que se intentó automatizar. Cada flujo de integración de datos necesita: log de errores, lógica de reintento con backoff exponencial y alerta al equipo responsable.
Subestimar el impacto del volumen en producción
Los entornos de prueba rara vez replican el volumen, la concurrencia y los patrones de timing del sistema en producción. Una arquitectura de integración de datos que responde en 200ms con 100 registros puede saturarse con 50.000. El throttling de la API de Dynamics 365 tiene límites documentados — ignorarlos en el diseño genera cuellos de botella que solo aparecen cuando el negocio ya depende del sistema.
Cómo evaluar si tu arquitectura está lista para producción
Antes de dar por cerrado un proyecto de conexión entre Dynamics 365 y sistemas legados, hay un conjunto de criterios que en KCP Dynamics usamos como checklist de madurez en integración de datos. La madurez de una arquitectura no se mide solo por si funciona, sino por si puede mantenerse y recuperarse cuando algo falla.
- Trazabilidad completa: cada mensaje tiene un ID único rastreable de extremo a extremo, desde el sistema origen hasta Dynamics 365. Sin trazabilidad, la integración de datos no puede auditarse.
- Manejo de errores documentado: existe un runbook que define qué hacer cuando falla cada tipo de flujo de integración de datos, quién recibe la alerta y en qué plazo.
- Pruebas de carga con datos reales: el sistema ha sido validado con volúmenes equivalentes a los picos de producción.
- Sistema de registro definido: para cada entidad crítica, está documentado qué sistema tiene la versión autoritativa del dato en el flujo de integración de datos.
- Monitorización activa: existe un dashboard que muestra el estado de cada flujo de integración de datos en tiempo real, con alertas configuradas para latencia y tasa de error.
- Plan de rollback: si el pipeline falla en producción, hay un procedimiento documentado para revertir sin pérdida de registros ni corrupción de datos integrados.
- Compliance documentado: los flujos de integración de datos que mueven datos personales tienen registrada la base legal, el cifrado aplicado y la política de retención de logs.
Si alguno de estos puntos está en blanco, la arquitectura de integración de datos no está lista para producción — aunque funcione en el entorno de pruebas. La diferencia entre una demo exitosa y un sistema que opera con fiabilidad durante tres años está exactamente en estos detalles.
[CTA:diagnostico-integracion]
Preguntas frecuentes
¿Puedo conectar Dynamics 365 con un sistema legacy que no tiene API?
Sí. Cuando el sistema legado no expone API, el patrón más efectivo de integración de datos es Change Data Capture (CDC): detecta cambios directamente en el log de transacciones de la base de datos sin modificar el sistema fuente. Herramientas como Azure Data Factory en modo incremental permiten capturar esos cambios y enviarlos a Dynamics 365 en tiempo casi real. Es el enfoque que aplicamos cuando el sistema legado no tiene soporte activo o el proveedor ya no existe.
¿Cuál es la diferencia entre usar Power Automate y Azure Logic Apps para integrar Dynamics 365?
Power Automate está orientado a usuarios de negocio y flujos de menor volumen, con una interfaz más accesible y conectores premium disponibles sin código. Azure Logic Apps está diseñado para orquestación enterprise de integración de datos: mayor control sobre la ejecución, mejor manejo de errores, soporte para patrones asíncronos con Service Bus y más opciones de escalado. Para integraciones críticas con sistemas legados en producción, Logic Apps ofrece la robustez necesaria. Power Automate es el punto de entrada correcto para flujos secundarios o equipos con menor madurez técnica.
¿Qué es dual-write y cuándo debo usarlo?
Dual-write es el mecanismo nativo de Microsoft para sincronización bidireccional casi en tiempo real entre Dynamics 365 Finance & Operations y las aplicaciones de Customer Engagement (Sales, Service). Es la opción correcta de integración de datos cuando operas ambas capas de D365 y necesitas que los datos de clientes, productos o pedidos estén sincronizados sin desarrollo adicional. No está diseñado para conectar Dynamics 365 con sistemas externos — usarlo como puente hacia ERPs legados añade complejidad sin ventaja real.
¿Cómo evito duplicar datos cuando dos sistemas pueden modificar el mismo registro?
Definiendo el sistema de registro (system of record) para cada entidad antes de diseñar la integración de datos. Eso significa que solo un sistema tiene autoridad para crear o modificar cada tipo de dato — el otro recibe la actualización como consumidor. Si ambos sistemas necesitan capacidad de escritura, necesitas una política de resolución de conflictos explícita: por ejemplo, “el último en escribir gana” o “D365 tiene prioridad sobre el legado para datos de cliente”. Sin esa política documentada, la integración de datos en tiempo real genera inconsistencias difíciles de rastrear.
¿Cuánto tiempo tarda un proyecto de integración Dynamics 365 con sistemas legados?
Depende del número de flujos, la complejidad del sistema legado y la madurez del equipo. Una integración de datos puntual con un sistema que expone API puede estar en producción en cuatro a seis semanas. Un proyecto de integración de datos completo con múltiples sistemas, CDC sobre bases de datos sin API y capa de middleware dedicada puede llevar de tres a seis meses. El factor que más impacta en el plazo no es el desarrollo — es la definición de reglas de negocio: qué dato es el autoritativo, qué pasa cuando falla, quién aprueba los cambios de esquema.