La ruta técnica específica desde NAV 2018 hasta Business Central Online: upgrade on-premises, conversión de C/AL a AL, datos, SQL, reportes, integraciones, add-ons, testing y cutover.
Lo esencial de esta ruta, en formato pregunta y respuesta, antes del detalle técnico.
| Pregunta | Respuesta directa |
|---|---|
| ¿Se puede migrar NAV 2018 a Business Central Online? | Sí. La ruta documentada por Microsoft pasa por Business Central on-premises antes de la nube. Ver ruta |
| ¿Es un salto directo a la nube? | No con las herramientas actuales: primero hay que actualizar a Business Central on-premises (versión 14 y luego 25 o superior). Ver ruta |
| ¿Qué pasa con las customizaciones C/AL? | Se convierten en extensiones AL. Los datos de tablas con código propio requieren una extensión instalada on-premises y online. Ver customizaciones |
| ¿Cómo se convierten los objetos? | Export con ExportToNewSyntax y conversión con Txt2Al de la versión 14, más refactorización manual. Ver conversión |
| ¿Qué datos se migran? | Datos de negocio por compañía. No se migran usuarios, permisos ni la mayoría de tablas de sistema. Ver datos |
| ¿Qué requisitos tiene SQL Server? | SQL Server 2016 o superior y nivel de compatibilidad 130 o superior. Ver SQL |
| ¿Qué pasa con reportes e integraciones? | Reportes a objetos AL; integraciones a API v2.0, OData v4 y automatización, sin acceso directo a SQL. Ver reportes · Ver integraciones |
| ¿Cuánto downtime hay? | Replicación inicial + delta; la ventana final se acota con simulacros previos. Ver downtime |
NAV 2018 fue la última versión publicada con el nombre Dynamics NAV. Business Central es su sucesor y el único producto con evolución continua, novedades funcionales e integración con el ecosistema Microsoft 365, Power Platform y Azure.
Según la página oficial de ciclo de vida de Microsoft, Dynamics NAV 2018 siguió la política de ciclo de vida fijo: el soporte mainstream finalizó el 11 de enero de 2023 y el soporte extendido está previsto hasta el 12 de enero de 2028. Ese calendario es la razón principal para planificar la migración con antelación.
Estado de soporte según la documentación oficial: Microsoft Lifecycle — Dynamics NAV 2018. Verificá siempre el estado vigente.
La ruta estándar documentada por Microsoft no es un salto directo: pasa por Business Central on-premises antes de la nube.
El primer paso es actualizar la base de NAV 2018 a Business Central versión 14 on-premises. Es la última versión con soporte C/AL y la base para la conversión a AL. Requiere compilar y exportar los objetos C/AL.
Luego se actualiza a Business Central on-premises versión 25 o superior. Aquí se ejecuta la conversión de las customizaciones a extensiones AL y se resuelven dependencias de add-ons.
Con la versión soportada y las extensiones listas, se configura la migración a la nube: Azure Data Factory, Integration Runtime, replicación de datos y upgrade final en el entorno online.
| Versión de origen | Ruta de upgrade documentada |
|---|---|
| Dynamics NAV 2015 a 2018 | 1) Business Central versión 14 on-premises → 2) Business Central on-premises versión 25 o superior → 3) Business Central Online |
| Dynamics NAV 2013 y 2013 R2 | 1) Dynamics NAV 2018 → 2) Business Central on-premises versión 14 → 3) Business Central on-premises versión 25 o superior → 4) Business Central Online |
| Dynamics NAV 2009 SP1 y 2009 R2 | 1) Dynamics NAV 2013 o 2015 → 2) NAV 2018 → 3) Business Central on-premises versión 14 → 4) Business Central on-premises versión 25 o superior → 5) Business Central Online |
Microsoft plantea dos caminos. La migración completa traslada todos los datos y customizaciones, y exige convertir C/AL a AL y actualizar a la última versión. La reimplementación migra solo los datos esenciales (maestros, saldos, una parte del histórico y configuración) y no requiere convertir extensiones ni actualizar más allá de la versión 14.
En ambos casos el primer paso es actualizar de NAV 2018 a Business Central versión 14 on-premises. La reimplementación se apoya en la herramienta de Business Central 14 y está pensada para bases muy customizadas o procesos que se quieren rediseñar.
Ruta y fases según la documentación oficial: Migrate Dynamics NAV to Business Central online.
Business Central Online ejecuta solo extensiones. Toda modificación del código base debe reescribirse.
En NAV 2018 las customizaciones se hacían modificando objetos base: tablas, páginas, codeunits y reports. Ese modelo no es compatible con la nube, donde el código base está bloqueado. Durante la auditoría cada objeto modificado se inventaría y clasifica:
Un punto crítico: los datos de tablas con código personalizado no se trasladan a la nube salvo que la customización esté gestionada por una extensión instalada tanto on-premises como online. Por eso conviene separar datos de comportamiento desde el inicio.
Detalle oficial: Customization migration guide — Dynamics NAV to Business Central Online.
La conversión automática es un punto de partida. El valor está en la compilación, la refactorización y el testing.
Se compilan todos los objetos y se exportan a la nueva sintaxis TXT, omitiendo los objetos de sistema (IDs en el rango 2000000000):
VPCExport-NAVApplicationObject `
-DatabaseServer .\BCDEMO `
-DatabaseName "Demo Database NAV (2018)" `
-ExportToNewSyntax `
-Path "C:\export2al\baseapplication\exported.txt" `
-Filter 'Id=1..1999999999'La herramienta Txt2Al solo se distribuye con Business Central versión 14, la última con soporte C/AL. Se usa esa versión sin importar la versión destino:
txt2al --source="C:\export2al\baseapplication" `
--target="C:\export2al\baseapplication\al" `
--renametableextension 50101 "VPC Customer Ext"
extends Customer
{
fields
{
field(50100; "VPC Discount %"; Decimal)
{
Caption = 'Descuento VPC %';
DecimalPlaces = 0 : 2;
}
}
}El código AL se monta en Visual Studio Code con la extensión AL Language, se resuelven los errores de compilación y se valida con analizadores estáticos antes de publicar en un entorno sandbox.
Procedimiento oficial: Code Conversion from C/AL to AL · Txt2Al Conversion Tool.
La migración de datos a la nube usa Azure Data Factory y el Integration Runtime, tabla por tabla y por compañía.
| Tipo de dato | ¿Se migra? | Observación |
|---|---|---|
| Datos de negocio de compañías | Sí | Tablas de la aplicación base y de extensiones que cumplan los requisitos |
| Maestros (clientes, proveedores, productos, cuentas) | Sí | Migración por tabla; también admite paquetes de configuración |
| Saldos de apertura y configuración | Sí | Se validan con conciliaciones antes del go-live |
| Histórico de movimientos | Según alcance | Completo o resumido; en reimplementación, solo un subconjunto |
| Usuarios, permisos y mayoría de tablas de sistema | No | No se migran; se configuran de nuevo en la nube |
| Vínculos de registros (record links) | No | Dependen del usuario y no se trasladan |
| Adjuntos y documentos | Según alcance | SharePoint, OneDrive o almacenamiento externo |
El proceso se gestiona desde Business Central Online y conecta con la base SQL on-premises mediante Azure Data Factory y el Integration Runtime. La primera replicación es completa y las siguientes son incrementales (delta). La solución on-premises sigue siendo el entorno operativo hasta completar la migración.
Referencia: Business Central on-premises to online migration overview.
La calidad y el orden de la base SQL condicionan la velocidad y el éxito de la migración.
No hay acceso directo a la base SQL en Business Central Online. Toda lectura o escritura desde sistemas externos pasa por APIs, OData o automatizaciones. Esto es un cambio de arquitectura, no solo de infraestructura.
Se convierten a AL, se reemplazan por estándar o se reorientan a analítica.
Cada report C/AL se reescribe como objeto report de AL. Los datasets se reconstruyen y los layouts RDLC o Word suelen poder reutilizarse con ajustes de formato y campos.
Cuando el reporte estándar de Business Central cubre la mayor parte, se extiende para agregar campos, columnas o filtros sin duplicar el objeto. Menos código y más compatibilidad con actualizaciones.
Los listados operativos se complementan con dashboards de Power BI conectados a Business Central. Ver Power BI para Business Central →
El inventario de reportes se hace en la auditoría: se identifica cuáles se usan, cuáles se pueden retirar y cuáles conviene reemplazar por estándar. Así se evita arrastrar reportes históricos que ya nadie utiliza.
Sin acceso directo a SQL ni interoperabilidad .NET: las integraciones se rehacen con servicios y APIs.
La API v2.0 (REST) y OData v4 exponen las entidades estándar. Para casos específicos se desarrollan APIs personalizadas y webhooks que notifican eventos de negocio.
Power Automate, Azure Logic Apps y Azure Functions permiten orquestar flujos con CRM, e-commerce, bancos y sistemas externos sin acoplarse a la base de datos.
Las integraciones se autentican con Entra ID (antes Azure AD) y OAuth 2.0. Se revisan permisos, aplicación de servicio y alcance mínimo necesario.
| En NAV 2018 | En Business Central Online |
|---|---|
| Acceso directo a SQL Server | Sin acceso directo: solo a través de APIs y OData |
| Web services SOAP y OData v3/v4 | API v2.0 REST, OData v4 y APIs personalizadas |
| Dataports y archivos de intercambio | XMLports en AL, APIs y Power Automate |
| Autenticación Windows / NavUserPassword | Entra ID y OAuth 2.0 |
| .NET interop y control add-ins locales | No disponible: control add-ins, Azure Functions o APIs externas |
Se profundiza en apps e integraciones móviles y cloud y en la sección de integraciones de servicios. Referencia: API (v2.0) for Business Central.
Un add-on en C/AL no viaja a la nube. Cada producto debe revisarse antes de la migración.
Si el add-on no tiene versión AL, las opciones son: reescribir su funcionalidad como extensión propia, reemplazarlo por funcionalidad estándar de Business Central o por otro producto del ecosistema, o descartarlo si ya no aporta valor. Esta decisión impacta directamente en el esfuerzo y el cronograma.
La playbook de Microsoft recomienda clasificar cada ítem por complejidad (campo simple, lógica compleja, dependencia de terceros) y decidir el modelo de despliegue antes de convertir.
Cada fase tiene criterios de aceptación. Nada llega a producción sin validación funcional y de datos.
Microsoft recomienda realizar al menos un simulacro completo de la migración en un entorno sandbox antes del cutover de producción, para identificar problemas, medir tiempos y validar resultados con los usuarios de negocio.
El corte final es una secuencia controlada de replicación, upgrade de datos y apertura en producción.
Una vez ejecutado con éxito el data upgrade no se puede volver a replicar desde una versión anterior, porque se mezclarían registros no actualizados con registros ya actualizados. Por eso la validación previa es obligatoria.
Durante la migración, los usuarios de la nube quedan restringidos por el conjunto de permisos Intelligent Cloud para evitar escrituras que la replicación sobreescribiría. Conviene asegurar al menos un usuario SUPER por compañía antes de configurar la conexión.
La replicación por etapas permite llegar al corte con el menor riesgo posible.
La primera replicación es la más larga porque copia todos los datos; las siguientes migran solo los cambios y son más rápidas. Con esta mecánica, el downtime real se concentra en el tramo final: replicación delta, data upgrade, validación y apertura.
En proyectos ordenados, esa ventana suele acotarse a una noche o un fin de semana. Cuanto mayor sea el volumen de datos, más integraciones haya que reconectar y más validaciones requiera el negocio, mayor será la ventana necesaria.
Estimaciones orientativas. El rango final depende del alcance y se confirma en el diagnóstico.
| Fase | Duración estimada |
|---|---|
| Auditoría y planificación | 1 a 3 semanas |
| Upgrade on-premises NAV 2018 → BC 14 → BC 25+ | 3 a 8 semanas |
| Conversión de C/AL a AL y add-ons | 3 a 8 semanas |
| Migración y validación de datos | 2 a 6 semanas |
| Testing, UAT y simulacro de cutover | 2 a 4 semanas |
| Cutover y estabilización | 1 a 2 semanas |
Estas cifras son estimaciones de planificación, no compromisos de plazo. Una base NAV 2018 con pocas customizaciones y sin add-ons puede ser más rápida que una con muchas modificaciones de posting e integraciones. El costo se compone de licencias por usuario (Essentials o Premium) y de servicios de migración, y se cotiza por fases.
Business Central Online se contrata por suscripción por usuario, no con licencia perpetua. El costo depende de la cantidad de usuarios y de la edición contratada.
Ver precios de Business CentralPara la visión completa del proceso, versiones y comparativas de rutas, ver la guía principal.
Migración NAV a Business CentralSí. Microsoft documenta una ruta de migración para Dynamics NAV 2015 a 2018 que pasa por Business Central on-premises (versión 14 y luego versión 25 o superior) antes de migrar a Business Central Online. No es un salto directo: requiere un upgrade intermedio on-premises y la conversión de las customizaciones C/AL a extensiones AL.
Con las herramientas actuales, la ruta estándar no es directa. Microsoft indica que las versiones de Dynamics NAV no migran directamente a la nube: primero hay que actualizar a Business Central on-premises. La ruta documentada para NAV 2018 es NAV 2018, luego Business Central versión 14 on-premises, luego Business Central on-premises versión 25 o superior y por último Business Central Online.
Todas las customizaciones C/AL deben convertirse en extensiones AL. Los datos de tablas con código personalizado no se pueden trasladar a la nube salvo que la customización esté gestionada por una extensión instalada tanto on-premises como online. Los cambios de esquema que eliminan o renombran campos impiden la sincronización de la extensión y deben planificarse con cuidado.
Parcialmente. Se exportan los objetos C/AL con Export-NAVApplicationObject y el modificador ExportToNewSyntax, y se convierten con la herramienta Txt2Al que se distribuye con Business Central versión 14. El resultado es un punto de partida que debe compilarse, refactorizarse y validarse. A partir de la versión 21 de Business Central la herramienta Txt2Al ya no está disponible, por lo que se usa la versión 14.
Se migran los datos de negocio de una o más compañías: tablas de la aplicación base y de las extensiones, siempre que cumplan los requisitos. No se migran la mayoría de las tablas de sistema, usuarios ni permisos, y los vínculos de registros (record links) tampoco se trasladan porque dependen del usuario. La migración se realiza tabla por tabla con Azure Data Factory.
La solución on-premises debe usar SQL Server 2016 o superior y la base de datos debe tener nivel de compatibilidad 130 o superior. Durante la migración se agregan procedimientos almacenados a la instancia de SQL Server. Se recomienda archivar histórico obsoleto, reducir tablas de transacciones y logs y validar los cambios de esquema antes de migrar.
Los reportes C/AL se reimplementan como objetos report de AL. Los layouts RDLC y Word suelen poder reutilizarse con ajustes y los datasets se reconstruyen. Cuando el reporte estándar de Business Central cubre la mayor parte, se usa una report extension. La analítica puede complementarse con Power BI.
En Business Central Online no hay acceso directo a la base de datos SQL ni interoperabilidad .NET. Las integraciones se rehacen con la API v2.0 REST, OData v4, APIs personalizadas, webhooks, Power Automate o Azure Logic Apps, con autenticación basada en Entra ID y OAuth 2.0.
Cada add-on debe revisarse: si es una extensión V1 en C/AL no es compatible con la nube y debe reescribirse o reemplazarse. Si el proveedor publica una extensión AL para Business Central Online, se instala y se valida. La playbook de Microsoft recomienda inventariar y clasificar todos los objetos modificados, add-ons de ISV e integraciones.
El proceso se apoya en replicación por etapas: una replicación inicial completa y luego replicaciones delta con los cambios. La solución on-premises sigue siendo el entorno operativo hasta completar la migración, y se recomienda al menos un simulacro en sandbox antes del cutover de producción. La ventana final suele acotarse a una noche o un fin de semana según el volumen.
Según la página oficial de ciclo de vida de Microsoft, Dynamics NAV 2018 siguió la política de ciclo de vida fijo: el soporte mainstream finalizó el 11 de enero de 2023 y el soporte extendido está previsto hasta el 12 de enero de 2028. Conviene verificar siempre el estado vigente en la página de ciclo de vida de Microsoft.
Fuentes primarias sobre las que se basa esta guía.
Los enlaces apuntan a documentación oficial de Microsoft. La disponibilidad, los nombres de las herramientas y las rutas pueden cambiar con las versiones; verificá siempre el contenido vigente antes de planificar.
La guía general: versiones, rutas, comparativas, tiempos y costes de la migración.
Ver guía de migración →Qué es el ERP en la nube de Microsoft, sus módulos y cómo implementarlo.
Ver Business Central →Desarrollo a medida con lenguaje AL para personalizar sin romper las actualizaciones.
Ver extensiones AL →Ediciones, licenciamiento por usuario y factores que definen el costo.
Ver precios →