Migrar NAV a Business Central en industria: moderniza el ERP sin trasladar la deuda a la nube
Versiones, C/AL, extensiones AL, datos, históricos, fabricación, MRP, escandallos, rutas, almacén, costes, integraciones, pruebas, cutover y una arquitectura preparada para Power BI, Power Platform, Copilot y agentes.
Migrar de Dynamics NAV o Navision a Business Central no debería ser una mudanza técnica. En industria es una decisión sobre cómo vas a fabricar, planificar, comprar, controlar inventario, registrar costes y utilizar datos durante los próximos años. El proyecto crea valor cuando elimina personalizaciones sin sentido, sanea maestros, rediseña procesos y deja un ERP más estándar y conectable. Si se copia todo, puedes terminar pagando cloud para seguir trabajando exactamente como antes.
“NAV funciona” no significa que el modelo actual merezca migrarse
Muchos NAV industriales funcionan porque la organización ha construido durante años una capa humana alrededor del ERP. Compras conoce los artículos que no debe planificar. Producción ajusta prioridades en Excel. Finanzas corrige cierres con informes propios. Almacén interpreta diferencias que el sistema no explica. Un desarrollador histórico sabe qué personalización no debe tocarse.
Ese conocimiento puede ser valioso, pero también puede esconder deuda. Una migración que se limita a convertir objetos y copiar tablas preserva la dependencia y la hace más cara. Business Central online está diseñado alrededor de una aplicación estándar actualizable y extensiones AL. El proyecto debe utilizar esa arquitectura para reducir acoplamiento, no para reconstruir C/SIDE en la nube.
La pregunta correcta no es “¿cómo migramos esta personalización?”. Primero es “¿qué problema resolvía, sigue existiendo y existe ahora una capacidad estándar, una app, Power Platform o una forma mejor de resolverlo?”. Solo después se decide si merece convertirse a AL.
En industria esta revisión es especialmente importante porque las personalizaciones suelen estar conectadas con planificación, fabricación, trazabilidad, almacén y coste. No se pueden eliminar por entusiasmo cloud. Hay que entender el proceso que protegen.
En 2026, un NAV antiguo no salta directamente a Business Central online
Microsoft mantiene una ruta específica para migrar NAV a Business Central online. Las versiones anteriores a Business Central 14 no pueden utilizar directamente la migración cloud: primero deben actualizarse a una versión de Business Central on-premises soportada y convertir las personalizaciones para trabajar con el modelo de extensiones.
El itinerario concreto depende de la versión inicial. Para NAV 2015–2018, por ejemplo, Microsoft documenta una ruta estándar que pasa por Business Central 14 on-premises, después por una versión on-premises moderna soportada y finalmente Business Central online. Esto hace que el diagnóstico de versión y customizaciones sea una fase técnica crítica antes de presupuestar.
Identificar versión y ruta
NAV 2013, 2015, 2016, 2017, 2018 o un Business Central on-premises no tienen exactamente el mismo recorrido técnico.
Actualizar on-premises
Las versiones antiguas necesitan alcanzar una versión intermedia y después una versión soportada para la migración online.
Convertir personalizaciones
C/AL y modificaciones directas deben evolucionar hacia apps y extensiones AL o desaparecer si ya no aportan valor.
Preparar online
Tenant, sandbox, extensiones, permisos, compañías, configuración y prerrequisitos de migración.
Replicar y validar
Utilizar las herramientas de cloud migration, revisar errores, repetir replicaciones y validar datos y extensiones.
Cutover a online
Última replicación, controles, usuarios, notas/enlaces, integraciones, apertura y soporte intensivo.
La migración de código es una oportunidad para dejar de modificar el ERP base
Business Central 2026 release wave 1 corresponde a la versión 28 y continúa el modelo completamente basado en AL. Microsoft abandonó C/AL como lenguaje de personalización del producto moderno y el enfoque actual se basa en extensiones. Esto cambia la arquitectura: en lugar de modificar objetos estándar, las personalizaciones deben añadirse de forma desacoplada mediante eventos, extensiones, APIs y aplicaciones.
No todo objeto C/AL merece convertirse línea por línea. Un análisis de personalizaciones debe clasificar cada pieza según valor, uso, sustitución estándar y coste de mantenimiento futuro.
Cada desarrollo debería terminar en una decisión explícita
Un inventario técnico sin decisión de negocio es insuficiente. Conviene mapear quién usa cada desarrollo, qué proceso soporta, qué frecuencia tiene, qué riesgo tendría perderlo y qué alternativa existe en el modelo objetivo.
| Situación | Decisión habitual | Qué validar | Impacto futuro |
|---|---|---|---|
| Sin uso real | Eliminar. | Telemetría, usuarios y owner. | Reduce superficie de migración. |
| Función ya estándar | Adoptar estándar. | Gap funcional y cambio de proceso. | Menor mantenimiento. |
| Proceso periférico | Power Platform / app. | Dato maestro, seguridad e integración. | Core más limpio. |
| Diferenciación sectorial | Extensión AL. | Arquitectura, eventos, test y upgrade. | Mantener valor sin modificar base. |
| Integración crítica | API / Azure / conector. | Contrato, volumen, errores y seguridad. | Menor acoplamiento. |
Migrar todo el histórico no es sinónimo de conservar conocimiento
Los datos tienen objetivos distintos: algunos son necesarios para operar, otros para cumplimiento, otros para análisis y otros apenas se consultan. Forzar décadas de información al nuevo ERP puede aumentar coste, pruebas y ruido sin aportar valor. La estrategia debe separar dato operativo, histórico analítico y archivo.
Maestros activos
Clientes, proveedores, artículos, BOM, rutas, ubicaciones y parámetros deben migrar saneados.
Saldos y abiertos
Contabilidad, cartera, pedidos, compras, stock y operaciones necesarias para continuar el negocio.
Histórico relevante
Decidir años y granularidad según consulta operativa, auditoría, servicio y analítica.
Archivo
Información que debe conservarse pero no necesita vivir como dato operativo en Business Central.
Power BI / Fabric
Histórico analítico puede mantenerse disponible para tendencias sin sobrecargar el modelo transaccional.
Calidad
Duplicados, unidades, referencias, nombres, dimensiones y relaciones deben corregirse antes del cutover.
La parte difícil no es mover empresas y asientos: es validar que la fábrica sigue funcionando de extremo a extremo
En una empresa industrial, el go-live depende de cadenas largas. Un pedido genera demanda; MRP propone suministro; compras recibe material; almacén lo ubica; producción consume componentes y capacidad; el producto termina; se expide; se factura; el coste impacta en inventario y contabilidad. Un fallo pequeño en un maestro puede romper varias etapas después.
Una migración limpia empieza antes de cargar el primer artículo
El esfuerzo de datos suele subestimarse porque “ya están en NAV”. Pero la migración hace visibles años de excepciones. El objetivo no es conseguir que todos los registros entren; es conseguir que el nuevo sistema pueda planificar y costear con ellos.
Artículos
Activo/inactivo, unidades, familia, aprovisionamiento, coste, tracking, lead time y política de planificación.
BOM
Componentes, cantidades, versiones, semielaborados, sustituciones y mermas.
Rutas
Operaciones, secuencia, setup, run time, centros, máquinas y calendarios.
Proveedores
Estado, referencias, plazos, condiciones, divisa, compra y calidad del dato.
Ubicaciones
Almacenes, bins, stock, picking, movimientos y disponibilidad real.
Dimensiones
Centro, familia, línea, proyecto, planta u otras estructuras necesarias para gestión y reporting.
Clasifica cada informe por su función antes de reconstruirlo
Documento transaccional
Factura, albarán, pedido, etiqueta o documento que pertenece al proceso operativo y debe resolverse en Business Central.
Control operativo
Listados de pendientes, órdenes, recepciones o excepciones pueden resolverse con páginas, vistas, consultas o Power BI según uso.
Análisis de gestión
Margen, stock, producción, servicio y proveedores deberían evolucionar hacia métricas comunes y modelos Power BI.
Histórico
Informes usados solo para consulta histórica pueden resolverse sobre archivo o plataforma de datos sin cargarlos como transacción viva.
La migración debe reducir conexiones directas a tablas y aumentar contratos de integración mantenibles
NAV suele acumular integraciones que leen o escriben directamente en SQL, intercambios de ficheros, procesos batch y lógica dentro del propio ERP. Business Central online cambia ese paradigma. APIs, web services, Power Platform y Azure permiten diseñar conexiones más desacopladas y compatibles con actualizaciones continuas.
Replicar datos varias veces reduce el riesgo del fin de semana de arranque
Las herramientas de migración cloud de Business Central permiten replicar datos desde el entorno on-premises hacia Business Central online, revisar incidencias y repetir la replicación durante el proyecto. Esto facilita ensayos, validación y preparación del cutover.
Durante el periodo de migración hay que controlar qué información se introduce en el entorno online, porque los datos incluidos en la replicación pueden sobrescribirse. El plan debe definir con precisión qué sistema es productivo hasta el corte y cuándo deja de permitirse actividad en NAV.
Sandbox de migración
Instalar extensiones, replicar compañías y validar problemas antes de acercarse al corte productivo.
Dry run
Medir duración, errores, reconciliación, tareas manuales y dependencias para convertir el cutover en un procedimiento ensayado.
Reconciliación
Saldos, stock, abiertos, lotes, órdenes, documentos y registros clave deben compararse con criterios definidos.
Última replicación
Cierre de actividad, backup, sincronización final, validaciones, usuarios, integraciones y apertura controlada.
UAT no es comprobar que una pantalla abre. Es demostrar que el negocio puede cerrar el ciclo completo.
Las pruebas deben cubrir los caminos normales y las excepciones que realmente consumen tiempo. En industria es importante probar con usuarios de producción, planificación, compras, almacén y finanzas, no solo con el equipo de proyecto.
Pedido a entrega
Pedido, demanda, planificación, producción, expedición, factura y margen.
Compra a consumo
Necesidad, pedido, recepción, lote, ubicación, reserva y consumo en producción.
Producción
Orden, componentes, ruta, capacidad, tiempos, scrap, output, terminación y coste.
MRP
Crear, reprogramar, cancelar y manejar excepciones de materiales y producción.
Trazabilidad
Lote o serie desde recepción hasta consumo, producción, expedición y cliente.
Cierre
Inventario, WIP, contabilidad, costes, conciliación y reporting.
Venir de NAV no obliga a elegir Business Central si la empresa ya ha superado su complejidad natural
Business Central suele ser la evolución natural para muchas compañías NAV, pero no debe decidirse por continuidad de marca. Si durante los últimos años la empresa ha crecido en plantas, países, volumen, warehouse, supply chain, gobierno corporativo o complejidad financiera, el proceso de migración es el momento de reevaluar la plataforma objetivo.
No todas las compañías deben llevar su base NAV completa por una ruta de upgrade
En algunos entornos muy personalizados, con muchos años de datos o procesos radicalmente distintos, una reimplantación sobre Business Central puede ofrecer más valor que convertir todo el sistema actual. La decisión debe comparar conservación de histórico, complejidad de personalizaciones, calidad de datos, continuidad operativa, tiempo y riesgo.
| Criterio | Upgrade + cloud migration | Reimplantación |
|---|---|---|
| Histórico | Mayor continuidad de datos. | Migración selectiva y archivo. |
| Personalizaciones | Hay que convertir o retirar lógica existente. | Se rediseña desde estándar y requisitos vigentes. |
| Datos | Más carga de limpieza y compatibilidad. | Mayor oportunidad de reset controlado. |
| Proceso | Más continuidad funcional. | Mayor rediseño y cambio organizativo. |
| Encaja cuando | El modelo actual es razonablemente sano y merece conservarse. | La mayor parte del entorno representa deuda o una realidad que ya cambió. |
El arranque debe diseñarse como una operación empresarial, no como una tarea del equipo IT
Producción no puede quedar detenida porque falte una secuencia de carga, un certificado, una etiqueta, una interfaz o un permiso. El plan de cutover debe tener responsables, horarios, criterios de go/no-go y procedimientos de contingencia.
Freeze
Definir cuándo deja de cambiar configuración, código y maestros antes del corte.
Último cierre NAV
Transacciones pendientes, inventario, producción, documentos y conciliaciones necesarias.
Migración final
Replicación, tareas manuales, extensiones y controles técnicos.
Reconciliación
Contabilidad, stock, abiertos, órdenes, lotes, costes y puntos críticos.
Integraciones
EDI, bancos, e-commerce, MES, transportistas, CRM, BI y otros sistemas deben validarse.
Hypercare
Soporte reforzado por proceso, priorización de incidencias y decisión rápida durante las primeras semanas.
El proyecto falla si Business Central es correcto y los usuarios vuelven al Excel
La adopción industrial no se resuelve con una formación genérica. Cada rol necesita entender qué cambia, qué dato es responsable de mantener, qué excepción debe registrar y cómo una mala captura afecta a otras áreas. Planner, comprador, almacenero, supervisor, operario, administración y dirección tienen responsabilidades distintas.
No intentes hacer toda la transformación antes de arrancar
Un proyecto industrial puede fracasar por intentar resolver ERP, BI, automatización, IA, integración y todos los deseos históricos a la vez. Es mejor diseñar la arquitectura completa y secuenciar valor. Primero estabilizar transacciones y datos; después mejorar reporting y procesos periféricos; finalmente escalar automatización e IA.
Estabilizar
Transacción, MRP, stock, costes, cierres, extensiones e integraciones.
Visibilizar
Power BI para margen, producción, inventario, compras, capacidad y servicio.
Automatizar
Power Apps y Power Automate para tareas periféricas, incidencias y aprobaciones.
Estructurar calidad
Quality Management y procesos complementarios cuando calidad necesita más profundidad.
Introducir IA
Copilot y agentes sobre procesos y datos que ya han demostrado suficiente fiabilidad.
Escalar arquitectura
Fabric, Azure y agentes de mayor complejidad cuando el caso de negocio lo justifica.
Doce decisiones que pueden convertir una migración NAV en varios años de deuda nueva
Migrar todo el histórico
Aumenta pruebas, volumen y ruido aunque apenas se consulte.
Convertir todo el C/AL
Reconstruye parches antiguos y perpetúa mantenimiento innecesario.
No limpiar maestros
El nuevo MRP y el nuevo reporting nacen con la misma desconfianza.
Copiar el proceso NAV
Impide aprovechar estándar y obliga a adaptar Business Central a hábitos históricos.
Dejar costes al final
Producción puede arrancar sin una referencia fiable de valoración y margen.
Diseñar sin planta
El sistema puede ser correcto en oficina y fracasar en captura y ejecución.
No ensayar cutover
El primer cálculo real de tiempo y dependencias llega demasiado tarde.
Integraciones directas a SQL
Recrear el patrón on-premises impide aprovechar la arquitectura cloud.
No retirar Excel
Los usuarios mantienen dos sistemas y el dato vuelve a divergir.
No revisar BC vs F&O
La empresa puede forzar Business Central aunque su escala haya cambiado.
Hacer BI después
Sin diseño de dimensiones y semántica, el reporting vuelve a depender de reconstrucciones.
IA como decoración
Añadir Copilot sobre datos y procesos débiles no crea una empresa más inteligente.
Una migración bien hecha deja Business Central listo para calidad, datos y agentes sin volver a rediseñar el núcleo
Business Central 2026 sigue ampliando capacidades de supply chain, Copilot y agentes. Microsoft ha introducido además Quality Management, que permite crear inspecciones en compra, producción, ensamblaje y almacén. La compañía que migra hoy debería tener en cuenta este destino aunque no active todas las capacidades en el primer go-live.
La preparación no consiste en “añadir IA” al alcance. Consiste en dejar maestros limpios, APIs correctas, permisos coherentes, procesos trazables y reporting estructurado para que el siguiente caso no necesite reconstruir la base.
Una migración industrial debería cerrar decisiones en este orden
Assessment
Versión, arquitectura, usuarios, módulos, datos, customizaciones, integraciones, volumen y dolores.
Modelo futuro
Business Central vs F&O, procesos, estándar, extensiones, apps, integración y datos.
Depuración
Maestros, históricos, personalizaciones, informes, Excel y procesos redundantes.
Construcción
Configuración, extensiones AL, apps, APIs, migración y reporting esencial.
Pruebas
End-to-end industrial, integración, datos, rendimiento, seguridad y cierre.
Cutover
Ensayo, freeze, replicación final, reconciliación, usuarios e integraciones.
Hypercare
Soporte intensivo, clasificación de incidencias, adopción y ajuste de parámetros.
Optimización
MRP, stock, costes, BI, automatización y calidad sobre datos reales.
IA y agentes
Casos de uso con impacto y guardrails una vez estabilizada la base operativa.
CYCASA: cuando el entorno NAV ya no debía seguir parcheándose
CYCASA ofrece una referencia muy útil porque el punto de partida está claramente documentado: trabajaba sobre un entorno NAV desactualizado y una versión anterior de su vertical. Rendimiento, soporte y nuevos requisitos fiscales y tecnológicos hacían que la evolución dejara de ser opcional. El proyecto partió de una auditoría y terminó en una reimplantación de IB Building 365 sobre Business Central.
NAV desactualizado y plataforma sectorial anterior
La tecnología ya no respondía con suficiente rendimiento, soporte y adaptación a nuevas necesidades del negocio.
Auditar y reimplantar
La referencia demuestra que no todo entorno debe “actualizarse tal cual”: en algunos casos una reimplantación es el camino más limpio para modernizar.
Business Central como base cloud más preparada para evolucionar
La compañía obtuvo una plataforma más alineada con sus necesidades actuales, con mejor acceso a información y mayor capacidad de control y evolución.
Migrar NAV en industria exige combinar arquitectura técnica y conocimiento real del proceso
Una migración cruza Business Central, fabricación, finanzas, datos, AL, integraciones, Power BI, Power Platform, Azure, seguridad y adopción. Ayesa puede trabajar estas disciplinas dentro de un único programa para que las decisiones técnicas no contradigan el modelo operativo.
Profundiza donde tu migración tiene más riesgo
Preguntas sobre migrar NAV a Business Central en industria
¿Se puede migrar NAV directamente a Business Central online?
Depende de la versión. Microsoft indica que versiones NAV anteriores a Business Central 14 no pueden migrar directamente a cloud y requieren primero un upgrade on-premises soportado.
¿Qué pasa con NAV 2015, 2016, 2017 o 2018?
Microsoft documenta una ruta estándar que pasa por Business Central 14 on-premises, después por una versión on-premises moderna soportada y finalmente Business Central online.
¿Qué ocurre con las personalizaciones C/AL?
Deben evaluarse y, cuando sigan siendo necesarias, convertirse al modelo de extensiones AL. Muchas deberían eliminarse, sustituirse por estándar o trasladarse a otra capa.
¿Hay que migrar todos los históricos?
No. Debe decidirse según necesidad operativa, legal, auditoría y analítica. Parte del histórico puede conservarse fuera del ERP productivo.
¿Conviene hacer upgrade o reimplantación?
Depende de deuda, datos y procesos. Si gran parte del NAV actual sigue siendo válida puede encajar una ruta de upgrade. Si predominan personalizaciones obsoletas y datos débiles, una reimplantación puede ser más limpia.
¿Business Central siempre es la evolución correcta?
No. Es la evolución natural en muchos casos, pero empresas con escala o supply chain enterprise deben comparar también Dynamics 365 Finance y Supply Chain Management.
¿Qué debemos revisar en fabricación?
BOM, rutas, work/machine centers, calendarios, consumos, producción, scrap, semielaborados, subcontratación y cierres de órdenes.
¿Qué debemos revisar en MRP?
Forecast, políticas, lead times, stocks de seguridad, lotes, reservas, BOM y calidad de inventario antes de confiar en nuevas propuestas.
¿Cómo se migran integraciones?
Conviene rediseñar accesos directos a SQL y procesos heredados utilizando APIs, extensiones AL, Power Platform o Azure según el nivel de complejidad.
¿Podemos repetir la migración de datos antes del go-live?
Sí. Las herramientas de cloud migration permiten realizar replicaciones durante el proyecto, revisar incidencias y preparar la migración final con más confianza.
¿Se puede trabajar en Business Central online mientras replica NAV?
Hay que limitar la entrada de datos que forman parte de la migración porque pueden ser sobrescritos por las replicaciones. El plan debe definir claramente cuál es el sistema productivo.
¿Qué es un dry run?
Es un ensayo completo del cutover para medir tiempo, errores, reconciliación, tareas manuales, dependencias e integraciones antes del arranque real.
¿Cuándo hay que diseñar Power BI?
Durante el proyecto debe definirse la semántica y dimensiones necesarias. La analítica avanzada puede desplegarse después, pero no conviene descubrir al final que faltan datos o estructuras.
¿Power Platform puede sustituir personalizaciones NAV?
En algunos procesos periféricos sí: aprobaciones, captura, incidencias, automatización y apps móviles pueden quedar mejor desacopladas del ERP.
¿Business Central 2026 incorpora Quality Management?
Sí. Microsoft introdujo Quality Management en 2026 release wave 1 con inspecciones para compras, producción, ensamblaje y almacén.
¿Debemos incluir IA en el primer alcance?
No necesariamente. Es más importante que la migración deje datos, procesos, APIs y permisos preparados. Los casos de IA pueden desplegarse después con menor riesgo.
¿Cuánto dura una migración?
No existe una duración estándar útil. Versión, personalizaciones, compañías, datos, fabricación, integraciones, localizaciones y alcance de rediseño cambian radicalmente el esfuerzo.
¿Por dónde empezar?
Por un assessment de versión, personalizaciones, datos, integraciones, procesos industriales y plataforma objetivo antes de comprometer calendario o presupuesto definitivo.
Antes de presupuestar la migración, averigua cuánto de tu NAV actual merece realmente llegar a Business Central
Podemos revisar versión, objetos C/AL, extensiones, datos, históricos, fabricación, MRP, almacén, costes, reporting, integraciones y crecimiento esperado para definir una ruta realista. El objetivo es reducir deuda, proteger continuidad y dejar una plataforma industrial que pueda evolucionar sin otra reimplantación dentro de pocos años.
Hablemos de tu NAV industrial y de la ruta adecuada hacia Business Central
Cuéntanos qué versión utilizas, qué áreas industriales están personalizadas, cuántas compañías tienes, qué integraciones son críticas y qué problemas quieres dejar atrás. Revisaremos primero el punto de partida y después la ruta de migración.