Migrar de Dynamics NAV a Business Central: qué pasará con la integración

August 21, 2026 · Beate Thomsen · Integración de datos

Pasar de Dynamics NAV a Business Central no significa automáticamente reconstruir tu integración: lo que ocurra depende de cómo se construyó. Según la configuración, puede que haya que reconstruir, reconfigurar o adaptar la integración. En este blog compartimos una guía de migración en seis pasos para ayudarte a pasar a Business Central sin poner en riesgo tu negocio.

Cambiar a un nuevo ERP puede parecer un proyecto enorme, sobre todo cuando tu CRM y otros sistemas dependen de tu integración actual con Dynamics NAV. Pero el cambio no significa necesariamente empezar desde cero.

En nuestro reciente webinar, Beate H. Thomsen y Andreea Arseni analizaron qué ocurre con tu integración al pasar de Dynamics NAV a Business Central, qué cambia entre on-premise y cloud, y cómo abordar la migración de forma controlada.

Qué encontrarás en este artículo:

• ¿Qué ocurre con tu integración al pasar a Business Central?
• ¿Qué cambia al pasar a Business Central Cloud?
• ¿Cómo puedes mantener tu migración bajo control?
• Descarga la Guía de actualización en 6 pasos
  

 

 

 

¿Qué ocurre con tu integración al pasar a Business Central?

Pasar de Dynamics NAV a Business Central no significa automáticamente reconstruir tu integración.

Lo que ocurra depende de cómo se construyó la integración y de cómo se conecta a Dynamics NAV. Hay tres escenarios posibles: reconstruir, reconfigurar o adaptar.

Reconstruir

Si tu integración está ligada a una versión concreta de Dynamics NAV, lee directamente las tablas de NAV o tiene los mapeos de campos y las reglas de negocio integrados en el conector, puede que haya que reconstruir parte de ella.

Una pregunta útil es: ¿dónde están documentados tus mapeos de campos y tus reglas de negocio?

Si la respuesta es simplemente «está en el código», puede que te enfrentes a una reconstrucción.

Reconfigurar

Si tus mapeos y tu lógica de negocio se gestionan por separado del ERP, por ejemplo en una plataforma de integración, puede que baste con reconfigurar la integración existente.

Esto puede implicar redirigir la conexión, configurar la autenticación y volver a mapear los campos que hayan cambiado.

En este caso, la migración se parece mucho más a un trabajo de configuración que a una reconstrucción completa.

Adaptar

Algunas integraciones usan código personalizado contra los servicios web de NAV. En estos casos, la conexión puede mantenerse, pero puede que haya que adaptar el código ligado a una versión concreta de la API o al esquema de NAV.

Esto va más allá de un cambio de configuración, pero no significa necesariamente reconstruir toda la integración.

Lo importante es que lo que ocurra con tu integración depende de cómo se construyó, no simplemente de lo antiguo que sea tu sistema NAV.

¿Qué cambia al pasar a Business Central Cloud?

El diseño de la integración no cambia necesariamente, pero sí la forma de conectarte a Business Central.

Se puede conservar más de lo que imaginas. El alcance de tu integración, los flujos de datos, las reglas de coincidencia, la deduplicación, la lógica de transformación, la gestión de conflictos y la frecuencia de sincronización no cambian automáticamente por pasar a Business Central.

Las principales diferencias entre Dynamics NAV, Business Central on-premise y Business Central Cloud tienen que ver con:

• El método de acceso
• La autenticación
• Dónde se ubica el motor de integración
• Los campos personalizados
• El volumen y el rendimiento
• Los entornos de prueba

Por ejemplo, pasar a Business Central Cloud puede implicar actualizar la autenticación, exponer los campos personalizados a través del nuevo entorno y tener en cuenta la limitación de solicitudes (throttling) y el procesamiento por lotes.

En resumen:

La nube cambia cómo te conectas, no lo que conectas.

¿Cómo puedes mantener tu migración bajo control?

Una vez que sabes qué tiene que pasar con tu integración, el siguiente reto es pasar al nuevo sistema sin jugártelo todo a un único gran fin de semana de cambio.

El enfoque en seis pasos que se presentó en el webinar es el siguiente:

1. Mapear y definir el alcance

Decide qué se migra, qué se queda atrás como histórico y acuerda la fecha de corte.

2. Depurar en origen

Elimina duplicados y corrige tus datos en el sistema antiguo antes de migrarlos.

3. Hacer un ensayo con un subconjunto

Prueba una parte representativa de la migración y detecta los problemas mientras todavía son más fáciles de solucionar.

4. Ejecutar el sistema antiguo y el nuevo en paralelo

Mantén ambos sistemas activos y al día con una sincronización bidireccional. Así no hay que congelar nada y no se pierde trabajo.

5. Validar y conciliar

Acuerda tus criterios de aceptación antes de empezar y úsalos para comprobar los resultados.

6. Hacer el cambio cuando tú decidas

Desconecta el sistema antiguo una vez que el nuevo haya demostrado que funciona, y no simplemente porque se fijó una fecha hace meses.

El objetivo es sencillo: detectar los problemas durante el ensayo, no el fin de semana del go-live.

Descarga la Guía de actualización en 6 pasos y los recursos del webinar

¿Quieres el enfoque completo, con una lista de comprobación para cada paso?

La Guía de actualización en 6 pasos lo cubre todo: desde mapear y depurar tus datos hasta ejecutar ambos sistemas en paralelo, validar los resultados y hacer el cambio cuando tú decidas.

