Guía técnica y servicio profesional para pasar de NAV a Business Central Cloud sin perder datos, procesos ni continuidad operativa.
Lo esencial, en formato pregunta y respuesta, antes del detalle técnico.
| Pregunta | Respuesta directa |
|---|---|
| ¿Se puede migrar NAV a Business Central Cloud? | Sí. NAV 2018 y posteriores tienen ruta oficial de migración a Business Central online. Las versiones anteriores requieren actualización intermedia o reimplementación. Ver detalle |
| ¿Qué versiones de NAV pueden migrarse? | Desde NAV 2018 la migración directa es viable; NAV 2017, 2016, 2015, 2013 y 2009 se abordan con upgrade escalonado o reimplementación. Ver versiones |
| ¿Cuál es la ruta de migración? | Migración a la nube con el asistente de Microsoft, upgrade on-premise intermedio o reimplementación en BC Cloud. Ver rutas |
| ¿Qué pasa con las personalizaciones? | Se reescriben como extensiones AL. No se puede migrar código que modifica objetos base, porque la nube no lo permite. Ver personalizaciones |
| ¿Qué pasa con los datos históricos? | Se migran maestros, configuración, saldos de apertura y documentos abiertos. El histórico detallado se define por alcance. Ver datos |
| ¿Cuánto cuesta? | Depende de usuarios, customizaciones, integraciones, datos y localización. Se cotiza tras el diagnóstico. Ver costes |
| ¿Cuánto tarda? | Una migración estándar se estima entre 4 y 12 semanas, según base, customizaciones e integraciones. Ver tiempos |
| ¿Qué ocurre con las integraciones? | Se rehacen con API REST v2.0, OData v4, APIs personalizadas, webhooks o Power Automate. Ver integraciones |
| ¿Qué ocurre con los reportes? | Se convierten a objetos report de AL, reutilizando layouts RDLC o Word cuando es posible. Ver reportes |
Sí. Business Central es el sucesor en la nube de Dynamics NAV y Microsoft mantiene una ruta de migración para las versiones soportadas. La viabilidad depende de la versión de NAV, del grado de personalización y de cómo estén construidas las integraciones.
La diferencia clave con un upgrade tradicional es el modelo de extensión: en Business Central Cloud no se puede modificar el código base. Toda personalización debe vivir en una extensión AL. Eso obliga a un relevamiento y una clasificación previa de cada customización.
Cada generación de NAV tiene una ruta distinta hacia Business Central Cloud. Microsoft publica el estado exacto en su política de ciclo de vida.
| Versión | Características | Ruta recomendada a BC Cloud |
|---|---|---|
| NAV 2018 | Última versión con el nombre NAV. Base de tres capas sobre SQL Server, web services y extensiones v2. | Upgrade a Business Central on-premises (versión 14 y luego 25 o superior) y migración a la nube, con conversión de C/AL a AL. Ver guía NAV 2018 → |
| NAV 2017 | Extensiones v2, mejor integración con Office 365 y web client consolidado. | Upgrade intermedio a NAV 2018 o a Business Central on-premise y luego migración a la nube. |
| NAV 2015 / 2016 | Web client maduro, mejoras en Power BI y primeras extensiones. | Actualización escalonada o reimplementación, según el volumen de customizaciones. |
| NAV 2013 / 2013 R2 | Arquitectura de tres capas y web services; base de código más antigua. | Actualización escalonada con evaluación previa o reimplementación en BC. |
| NAV 2009 y anteriores | Cliente clásico y RoleTailored client, sin soporte vigente. | Reimplementación en Business Central con migración de datos y rediseño de customizaciones. |
La versión no es el único criterio: una base NAV 2016 sin customizaciones puede ser más simple de migrar que una NAV 2018 muy intervenida. Por eso el diagnóstico técnico es el primer paso de cualquier proyecto.
No hay una única forma de migrar. La ruta correcta depende de la versión, las customizaciones y el apetito de rediseño.
Para NAV 2018 y posteriores. El asistente de migración de Microsoft replica los datos on-premise hacia un entorno de Business Central online, permitiendo migrar por compañías y por etapas. Las customizaciones se reescriben como extensiones AL.
Para versiones anteriores a NAV 2018. Se actualiza primero on-premise a NAV 2018 o a una versión soportada de Business Central on-premise y, desde ahí, se migra a la nube. Conserva más código y datos, pero alarga el proyecto.
Se crea un entorno limpio de Business Central Cloud, se migran datos maestros, saldos y documentos abiertos, y se reescriben solo las customizaciones que aportan valor. Recomendada para bases antiguas o procesos a rediseñar.
| Criterio | Migración a la nube | Upgrade intermedio | Reimplementación |
|---|---|---|---|
| Versión de origen | NAV 2018 o posterior | NAV 2017 y anteriores | Cualquier versión |
| Esfuerzo de customizaciones | Medio | Alto | Medio / alto según rediseño |
| Conservación de datos | Alta | Alta | Definida por alcance |
| Tiempo relativo | Medio | Alto | Medio |
| Oportunidad de rediseño | Baja | Baja | Alta |
En NAV las customizaciones se hacían, en general, modificando objetos base: tablas, páginas, codeunits y reports. Ese modelo no es compatible con Business Central Cloud, donde el código base está bloqueado y toda extensión debe ser independiente y actualizable.
Durante la auditoría cada modificación C/AL se clasifica en una de estas categorías:
Este análisis evita reescribir código innecesario y es la base de la estimación de esfuerzo. Se profundiza en la página de desarrollo de extensiones AL.
"Line Discount %" :=
GetCustomerDiscount("Sell-to Customer No.");
AL — Business Central (extension)
codeunit 50100 "VPC Sales Discount"
{
[EventSubscriber(ObjectType::Table,
Database::"Sales Line",
'OnAfterValidateEvent', 'Quantity',
false, false)]
local procedure ApplyDiscountOnQuantity(
var Rec: Record "Sales Line")
begin
Rec."Line Discount %" :=
GetCustomerDiscount(Rec."Sell-to Customer No.");
end;
local procedure GetCustomerDiscount(
CustomerNo: Code[20]): Decimal
var
Customer: Record Customer;
begin
if Customer.Get(CustomerNo) then
exit(Customer."VPC Discount %");
exit(0);
end;
}
En lugar de modificar la tabla base, la lógica se engancha con un evento y los campos nuevos se agregan desde una extensión.
La conversión automática es un punto de partida, no el resultado final. El valor está en la refactorización.
Los objetos C/AL se exportan como texto y se convierten a sintaxis AL con la herramienta txt2al de Microsoft. El resultado se revisa objeto por objeto.
txt2al --source="C:\NAV\Objects" --target="C:\BC\AL" --rename
El código AL se valida con analizadores estáticos y pruebas antes de publicarse en el entorno de Business Central.
tableextension 50101 "VPC Customer Ext"
extends Customer
{
fields
{
field(50100; "VPC Discount %"; Decimal)
{
Caption = 'Descuento VPC %';
DecimalPlaces = 0 : 2;
}
}
}
La conversión automática no resuelve la dependencia con add-ons de terceros, los cambios profundos en posting ni las integraciones. Esos puntos se tratan como desarrollos específicos dentro del plan de migración.
El alcance de datos se define con el negocio, no solo con TI. Todo lo que se migra debe conciliarse antes del go-live.
| Tipo de dato | ¿Se migra? | Método habitual |
|---|---|---|
| Maestros (clientes, proveedores, productos, cuentas) | Sí | Paquetes de configuración (RapidStart), Excel/CSV o API |
| Configuración (impuestos, dimensiones, series, almacenes) | Sí | Paquetes de configuración y plantillas |
| Saldos de apertura (contables, inventario, cuentas corrientes) | Sí | Asientos de apertura y conciliación contable |
| Documentos abiertos (pedidos, facturas pendientes) | Sí | Migración de cabeceras y líneas con estado |
| Histórico detallado de movimientos | Según alcance | Migración completa o resumida, según volumen y necesidad de consulta |
| Adjuntos y documentos | Según alcance | SharePoint, OneDrive o almacenamiento externo |
Para NAV 2018 y posteriores, el asistente de migración a la nube replica la base on-premise y permite copiar compañías completas. Para reimplementaciones, los paquetes de configuración cargan maestros y la apertura se registra con asientos. Los datos masivos pueden migrarse con codeunits y APIs.
Los reportes se convierten, 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 pueden complementarse 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.
En la nube no hay acceso directo a la base de datos. 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 | En Business Central Cloud |
|---|---|
| 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 |
Se profundiza en apps e integraciones móviles y cloud y en la sección de integraciones de servicios.
Cada fase tiene criterios de aceptación. Nada llega a producción sin validación funcional y de datos.
El testing no es una etapa aislada: acompaña cada fase. Cuanto antes se detecten diferencias funcionales o de datos, menor es el riesgo en el cutover.
El objetivo es que la operación se detenga lo mínimo y que el corte sea reversible.
Con el asistente de migración y replicación incremental, el corte final se reduce a una ventana acotada: típicamente una noche o un fin de semana. Cuanto mayor sea el volumen de datos y más integraciones haya que reconectar, mayor es la ventana necesaria.
La migración por fases permite validar en paralelo y llegar al corte con el menor riesgo posible. El downtime no depende solo de la tecnología: también influye el tiempo de validación del negocio.
Estimaciones orientativas por fase. El rango final depende del alcance.
| Fase | Duración estimada |
|---|---|
| Diagnóstico y planificación | 1 a 3 semanas |
| Conversión de customizaciones C/AL a AL | 3 a 8 semanas |
| Migración y validación de datos | 2 a 6 semanas |
| Testing y UAT | 2 a 4 semanas |
| Cutover y estabilización | 1 a 2 semanas |
Una migración estándar suele ubicarse entre 4 y 12 semanas en total, con fases que pueden solaparse. Bases con muchas customizaciones, integraciones complejas o histórico extenso requieren más tiempo. Estas cifras son estimaciones de planificación, no compromisos de plazo: el cronograma se confirma después del diagnóstico.
No existe un precio único. El costo se compone de licencias y de servicios, y depende de estos factores.
| Factor | Impacto en el costo |
|---|---|
| Cantidad de usuarios y edición (Essentials o Premium) | Suscripción mensual o anual por usuario |
| Volumen y complejidad de customizaciones C/AL | Horas de reescritura, refactorización y testing |
| Integraciones a rehacer | Desarrollo de APIs, automatizaciones y autenticación |
| Alcance de datos e histórico a migrar | Esfuerzo de migración, conciliación y validación |
| Localización fiscal y reportes regulatorios | Extensiones locales y cumplimiento |
| Capacitación y soporte post go-live | Horas de formación y acompañamiento |
Business Central Cloud se contrata por suscripción, no con licencia perpetua. Microsoft publica programas de transición para clientes de NAV. El costo de licencias depende de la cantidad de usuarios y de la edición contratada.
Ver precios de Business CentralEl servicio incluye auditoría, conversión de customizaciones, migración de datos, reportes, integraciones, testing y cutover. Se cotiza por alcance y por fases, para que sepas qué se entrega en cada etapa.
Solicitar cotizaciónUn proceso por fases, con validaciones y entregables en cada etapa.
Relevamiento de versión, módulos, objetos C/AL, add-ons, integraciones y datos. Entregable: informe de viabilidad y ruta recomendada.
Alcance, cronograma por fases, prioridades, criterios de aceptación y plan de datos. Entregable: plan de migración.
Reescritura de customizaciones a extensiones AL, conversión de reportes y refactorización sobre eventos. Entregable: extensión publicable.
Carga de maestros, configuración, saldos y documentos abiertos, con conciliaciones. Entregable: datos validados.
Pruebas unitarias, de regresión, integraciones y aceptación de usuarios. Entregable: acta de validación.
Corte, apertura en producción, capacitación y acompañamiento post go-live. Entregable: operación estabilizada.
Sí. NAV 2018 y las versiones posteriores cuentan con ruta oficial de migración a Business Central online. Las versiones anteriores (NAV 2017, 2016, 2015, 2013, 2013 R2 y 2009) requieren una actualización intermedia a NAV 2018 o a Business Central on-premise, o bien una reimplementación. La viabilidad se confirma en la auditoría inicial.
La migración directa con las herramientas de Microsoft está prevista para NAV 2018 y posteriores. Las versiones más antiguas se migran mediante actualización escalonada o reimplementación. La decisión depende del grado de personalización C/AL, las integraciones y la calidad de la base de datos.
Existen tres rutas principales: migración a la nube con el asistente de Microsoft (NAV 2018 o posterior), actualización intermedia on-premise y posterior migración, o reimplementación en Business Central Cloud. La ruta se define según versión, customizaciones, integraciones y volumen de datos.
Se clasifican y se reescriben como extensiones AL. Las modificaciones sobre objetos base de NAV no se pueden migrar tal cual a Business Central Cloud, porque en la nube no se permite modificar el código base. Se reemplazan por table extensions, page extensions y event subscribers.
Parcialmente. La herramienta txt2al convierte objetos C/AL exportados en texto a sintaxis AL y sirve como punto de partida, pero el resultado debe refactorizarse manualmente: eventos, extensiones, permisos y validación con analizadores como CodeCop y AppSourceCop.
Se migran datos maestros, configuración, saldos de apertura y documentos abiertos. El histórico detallado puede migrarse completo o resumido según volumen, necesidad de consulta y coste. La integridad se valida con conciliaciones antes del go-live.
En Business Central Cloud no hay acceso directo a la base de datos SQL. Las integraciones se rehacen con la API v2.0 (REST), OData v4, APIs personalizadas, webhooks, Power Automate o Azure Logic Apps, revisando autenticación con Entra ID y formatos de intercambio.
Los reportes C/AL se convierten en objetos report de AL. Los layouts RDLC y Word suelen poder reutilizarse con ajustes y los datasets se reconstruyen. Algunos reportes propios se reemplazan por reportes estándar con report extension, y la analítica puede migrarse a Power BI.
Una migración estándar suele estimarse entre 4 y 12 semanas. El rango depende del tamaño de la base, la cantidad y complejidad de customizaciones, las integraciones y el alcance del histórico. El proyecto se planifica por fases con validaciones.
Depende del alcance: cantidad de usuarios y licencias, volumen de customizaciones C/AL, integraciones, datos a migrar, localización fiscal y capacitación. No hay un precio único; se cotiza después del diagnóstico inicial.
El downtime se concentra en el cutover final. Con replicación incremental y migración por fases, la ventana de corte suele limitarse a noches o fin de semana, según el volumen de datos y las validaciones previas.
Business Central Cloud funciona con suscripción por usuario, no con licencia perpetua. Microsoft publica programas de transición para clientes de NAV. El coste de licencias se define según cantidad de usuarios y edición (Essentials o Premium).
Ruta técnica específica desde NAV 2018: upgrade on-premises, C/AL a AL, datos, SQL, reportes y cutover.
Ver guía NAV 2018 →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 →Factura electrónica ARCA (ex AFIP) integrada con Business Central para Argentina.
Ver Facturación ARCA →