Migrar un ERP legacy ya no va de cambiar de software. Va de recuperar capacidad de negocio.
NAV, Navision, Dynamics AX, Axapta, un ERP propio, una solución sectorial antigua o un sistema on premise pueden seguir funcionando y, aun así, estar frenando crecimiento, integración, automatización, reporting, seguridad e IA. La migración debe resolver ese problema, no trasladarlo a otra plataforma.
El ERP antiguo puede seguir funcionando y, aun así, estar frenando a toda la compañía
Durante años, muchas empresas han mantenido su ERP porque todavía permite facturar, comprar, cerrar contabilidad o gestionar almacenes. Pero esa lectura se queda corta. Un ERP legacy puede resolver lo básico y, al mismo tiempo, bloquear crecimiento, integración, automatización, reporting, seguridad, eficiencia operativa y capacidad para aprovechar IA.
El problema aparece cuando cada mejora exige desarrollo a medida, cada integración se convierte en una excepción, cada informe requiere manipulación manual y cada proceso depende de personas que conocen una lógica histórica no documentada. En ese punto, el ERP deja de ser una plataforma de gestión y se convierte en una restricción.
Migrar a Microsoft Cloud no debería plantearse como una mudanza técnica. Debe ser una decisión de negocio: qué procesos mantener, cuáles simplificar, qué datos limpiar, qué integraciones rediseñar, qué reporting necesita dirección y qué nuevas capacidades puede activar la organización.
El equipo dedica demasiado esfuerzo a sostener el sistema, no a mejorar el negocio.
Los datos llegan tarde, se manipulan fuera del sistema o no responden a la visión de dirección.
CRM, bancos, e-commerce, nómina, BI o sistemas sectoriales se conectan con más coste y riesgo.
Copilot y los agentes necesitan procesos, permisos y datos gobernados para aportar valor real.
No migres el pasado. Decide qué merece llegar al futuro.
La mayor oportunidad de una migración ERP no está en reproducir pantallas antiguas. Está en eliminar deuda técnica, simplificar procesos, limpiar datos, revisar integraciones y construir una arquitectura capaz de evolucionar sin volver a quedar atrapada.
Cada ERP antiguo exige una estrategia distinta
El punto de partida determina alcance, coste, plan de datos, integraciones, arquitectura futura y nivel de riesgo. Copiar una receta de otro proyecto suele ser la forma más rápida de trasladar la deuda técnica al sistema nuevo.
Para muchas empresas, NAV ha sido durante años el corazón de finanzas, compras, ventas, almacén, proyectos o servicios. El problema llega cuando las personalizaciones pesan demasiado, el reporting depende de Excel y cada mejora exige tocar una lógica que pocas personas conocen.
La migración debe revisar procesos, limpiar datos, reducir deuda técnica, aprovechar estándar, gobernar extensiones y decidir qué debe resolverse en el ERP y qué puede acelerarse con Power Platform, Power BI o automatización.
En empresas con mayor complejidad financiera, operativa, industrial, internacional o multisociedad, la evolución desde AX exige una lectura más profunda que una migración técnica. Pesan procesos críticos, desarrollos históricos, integraciones, datos maestros, roles, seguridad y pruebas.
Dynamics 365 Finance & Operations suele encajar cuando la organización necesita más control financiero, supply chain, fabricación, planificación, consolidación, reporting avanzado o escalabilidad internacional.
Muchas empresas operan con desarrollos propios, soluciones locales o aplicaciones sectoriales que resolvieron muy bien una necesidad concreta, pero hoy dificultan crecimiento, integración y control. Aquí el primer paso no es elegir producto: es entender qué hace realmente el ERP, qué hacen las hojas Excel, qué sistemas externos intervienen, qué datos son fiables y qué información necesita dirección.
A partir de ese mapa se puede valorar si el destino debe ser Business Central, Finance & Operations o una arquitectura más amplia apoyada en Azure, Power Platform, Power BI, Copilot y agentes.
Lo caro no siempre es migrar. A menudo, lo caro es seguir igual.
El coste de mantener un ERP antiguo suele estar repartido en pequeñas partidas: horas de conciliación, informes manuales, incidencias recurrentes, procesos duplicados, integraciones que se rompen, desarrollos que nadie quiere tocar, cierres lentos, dependencia de Excel y decisiones tomadas con datos atrasados. Como no aparece concentrado en una sola factura, se subestima.
La decisión no es solo migrar. Es elegir qué complejidad debe absorber el ERP.
Una mala elección no se nota el primer día. Se nota cuando aparecen nuevas sociedades, crece el volumen, el reporting exige más detalle o las integraciones empiezan a condicionar el negocio.
Encaja especialmente bien en organizaciones medianas, grupos con complejidad controlada o empresas que quieren modernizar finanzas, compras, ventas, almacén, proyectos o servicios sin construir una arquitectura demasiado pesada.
Es una ruta natural para escenarios NAV/Navision donde conviene revisar personalizaciones, limpiar datos, aprovechar estándar, extensiones y Power Platform.
Pensado para organizaciones con multisociedad, consolidación avanzada, volumen transaccional elevado, procesos complejos, fabricación, supply chain o actividad internacional.
En escenarios AX/Axapta, la robustez, escalabilidad y gobierno operativo suelen pesar más que la simplicidad inicial de despliegue.
La pregunta es qué complejidad debe resolver el ERP y qué puede resolverse con Power Platform, Azure, Power BI, Copilot o agentes inteligentes sin sobrecargar el núcleo.
Business Central o Finance es solo una parte de la decisión.
El valor aparece cuando ERP, datos, Power Platform, Power BI, Azure, Microsoft 365 y Copilot se diseñan como una arquitectura coherente. El objetivo no es meterlo todo dentro del ERP, sino construir un núcleo estable que pueda conectarse y evolucionar.
Los proyectos ERP no fracasan por instalar mal el software. Fracasan por entender mal el negocio.
La migración ERP debe dejar una empresa más conectada, no solo un sistema más nuevo
El ERP debe seguir siendo el núcleo transaccional, pero no puede vivir aislado. Debe conectarse con CRM, Power BI, Power Platform, Azure, Microsoft 365, sistemas sectoriales, aplicaciones externas y capas de inteligencia artificial capaces de operar sobre datos fiables.
No todo debe meterse dentro del ERP. Esa es precisamente la ventaja de una arquitectura Microsoft bien diseñada.
La migración se gana antes del go-live.
La calidad del dato, las dependencias reales, las excepciones operativas, la seguridad y las integraciones críticas determinan más el resultado que la configuración del software. Por eso el diagnóstico y el diseño de arquitectura son parte del proyecto, no una tarea previa de poca importancia.
Cómo abordar una migración ERP legacy sin poner en riesgo la operación
Una migración bien gobernada no empieza configurando pantallas. Empieza construyendo una visión compartida de negocio, procesos, datos, integraciones, riesgos y decisiones de arquitectura. Estas seis fases ayudan a ordenar el proyecto antes de comprometer inversión y calendario.
Entender el sistema real, no el que figura en la documentaciónVersiones, personalizaciones, deuda técnica, usuarios, rendimiento, incidencias, soporte, costes de mantenimiento y dependencias críticas.
Separar lo que aporta valor de lo que simplemente se ha heredadoFinanzas, compras, ventas, almacén, fabricación, proyectos, reporting y circuitos paralelos deben revisarse con usuarios de negocio.
Decidir qué pertenece al ERP y qué debe vivir en plataformaBusiness Central o F&O, Power Platform, Power BI, Azure, Microsoft 365, Dataverse, integraciones y capas de IA.
No migrar por defecto todo el pasadoClasificar históricos, maestros, calidad del dato, interfaces, APIs, bancos, CRM, logística, nómina, e-commerce y sistemas sectoriales.
Probar procesos completos, no funciones aisladasConfiguración, extensiones, migración, integraciones, pruebas end-to-end, seguridad, rendimiento, contingencia y salida a producción.
El go-live no es el final del proyectoFormación, gobierno, soporte, mejora continua, automatización, reporting, nuevos casos de uso y preparación de escenarios de Copilot y agentes.
El objetivo no es prometer una migración sin fricciones. Es detectar antes dónde están los datos problemáticos, los procesos críticos, las integraciones frágiles, las personalizaciones innecesarias y las decisiones que pueden condicionar el futuro de la plataforma.
La ruta cambia según el ERP, la complejidad y la arquitectura futura
Ruta específica para reducir deuda técnica, revisar personalizaciones y aprovechar mejor el estándar Microsoft.
Ruta para organizaciones con mayor complejidad financiera, operativa, industrial, multisociedad o internacional.
Cómo preparar Dynamics 365, datos, Power Platform, Azure y Copilot para escenarios reales de IA y agentes.
Apps, flujos, Power BI, Dataverse y agentes para automatizar alrededor del ERP sin convertirlo en un bloque rígido.
Arquitectura cloud para datos, IA generativa, RAG, agentes, seguridad, monitorización y escalabilidad.
ERP, obra, datos, reporting, Power Platform, Azure e IA aplicada a un sector con procesos críticos.
Una migración ERP crítica necesita capacidad acreditada más allá del ERP
Ayesa combina Business Applications, Azure, Data & AI, Modern Work, seguridad, Power Platform e integración. Esa cobertura permite abordar la modernización como una transformación de procesos, datos y arquitectura, no como una simple sustitución tecnológica.
Preguntas frecuentes sobre migración de ERP legacy
Las dudas más importantes suelen aparecer antes de pedir una propuesta. Resolverlas bien ayuda a dimensionar alcance, riesgo y expectativas desde el principio.
No necesariamente. Conviene separar datos que deben operar en el nuevo ERP, históricos que deben conservarse por motivos legales o de consulta y datos obsoletos que no aportan valor. Migrar todo por defecto aumenta coste, complejidad y riesgo.
Sí, cuando la arquitectura y las dependencias lo permiten. En grupos empresariales o entornos complejos puede ser preferible migrar por sociedades, geografías, procesos o unidades de negocio para reducir riesgo y controlar mejor el cambio.
Deben inventariarse y clasificarse por criticidad. Algunas podrán mantenerse con cambios mínimos, otras deberán rediseñarse y otras pueden desaparecer si el nuevo entorno cubre esa necesidad de forma estándar o mediante Power Platform, Dataverse o Azure.
La elección depende de complejidad financiera y operativa, multisociedad, internacionalización, volumen, fabricación, supply chain, reporting y gobierno. No debería decidirse únicamente por tamaño de empresa o por el ERP del que se parte.
Puede reducirlo si el proyecto elimina personalizaciones innecesarias, aprovecha estándar, gobierna extensiones y evita reconstruir el mismo modelo de deuda técnica sobre la nueva plataforma. Migrar sin simplificar puede trasladar el problema en lugar de resolverlo.
Cuando el coste de evolucionar el ERP actual empieza a limitar proyectos de negocio, reporting, integración, seguridad, automatización o IA. La preparación puede comenzar mucho antes del cambio de plataforma mediante diagnóstico, limpieza de datos y revisión de procesos.
La modernización ERP se entiende mejor cuando se ve aplicada
Consulta proyectos de Ayesa en los que Microsoft Dynamics 365, Business Central, cloud, datos y soluciones sectoriales han servido para modernizar operaciones, integrar información y mejorar control.
Evalúa si ha llegado el momento de dejar atrás tu ERP legacy
Cuéntanos desde qué ERP partes, qué problemas estás viendo y qué necesitas resolver. Podemos ayudarte a ordenar la conversación: ruta de migración, riesgos, datos, integraciones, Business Central vs Finance & Operations y oportunidades de automatización e IA.