Descarga las diapositivas del webinar para tener todas las claves en un solo lugar.

Si estás planificando una migración de Dynamics NAV a Business Central y quieres hablar sobre tu integración, contáctanos para una evaluación →

Preguntas frecuentes

¿Qué pasa con nuestras integraciones actuales cuando pasamos de NAV a Business Central?

Depende de a qué esté vinculada la integración. Si está vinculada a una versión, a un esquema SQL o a un endpoint concreto, hay que reconstruirla. Si está vinculada a una definición de conexión con mapeos que son tuyos, basta con reconfigurarla: la diriges al nuevo sistema y los mapeos se mantienen. La propia lista de comprobación de Microsoft para la migración a la nube sitúa la reconexión de las integraciones en el paso 7 de 8, lo que dice mucho de cómo trata hoy el sector esta cuestión. NAV 2016 y versiones posteriores y Business Central usan el mismo tipo de conexión de Rapidi, así que para los clientes de Rapidi se trata de una reconexión y no de una reconstrucción.

¿Qué pasa con los campos personalizados que añadimos a NAV hace años?

Esta es la pregunta que decide si tu integración sobrevive, y normalmente se plantea demasiado tarde. Hay tres casos, y necesitas saber en cuál está cada campo antes de fijar el presupuesto: el campo ya existe de serie en Business Central, el campo se traslada como parte de una extensión, o el campo no existe y alguien tiene que decidir si debería existir. Audita tus campos personalizados antes de definir el alcance del proyecto, no a mitad de camino.

¿Podemos tener NAV y Business Central funcionando en paralelo durante la transición?

Sí, y es la forma más tranquila de hacerlo, pero no con la herramienta de migración a la nube de Microsoft. Esa herramienta hace una replicación unidireccional hacia el nuevo entorno, y la propia documentación de Microsoft advierte de que, cada vez que se ejecuta la migración, se sobrescriben los cambios realizados en la empresa de destino online. Mueve datos; no permite que ambos sistemas estén activos. Trabajar de verdad en paralelo significa una sincronización bidireccional entre los dos sistemas, con una fecha de corte acordada, una fase de validación y un cambio de sistema en la fecha que tú elijas.

¿Podemos pasar directamente de Dynamics NAV a Business Central online?

No. La ruta que marca Microsoft para NAV 2015 a 2018 consta de tres saltos: Business Central versión 14 on-premise, después Business Central on-premise versión 25 o posterior y, por último, Business Central online. Desde NAV 2013 son cuatro saltos, y desde NAV 2009, cinco. Dynamics GP y SL a partir de 2015 migran directamente, pero NAV no. Cada salto es un punto en el que hay que volver a ocuparse de una integración vinculada a una versión, a un endpoint o a un esquema.

Nuestras personalizaciones se desarrollaron en C/AL. ¿Qué pasa con ellas?

Todo lo que tenga personalizaciones de código debe convertirse en extensiones AL antes de poder pasar a online. Microsoft lo deja claro: los datos de tablas con personalizaciones de código no se pueden trasladar desde Dynamics NAV a menos que esas personalizaciones se gestionen mediante extensiones instaladas tanto on-premise como online. La alternativa es la herramienta de reimplementación de Business Central 14, que solo traslada datos maestros, saldos iniciales y configuración, y no conserva ni las transacciones históricas ni las personalizaciones heredadas. Si tus personalizaciones ya son extensiones, las actualizaciones son rutinarias. La deuda técnica está, en concreto, en el código anterior a las extensiones.

Usamos la sincronización estándar de Business Central con Dynamics 365 Sales. ¿Sigue funcionando sin más?

No. Microsoft incluye la reconfiguración de la conexión con Dynamics 365 Sales como un paso propio después de la migración a la nube: tienes que volver a configurar la conexión. Además, la reconexión esconde una trampa. La página de Microsoft sobre la acción Use Default Synchronization Setup indica que se sobrescribirán todos los mapeos personalizados, así que, si has adaptado mínimamente la sincronización estándar, una reconexión rutinaria puede borrar esas adaptaciones. Documenta tus mapeos antes de que nadie toque nada.

¿Hay límites de API con los que nos encontraremos una vez en la nube?

Sí, y están publicados. Por usuario, en una ventana deslizante de cinco minutos, 6.000 solicitudes OData o SOAP. Por entorno, 600 solicitudes por minuto en producción y 300 en sandbox, cinco solicitudes simultáneas, cien conexiones, noventa y cinco en cola y un tiempo de espera de ocho minutos por operación. Si superas el límite, recibes un 429 con una cabecera Retry-After. El detalle que casi todo el mundo pasa por alto es que Microsoft advierte de que una integración que se ejecute como un único usuario o entidad de servicio alcanzará el límite por usuario con bastante rapidez, y la solución documentada es repartir el trabajo entre varias entidades de servicio. En la práctica, es un detalle de diseño más que una crisis.

El soporte de NAV 2017 termina en enero de 2027. ¿Es ya demasiado tarde para planificar bien?

No, pero el margen es corto, y eso debería cambiar la forma del plan, no su ambición. El soporte de NAV 2016 terminó el 14 de abril de 2026, el de NAV 2017 termina el 11 de enero de 2027 y el de NAV 2018, el 11 de enero de 2028. Lo que hacen los equipos con experiencia cuando el margen es corto no es comprimir todo el proyecto, sino acortar el primer go-live: finanzas más un área operativa, en marcha en un trimestre, y el resto como una hoja de ruta con fechas. Mantener vivas las integraciones existentes durante la transición es lo que hace posible ese planteamiento.