De Navision a Microsoft Dynamics 365 Business Central: cuándo y cómo abordar la migración
Seguir utilizando Navision o una versión antigua de Dynamics NAV no significa necesariamente que el sistema haya dejado de funcionar. El verdadero problema aparece cuando el ERP deja de acompañar al negocio: cuesta actualizarlo, depende de desarrollos difíciles de mantener, limita las integraciones y convierte cualquier cambio en un proyecto de riesgo. Migrar a Dynamics 365 Business Central permite modernizar la plataforma, pero exige tomar decisiones sobre procesos, datos y personalizaciones antes de mover una sola tabla.
Muchas empresas llevan años trabajando con Navision. Conocen el sistema, han adaptado sus procesos a él y disponen de desarrollos que resuelven necesidades específicas. Precisamente por eso, la decisión de migrar suele aplazarse: el ERP actual “todavía funciona” y existe temor a perder información, funcionalidad o estabilidad.
Sin embargo, el coste de mantener una plataforma antigua no siempre aparece de forma visible en una factura. Se manifiesta en tiempos de respuesta, dependencia de perfiles concretos, dificultad para integrar nuevas aplicaciones, falta de movilidad, procesos manuales, problemas de seguridad, imposibilidad de aprovechar capacidades cloud y retrasos en iniciativas de datos o inteligencia artificial.
De Navision a Dynamics 365 Business Central: la evolución del ERP de Microsoft
Navision fue el nombre con el que muchas empresas conocieron el ERP que posteriormente evolucionó a Microsoft Dynamics NAV. Con el desarrollo de la estrategia cloud de Microsoft, la solución continuó su evolución hasta Dynamics 365 Business Central, la plataforma de gestión empresarial para pequeñas y medianas organizaciones.
Business Central mantiene la lógica de un ERP integral para finanzas y operaciones, pero introduce una arquitectura, un modelo de extensiones y una experiencia de servicio propios de una plataforma moderna. Integra finanzas, compras, ventas, inventario, proyectos, servicios y capacidades de fabricación o almacén, y se conecta de forma nativa con Microsoft 365, Power Platform, Power BI y el ecosistema de aplicaciones de Microsoft.
¿Por qué migrar si Navision todavía funciona?
La pregunta correcta no es si Navision arranca cada mañana. Es si la plataforma actual permite a la empresa competir, crecer y cambiar con la velocidad necesaria. Estas son algunas razones habituales para abordar la migración:
- La versión está fuera de soporte o requiere una infraestructura difícil de mantener.
- Las personalizaciones en C/AL dependen de conocimiento escaso o de desarrollos poco documentados.
- Cada actualización implica un proyecto costoso y arriesgado.
- Los usuarios necesitan acceso seguro desde diferentes ubicaciones y dispositivos.
- La empresa quiere integrarse mejor con Outlook, Excel, Teams, Power Automate o Power BI.
- Existen demasiados procesos paralelos en hojas de cálculo o aplicaciones externas.
- La organización necesita automatización, analítica avanzada o inteligencia artificial.
- El crecimiento, la internacionalización o nuevas líneas de negocio exigen mayor escalabilidad.
También hay un motivo estratégico: la innovación de Microsoft se concentra en las versiones actuales y en la nube. Mantener una solución antigua puede ser viable durante un tiempo, pero cada año aumenta la distancia respecto a nuevas funcionalidades, modelos de seguridad, conectividad y capacidades de IA.
Migración, actualización o reimplantación: no son exactamente lo mismo
En una conversación empresarial se utilizan a menudo como sinónimos, pero conviene distinguir tres enfoques:
Actualización técnica
Consiste en llevar la solución a versiones posteriores manteniendo gran parte de la estructura, datos y funcionalidad. Puede ser necesaria como paso intermedio dentro de una ruta soportada, pero no garantiza por sí sola que se hayan simplificado procesos o eliminado personalizaciones obsoletas.
Migración completa
Busca trasladar datos y funcionalidad a Business Central online. Microsoft establece que las personalizaciones en código C/AL deben convertirse a extensiones AL. Además, los datos asociados a tablas con personalizaciones de código no pueden trasladarse correctamente si esas personalizaciones no se han transformado y están disponibles en los entornos de origen y destino.
Reimplantación o enfoque “clean start”
Consiste en configurar Business Central con un diseño más estandarizado y migrar únicamente la información necesaria: maestros, saldos, configuración y, cuando proceda, una selección de históricos. Este enfoque evita trasladar todo el legado y puede ser recomendable cuando la solución actual acumula desarrollos, datos o procesos que ya no aportan valor.
Microsoft documenta actualmente dos grandes rutas desde Dynamics NAV: migración completa y reimplantación. Ambas requieren analizar la versión de partida y, en determinados escenarios, pasar primero por Business Central on-premises antes de completar el salto a Business Central online.
Las rutas de migración dependen de la versión de origen
No todas las versiones de Navision o Dynamics NAV pueden migrar directamente a la nube. Microsoft establece rutas soportadas que incluyen versiones intermedias. Por ejemplo, las versiones Dynamics NAV 2015 a 2018 deben pasar por Business Central 14 on-premises y posteriormente por una versión moderna de Business Central on-premises antes de migrar a Business Central online en una migración completa.
Las versiones anteriores requieren más escalones. Dynamics NAV 2013 puede necesitar pasar por NAV 2018; NAV 2009 puede requerir primero NAV 2013 o 2015 y después NAV 2018. Por eso no es recomendable estimar el proyecto basándose únicamente en el número de usuarios o en el tamaño de la base de datos. La versión, las personalizaciones y la arquitectura técnica condicionan de manera decisiva el esfuerzo.
El gran reto: las personalizaciones heredadas
Durante años, muchas implantaciones de Navision se diferenciaron mediante modificaciones directas sobre el código base. Este enfoque permitía adaptar profundamente la aplicación, pero complicaba las actualizaciones. Business Central online utiliza un modelo de extensiones. Las personalizaciones deben desacoplarse del núcleo y convertirse a extensiones AL.
Antes de convertir cada desarrollo, conviene clasificarlo:
- Imprescindible: responde a un requisito legal o a una ventaja operativa real.
- Sustituible por estándar: Business Central ya cubre la necesidad de otra manera.
- Sustituible por una aplicación disponible en AppSource o por una extensión moderna.
- Obsoleto: se creó para un proceso, integración o normativa que ya no existe.
- Rediseñable: resuelve una necesidad válida, pero mediante un proceso innecesariamente complejo.
Migrar todo sin cuestionarlo suele ser el error más caro. Una personalización antigua no es automáticamente un requisito actual. La migración ofrece una oportunidad para reducir deuda técnica y recuperar capacidad de actualización.
¿Qué datos deben migrarse?
La respuesta “todos” parece prudente, pero no siempre lo es. Migrar años de históricos, registros duplicados, maestros inactivos y datos inconsistentes aumenta tiempo, coste y riesgo. La decisión debe responder a necesidades operativas, legales, de auditoría y analítica.
El análisis debería clasificar los datos en cuatro grupos:
- Datos maestros activos: clientes, proveedores, productos, cuentas, dimensiones y configuraciones.
- Saldos y operaciones abiertas: facturas pendientes, pedidos, inventario, bancos y compromisos.
- Histórico necesario en el nuevo sistema: información que los usuarios deben consultar o procesar.
- Histórico que puede conservarse en un repositorio de consulta o plataforma analítica sin trasladarlo al ERP operativo.
Una estrategia híbrida puede mantener el nuevo ERP limpio y, al mismo tiempo, conservar acceso gobernado a la información histórica mediante Power BI, Fabric u otros repositorios.
Fases recomendadas de una migración a Business Central
- Diagnóstico de la versión, infraestructura, base de datos, licencias y soporte actual.
- Inventario de personalizaciones, informes, integraciones y procesos paralelos.
- Definición del modelo objetivo y decisión entre migración completa o reimplantación.
- Diseño de datos: qué se migra, qué se depura y qué se conserva fuera del ERP.
- Conversión o sustitución de personalizaciones y desarrollo de extensiones AL.
- Configuración de Business Central, roles, seguridad e integraciones.
- Migraciones de prueba y validación funcional con usuarios clave.
- Formación y gestión del cambio.
- Ensayo completo del cutover en un entorno sandbox.
- Puesta en producción, soporte intensivo y optimización posterior.
Microsoft recomienda realizar al menos un ensayo completo de migración antes del corte productivo. Los dry runs permiten detectar incidencias, medir tiempos y validar resultados con usuarios de negocio antes de comprometer el arranque definitivo.
Riesgos habituales y cómo reducirlos
Querer replicar el sistema antiguo al cien por cien
Esta decisión traslada la deuda técnica y elimina gran parte del beneficio de modernizar. La solución es analizar el propósito de cada personalización y contrastarla con el estándar actual.
Subestimar la calidad de los datos
Los problemas de duplicidad, codificación o falta de consistencia aparecen durante las pruebas. Debe reservarse tiempo para depuración, criterios de migración y responsables de validar cada dominio de datos.
Dejar a los usuarios para el final
La adopción no se resuelve con una sesión de formación el día anterior al arranque. Los usuarios clave deben participar en diseño, pruebas y validación de procesos.
No realizar ensayos de corte
Sin un ensayo completo es difícil estimar tiempos, secuencias y dependencias. El cutover debe documentarse y probarse como un proceso operativo crítico.
Tratar la migración como un proyecto exclusivamente técnico
La migración cambia procesos, responsabilidades y formas de trabajar. Necesita gobierno, decisiones de negocio y una comunicación clara sobre objetivos y beneficios.
Qué aporta Business Central después de la migración
- Una plataforma cloud accesible y administrada como servicio.
- Actualizaciones periódicas y una arquitectura de extensiones más sostenible.
- Integración con Microsoft 365, Power Platform, Power BI y servicios Microsoft.
- Mayor facilidad para automatizar procesos y aprobaciones.
- Capacidad para incorporar aplicaciones sectoriales y funcionalidad adicional.
- Una base más adecuada para analítica, Copilot y agentes de inteligencia artificial.
- Escalabilidad para acompañar el crecimiento y nuevas necesidades.
¿Cuándo es mejor no retrasar más la decisión?
La urgencia aumenta cuando la versión está fuera de soporte, hay problemas de seguridad o infraestructura, faltan perfiles capaces de mantener el sistema, se aproxima un cambio societario o regulatorio, o la plataforma está bloqueando iniciativas estratégicas. También es recomendable anticiparse a una fecha límite: una migración planificada ofrece más opciones que una sustitución forzada por una incidencia o incompatibilidad.
¿Por qué realizar la migración con EQM?
Una migración desde Navision requiere conocimiento del legado y capacidad para diseñar la solución futura. EQM cuenta con experiencia contrastada en implantaciones ERP para pymes y empresas en expansión, y combina visión funcional, conocimiento tecnológico, metodología y acompañamiento.
El objetivo es evaluar la versión actual, las personalizaciones, los datos y las integraciones para construir una ruta realista. No se trata de mover el pasado a la nube, sino de conservar lo que aporta valor y preparar la empresa para trabajar mejor en los próximos años.
¿Sigues trabajando con Navision o Dynamics NAV?
Solicita a EQM una evaluación de tu versión, personalizaciones, datos, integraciones y necesidades futuras.
Obtendrás una primera visión de la ruta de migración y de las decisiones
que conviene tomar antes de iniciar el proyecto.
Preguntas frecuentes
Las preguntas más habituales sobre la migración de Navision a Business Central
¿Navision y Business Central son el mismo producto?
Business Central es la evolución del ERP que muchas empresas conocieron como Navision y posteriormente como Dynamics NAV, pero incorpora una arquitectura, un modelo cloud y un sistema de extensiones diferentes.
¿Se puede migrar directamente desde cualquier versión de Navision?
No. Las versiones antiguas requieren rutas de actualización intermedias. La ruta exacta depende de la versión de origen y del enfoque de migración.
¿Es obligatorio migrar todo el histórico?
No. Puede migrarse la información necesaria para operar y conservar determinados históricos en un repositorio de consulta o plataforma analítica, de acuerdo con las necesidades legales y de negocio.
¿Cuánto dura una migración?
Depende de la versión, personalizaciones, volumen y calidad de datos, integraciones, alcance y disponibilidad de usuarios. Un diagnóstico previo es imprescindible para estimar plazos con rigor.
¿Se puede seguir trabajando con Navision durante la preparación?
Sí. Normalmente el sistema de origen continúa operativo mientras se configura y prueba Business Central. El cambio se completa durante un cutover planificado.
¿Qué diferencia hay entre migración completa y reimplantación?
La migración completa busca trasladar datos y funcionalidad. La reimplantación configura un entorno más limpio y migra datos esenciales, evitando cargar con personalizaciones e históricos innecesarios.
