Cuánto cuesta migrar de NAV a Business Central: tres escenarios para decidir sin pagar por trasladar deuda
Desde unos 50.000 € en una transición muy controlada, alrededor de 90.000 € cuando hay mejora funcional y 150.000 € o más cuando NAV sostiene personalizaciones, integraciones, multiempresa o procesos críticos que hay que rediseñar.
El coste no lo determina “NAV” como producto. Lo determinan la versión, el código C/AL, los datos, el histórico, las integraciones, las sociedades, los países, las aplicaciones de terceros, la calidad de los maestros, las pruebas y cuánto del modelo actual quieres conservar. Esta guía mantiene tres rangos orientativos, pero los convierte en una herramienta de decisión: qué compra cada escenario, qué puede dispararlo y cuándo actualizar deja de ser razonable frente a reimplantar.
50.000 €, 90.000 € y 150.000 €+ pueden ser referencias útiles. No son una tarifa ni una promesa sin diagnóstico.
Los rangos sirven para ordenar expectativas. Un proyecto alrededor de 50.000 € solo es defendible cuando el alcance es realmente contenido: pocas personalizaciones, datos controlados, baja complejidad de integración, pocos procesos diferenciales y una organización dispuesta a adoptar mucho estándar.
En torno a 90.000 € aparece un espacio mayor para revisar procesos, limpiar datos, adaptar extensiones, rediseñar reporting, probar integraciones y acompañar mejor a usuarios. El proyecto deja de ser una simple transición técnica y empieza a corregir fricciones del NAV actual.
A partir de 150.000 €, normalmente estamos ante un problema más amplio: muchas personalizaciones, varias sociedades, industria, verticales, interfaces sensibles, históricos complejos, países o una oportunidad real de reimplantar procesos.
La cifra adecuada debe salir del inventario, no al revés. Presupuestar primero y descubrir después qué tiene NAV es la forma más rápida de convertir un precio atractivo en una cadena de ampliaciones.
La diferencia entre 50k€ y 150k€ no es “más Business Central”. Es más complejidad que resolver.
Los siguientes escenarios son orientativos y deben validarse con un assessment. No incluyen automáticamente cualquier licencia, app o servicio recurrente; cada propuesta debe indicar expresamente qué conceptos forman parte del proyecto y cuáles quedan fuera.
Migración básica y controlada
NAV relativamente estándar, pocas personalizaciones críticas, alcance funcional limitado, datos razonablemente ordenados y pocas integraciones.
Migración con mejora de procesos
Personalizaciones relevantes, varias áreas, reporting importante, limpieza de datos, algunas integraciones y voluntad de mejorar cómo trabaja la compañía.
Migración avanzada o transformación
NAV muy personalizado, verticales, varias sociedades o países, fabricación compleja, históricos sensibles, integraciones críticas o rediseño amplio.
NAV 2015–2018 no migra directamente a Business Central online: la ruta estándar pasa primero por Business Central on-premises
Microsoft documenta que Dynamics NAV 2015, 2016, 2017 y 2018 deben actualizarse primero a Business Central 14 on-premises. Para la migración completa a Business Central online, la ruta actual continúa después hacia Business Central on-premises versión 25 o posterior y, desde ahí, utiliza las herramientas de cloud migration.
NAV 2013 y 2013 R2 requieren un paso previo por NAV 2018. NAV 2009 SP1/R2 necesita pasos adicionales. Esto explica por qué dos clientes con “NAV” pueden recibir presupuestos radicalmente distintos.
Microsoft ofrece además una alternativa de reimplementación desde Business Central 14 para migrar datos esenciales —por ejemplo, maestros, saldos iniciales y setup— en lugar de trasladar toda la historia. Es una opción que merece evaluarse cuando una migración completa arrastra demasiado coste o deuda.
El calendario de soporte cambia el riesgo y también el coste de esperar
Dynamics NAV 2015 y NAV 2016 ya han finalizado su soporte extendido. NAV 2017 mantiene soporte extendido hasta enero de 2027 y NAV 2018 hasta enero de 2028. Estas fechas no significan que todos los clientes deban arrancar un proyecto mañana, pero sí cambian el balance entre seguir operando, actualizar infraestructura o preparar una migración ordenada.
Esperar puede ser razonable si existe una hoja de ruta y el entorno está bien protegido. Esperar sin inventario, sin sucesión de conocimiento y sin presupuesto convierte una decisión estratégica en una migración de urgencia.
| Versión | Fin soporte extendido | Lectura en agosto 2026 | Prioridad |
|---|---|---|---|
| NAV 2015 | Enero 2025 | Fuera de soporte. | Alta: planificar modernización. |
| NAV 2016 | Abril 2026 | Fuera de soporte. | Alta: evaluar ruta y riesgo. |
| NAV 2017 | Enero 2027 | Últimos meses de soporte extendido. | Muy alta: evitar decisión tardía. |
| NAV 2018 | Enero 2028 | Todavía tiene margen de soporte. | Planificar con tiempo y usar el margen para depurar. |
El precio debería poder descomponerse en trabajo visible, no en una línea llamada “migración”
Una oferta comparable debe explicar qué parte del presupuesto corresponde a diagnóstico, upgrade técnico, código, datos, configuración, integraciones, reporting, pruebas, formación y transición. Si una de estas partidas no aparece, debe constar si está fuera de alcance o incluida dentro de otra actividad.
Assessment
Versión, objetos, módulos, usuarios, sociedades, localizaciones, integraciones, datos, procesos y riesgos.
Ruta técnica
Versiones intermedias, SQL, BC14, BC25+, tools y condiciones de cloud migration.
C/AL → AL
Clasificar código, sustituir estándar, convertir extensiones y resolver dependencias.
Datos
Limpieza, transformación, maestros, saldos, abiertos, históricos y reconciliación.
Configuración
Finanzas, ventas, compras, inventario, proyectos, servicios, fabricación y localización.
Integraciones
APIs, Power Platform, bancos, EDI, e-commerce, CRM, MES, WMS y aplicaciones externas.
Reporting
Informes regulatorios, operativos, Power BI, APIs y sustitución de reporting histórico.
UAT y pruebas
Procesos end-to-end, excepciones, interfaces, fiscalidad, cierre, cargas y cutover.
Go-live
Dry run, freeze, carga final, go/no-go, formación, soporte e hypercare.
El código antiguo es una de las partidas que más puede mover el presupuesto porque obliga a decidir, no solo a convertir
Microsoft exige que las personalizaciones C/AL se conviertan en extensiones AL para migrar a Business Central online mediante la ruta estándar. Pero “convertir todo” no debería ser el objetivo. Cada objeto debe justificar por qué sigue existiendo.
Una personalización puede haberse creado porque NAV no tenía determinada capacidad, porque el negocio tomó una decisión específica, porque existía una integración antigua o porque alguien resolvió una necesidad urgente. Diez años después, algunas siguen siendo diferenciales; otras ya están cubiertas por estándar, AppSource, Power Platform o una API.
Migrar diez años de histórico al ERP productivo no es automáticamente más completo. Puede ser simplemente más caro.
El proyecto debe separar lo que Business Central necesita para operar del dato que solo se utiliza para consulta, auditoría o analítica. Maestros, saldos, pedidos abiertos, inventario y determinados históricos pueden ser esenciales. Otros años de transacciones pueden quedar en una capa de consulta o datos si existe una estrategia bien gobernada.
Cuanto más histórico se migra, más reglas de transformación, validación, reconciliación, tiempos de carga y excepciones aparecen. La pregunta no es “¿podemos moverlo?”. Es “¿qué decisión futura justifica que esté dentro de Business Central?”.
La alternativa de reimplementation desde BC14 que documenta Microsoft refuerza esta idea: en determinados escenarios puede ser mejor migrar datos esenciales y construir un modelo limpio.
Una interfaz olvidada puede costar más que cien objetos C/AL si bloquea una operación crítica
En NAV es frecuente encontrar servicios, SQL directo, ficheros, jobs, FTP, DLL, impresoras, EDI o conexiones que han crecido sin un inventario central. Business Central online cambia patrones de acceso y obliga a revisar cómo se conectan los sistemas.
El coste no depende solo de “cuántas interfaces”. Una integración crítica necesita autenticación, retries, trazabilidad, monitorización, reconciliación y soporte. Hay que clasificar cada conexión por responsabilidad y riesgo.
Bancos / fiscal
Formatos, certificados, estados, conciliación y obligaciones regulatorias.
CRM / e-commerce
Clientes, precios, stock, pedidos, facturas, devoluciones y ownership de datos.
MES / WMS / EDI
Procesos críticos con volumen, secuencia, recuperación y monitorización.
Power Platform
Aprobaciones, movilidad, captura y automatización como alternativa a parte del desarrollo antiguo.
Azure
APIs, integración, mensajería y desacoplamiento cuando la arquitectura lo requiere.
Power BI
Reporting histórico y futuro sobre modelos más estables que los informes artesanales del ERP.
En una fábrica, el coste crece cuando NAV no solo contabiliza: decide qué comprar, qué producir, cuándo entregar y cuánto ha costado
Fabricación multiplica dependencias entre maestros, BOM, rutas, MRP, inventario, capacidad, compras, lotes, warehouse y costes. Migrar esos procesos exige validar resultados, no solo datos y pantallas.
Un escenario industrial puede seguir encajando en Business Central, pero suele desplazarse del rango básico al medio o avanzado cuando existen desarrollos específicos, trazabilidad, planificación compleja, MES, calidad o reporting industrial. Conviene evaluar el modelo antes de presupuestar una conversión automática.
Cada sociedad adicional no multiplica el proyecto de forma lineal, pero añade datos, pruebas, localización y gobierno
Una empresa con varias sociedades puede compartir chart of accounts, maestros y procesos o puede operar con configuraciones muy diferentes. El coste depende de cuánto se puede estandarizar y de cuántas excepciones deben conservarse.
En varios países aparecen localizaciones, fiscalidad, e-invoicing, bancos, idiomas, monedas, calendarios y apps específicas. La propuesta debe distinguir rollout común de trabajo específico por país.
Core común
Modelo financiero, dimensiones, compras, ventas y reglas comunes reducen dispersión.
Plantilla
Permite replicar configuración gobernada y limitar desarrollos distintos por sociedad.
Localización
Fiscalidad, e-invoicing, bancos y obligaciones específicas deben validarse por país.
Intercompany
Operaciones cruzadas, eliminaciones, reconciliación y ownership de procesos.
Rollout
Big bang o despliegue por oleadas según dependencia, riesgo y capacidad interna.
Soporte futuro
El diseño debe evitar convertir cada país en una solución independiente difícil de actualizar.
Un rango solo es útil si también deja claro qué no está comprando
Cada propuesta debe explicarlo. Estos elementos son ejemplos de conceptos que a menudo se cotizan por separado o dependen del alcance: licencias recurrentes, apps de terceros, dispositivos, infraestructura ajena a Business Central, proyectos de datos avanzados, integraciones no inventariadas, soporte de terceros, localizaciones adicionales y evolutivos posteriores.
Licencias
Business Central y otras capacidades Microsoft son OPEX y deben mostrarse separadas del proyecto.
Apps
Suscripciones o mantenimiento de ISV pueden tener su propio modelo de precio.
Terceros
MES, EDI, bancos, portales, fiscalidad o proveedores externos pueden requerir trabajo adicional.
Power BI avanzado
Puede fasearse después del go-live si el modelo de datos queda preparado.
IA y agentes
No deben inflar el primer alcance salvo que exista caso de negocio claro.
Evolutivos
Mejoras posteriores al hypercare deben distinguirse de correcciones del alcance pactado.
La mejor reducción de presupuesto suele venir de retirar complejidad, no de retirar pruebas
Reducir UAT, dry run, reconciliación o soporte al arranque puede abaratar la propuesta y encarecer la operación. Hay otras palancas más sanas: limitar histórico, eliminar código sin valor, usar estándar, consolidar informes, fasear analítica avanzada y simplificar integraciones.
Cuanto más antiguo y personalizado está NAV, más sentido tiene comparar dos proyectos diferentes
La migración completa busca preservar una mayor parte del estado, datos y continuidad técnica. La reimplantación busca construir un Business Central limpio y migrar solo lo necesario. Ninguna es universalmente mejor.
La elección debe comparar coste, riesgo, histórico, capacidad de rediseño, volumen de personalización y disposición del negocio a cambiar procesos. Microsoft documenta incluso una ruta de reimplementation desde BC14 para trasladar datos esenciales, lo que formaliza una alternativa que muchas organizaciones deberían considerar.
Preservar más continuidad
Tiene sentido cuando datos, procesos y personalizaciones están bien controlados y merece la pena conservar gran parte del modelo.
Construir un modelo limpio
Tiene sentido cuando el NAV actual acumula mucho código, datos, informes y hábitos que no representan el futuro del negocio.
Una propuesta de 60k€ y otra de 120k€ pueden estar describiendo proyectos distintos
Antes de elegir por precio, normaliza el alcance. Si una oferta incluye conversión de C/AL, dos ensayos de datos, UAT, integraciones, formación, dry run e hypercare y otra no, el total no es directamente comparable.
| Pregunta | Qué debería responder la oferta | Señal de riesgo |
|---|---|---|
| ¿Qué versión tenemos? | Ruta exacta y versiones intermedias. | Precio sin assessment técnico. |
| ¿Qué código se convierte? | Inventario, clasificación y volumen de C/AL/AL. | “Personalizaciones incluidas” sin detalle. |
| ¿Qué datos migran? | Maestros, abiertos, saldos, históricos, ensayos y reconciliación. | “Toda la base” sin política de calidad. |
| ¿Qué integraciones? | Sistema, dirección, frecuencia, criticidad y contingencia. | Interfaces como bolsa genérica. |
| ¿Qué pruebas? | Ciclos, owners, UAT, integraciones, reconciliación y cutover. | Validación únicamente por consultoría. |
| ¿Qué pasa tras go-live? | Hypercare, SLAs, criterios de salida y soporte recurrente. | Proyecto termina el día del arranque. |
| ¿Qué queda fuera? | Exclusiones, terceros, licencias y dependencias cliente. | Oferta casi sin supuestos ni exclusiones. |
El business case no compara “migrar” con “cero euros”. Compara migrar con mantener el entorno actual durante tres o cinco años.
NAV puede seguir funcionando y aun así generar un coste creciente: infraestructura, SQL, backup, seguridad, soporte, actualizaciones, desarrollos, dependencia de personas, informes manuales, integraciones frágiles y oportunidad perdida de automatizar.
La decisión financiera debe construir dos escenarios: TCO de mantener NAV y TCO de migrar a Business Central. El proyecto inicial puede ser más visible que el coste distribuido de seguir igual, pero ambos consumen presupuesto y capacidad.
El proyecto de migración es el pico de inversión. La arquitectura decide el coste que queda después.
El TCO de Business Central debe incluir proyecto, licencias, apps, soporte, evolutivos, integraciones y capacidad interna. También debe descontar costes que se eliminan o reducen al abandonar NAV. No existe un ROI universal: depende de cuánto cuesta hoy la fricción y cuánto valor genera el nuevo modelo.
Año 0–1
Assessment, proyecto, licencias, apps, migración, formación, cutover e hypercare.
Año 2
Estabilización, soporte, Power BI, automatización y mejoras basadas en uso real.
Años 3–5
Evolución, nuevas sociedades, apps, integración e innovación sobre una base actualizable.
Coste evitado
Infraestructura NAV, upgrades legacy, mantenimiento de C/AL y herramientas duplicadas.
Productividad
Menos doble entrada, conciliación, informes manuales y tiempos de soporte.
Futuro
Capacidad para Power Platform, Power BI, Copilot, agentes y nuevas integraciones.
Una migración no tiene ROI porque “la nube sea moderna”. Lo tiene cuando cambia una métrica que cuesta dinero o limita crecimiento.
El business case debe partir de indicadores actuales. No todos mejorarán por el ERP, pero sin una línea base tampoco se puede saber si el proyecto generó retorno.
Cierre financiero
Horas/días de cierre, ajustes manuales y conciliaciones.
Administración
Horas de doble entrada, exportación, Excel y reintroducción de datos.
Inventario
Cobertura, obsolescencia, roturas y compras urgentes.
Servicio
Plazo, OTIF, errores, devoluciones y tiempo de respuesta.
IT
Horas dedicadas a plataforma, incidencias, backups, versiones e integraciones antiguas.
Cambio
Tiempo/coste para lanzar una integración, proceso, sociedad, informe o automatización nueva.
Una promoción puede mejorar el caso económico. No debe ser la razón para migrar un ERP sin estar preparado.
Microsoft mantiene iniciativas para ayudar a clientes Dynamics on-premises a evolucionar hacia cloud. En 2026 Microsoft anunció Bridge to Cloud 3 como sucesor de Bridge to Cloud 2. Las condiciones y elegibilidad comercial deben validarse en el momento de cotizar, porque promociones, fechas y requisitos pueden cambiar.
La forma correcta de usar una ventana comercial es reducir fricción financiera de un proyecto ya justificado por negocio, soporte, arquitectura o riesgo. La forma incorrecta es acelerar una migración sin assessment para “no perder la oferta”.
De una cifra orientativa a un presupuesto defendible
El siguiente proceso reduce incertidumbre antes de comprometer fecha y coste.
El escenario básico deja de ser creíble cuando aparecen varias de estas condiciones
Business Central puede ser el destino correcto y el proyecto estar prematuro
No conviene fijar go-live si no existe inventario de código, las integraciones críticas no tienen owner, los datos no pueden reconciliarse, el negocio no dispone de usuarios clave o hay una transformación mayor simultánea que supera la capacidad de absorción. Preparar estas condiciones puede reducir el coste total aunque retrase el arranque unas semanas o meses.
El valor de Business Central no está en parecerse a NAV. Está en dejar una plataforma más fácil de conectar y evolucionar.
Una buena migración deja datos más limpios, extensiones gobernables, APIs, permisos, reporting y procesos preparados para una segunda etapa. Power Platform puede automatizar procesos periféricos, Power BI puede construir una capa de decisión y Copilot/agentes pueden aprovechar contexto del ERP cuando existe una base fiable.
No es necesario meter toda esa innovación en el primer presupuesto. Sí es necesario evitar una arquitectura que obligue a volver a rehacer la solución cuando quieras incorporarla.
Power BI
Finanzas, ventas, compras, stock, proyectos, fabricación y margen sobre una semántica común.
Power Platform
Apps, flujos, movilidad, aprobaciones y automatización alrededor del ERP.
Copilot
Capacidades nativas online que pueden incorporarse según región, función y caso de negocio.
Agentes
Procesos y decisiones automatizadas con permisos, contexto, límites y trazabilidad.
Azure
Integración, datos e IA cuando la arquitectura empresarial necesita una capa adicional.
Actualización continua
Extensiones, apps y pruebas preparadas para el ciclo de Business Central online.
Migrar, reimplantar y modernizar no significan lo mismo en todos los clientes
Estas referencias muestran distintos contextos Business Central. No se presentan como ejemplos exactos de los tres rangos económicos anteriores. CYCASA es especialmente útil para ilustrar una reimplantación desde una solución NAV previa.
Reimplantación desde un entorno NAV anterior
Una referencia relevante para entender por qué conservar todo el sistema anterior no siempre es la mejor estrategia.
Business Central para integrar gestión y operaciones
Un ejemplo de cómo Business Central puede servir como base común para procesos administrativos e industriales.
Business Central en electrónica industrial
Una referencia donde robustez, integración y capacidad de crecimiento forman parte del valor de la plataforma.
Business Central y gestión integrada
Una referencia de transformación con Business Central y analítica para mejorar control y visión de negocio.
Una migración NAV puede cruzar ERP, industria, Azure, Power Platform, Power BI, seguridad, datos e IA
El coste baja cuando las decisiones se coordinan desde una arquitectura común y no se convierten en proyectos aislados. Ayesa puede trabajar el ERP, las integraciones, el dato y la evolución Microsoft dentro de una misma hoja de ruta.
Profundiza antes de fijar presupuesto
Dudas frecuentes sobre el coste de migrar NAV a Business Central
¿Cuánto cuesta migrar de NAV a Business Central?
Como referencia orientativa, una migración controlada puede partir de unos 50.000 €, un escenario con mejora funcional puede situarse alrededor de 90.000 € y una migración avanzada puede alcanzar 150.000 € o más. El precio real depende de versión, personalizaciones, datos, integraciones, sociedades, usuarios y alcance.
¿Los 50.000 € son un precio cerrado?
No. Es un punto de referencia para escenarios acotados. Sin revisar NAV, personalizaciones, datos e integraciones no debería utilizarse como promesa comercial.
¿Qué suele incluir un proyecto de 50.000 €?
Un assessment acotado, configuración, migración de datos esenciales, adaptación limitada, pruebas, formación y puesta en marcha. Solo encaja cuando el entorno es relativamente estándar.
¿Qué justifica un escenario de 90.000 €?
Más revisión de procesos, limpieza de datos, extensiones, reporting, integraciones, UAT y acompañamiento. La empresa aprovecha la migración para mejorar cómo trabaja.
¿Cuándo se supera 150.000 €?
Cuando aparecen muchas personalizaciones, varias sociedades o países, industria compleja, verticales, datos históricos extensos, integraciones críticas o una transformación amplia.
¿NAV 2015 puede migrar directamente a Business Central online?
No mediante la ruta estándar actual. Microsoft documenta el paso por Business Central 14 on-premises y posteriormente por Business Central on-premises versión 25 o posterior antes de cloud migration.
¿NAV 2018 puede migrar directamente a Business Central online?
Tampoco directamente. La ruta estándar documentada por Microsoft pasa por Business Central 14 y después por Business Central on-premises 25 o posterior.
¿Qué pasa si utilizo NAV 2013?
Microsoft documenta una ruta que pasa primero por NAV 2018, después Business Central 14, Business Central 25 o posterior y finalmente online.
¿Qué pasa si utilizo NAV 2009?
La ruta requiere más pasos intermedios. Debe revisarse la versión exacta y el camino soportado por Microsoft antes de estimar.
¿NAV 2015 sigue soportado?
No. Su soporte extendido terminó en enero de 2025.
¿NAV 2016 sigue soportado?
No. Su soporte extendido terminó en abril de 2026.
¿NAV 2017 sigue soportado?
En agosto de 2026 todavía está en soporte extendido, con final previsto en enero de 2027.
¿NAV 2018 sigue soportado?
Sí, mantiene soporte extendido hasta enero de 2028 según Microsoft Lifecycle.
¿Hay que convertir todo el C/AL a AL?
Para la migración estándar a online, las personalizaciones que deban sobrevivir deben gestionarse mediante extensiones AL. No significa que todo el código antiguo merezca convertirse.
¿Qué personalizaciones conviene eliminar?
Las que ya cubre estándar, una app o Power Platform, las que no se utilizan, no tienen owner o responden a procesos que la empresa no quiere conservar.
¿Hay que migrar todo el histórico?
No. Conviene separar datos necesarios para operar de histórico para consulta, auditoría o analítica. Reducir histórico puede disminuir coste y riesgo.
¿Qué es la reimplantación desde Business Central 14?
Microsoft documenta una alternativa que permite trasladar datos esenciales desde BC14 en lugar de seguir la ruta completa de migración de todo el historial. Puede ser útil cuando se busca un modelo más limpio.
¿Qué encarece más: usuarios o personalizaciones?
Los usuarios influyen en licencias y pruebas, pero en el proyecto suelen pesar mucho la versión, el código, los datos, las integraciones y la complejidad funcional.
¿Una empresa industrial suele estar en el escenario básico?
Puede estarlo si la fabricación es simple y NAV está poco personalizado, pero MRP, trazabilidad, warehouse, costes e integraciones de planta suelen aumentar alcance.
¿Qué pasa con el MES o WMS actual?
Debe revisarse la integración completa: datos, dirección del flujo, latencia, seguridad, reintentos, monitorización, contingencia y ownership.
¿Power BI debe entrar en el primer proyecto?
Conviene asegurar reporting esencial y los datos necesarios desde el diseño. Analítica avanzada puede fasearse para no inflar el go-live.
¿Power Platform puede sustituir desarrollos de NAV?
En algunos procesos periféricos sí: aprobaciones, movilidad, captura o automatización pueden resolverse mejor fuera del core. Debe evaluarse caso por caso.
¿Cómo comparo dos presupuestos?
Normaliza alcance de versión, C/AL, datos, integraciones, reporting, pruebas, formación, cutover, hypercare, terceros, licencias y exclusiones.
¿Qué es más caro: migrar o reimplantar?
Depende. Migrar puede salir caro si conserva mucha deuda; reimplantar puede requerir más rediseño y cambio. Debe compararse el TCO futuro, no solo el proyecto inicial.
¿Cuánto tiempo puede durar una migración?
Depende del escenario, sociedades, ruta de versiones, código, datos, integraciones y capacidad interna. Un calendario serio se estima después del assessment.
¿Se puede migrar sin parar el negocio?
El objetivo es minimizar la parada con cargas previas, replicación cuando aplica, dry run y una ventana de cutover. Siempre debe existir una estrategia para los procesos críticos.
¿Qué es un dry run?
Un ensayo completo de la transición para medir tiempos, validar secuencia, cargas, integraciones, responsables y criterios de go/no-go antes del arranque real.
¿Qué es hypercare?
Un periodo de soporte reforzado tras el go-live para estabilizar procesos, resolver incidencias y evitar que aparezcan workarounds permanentes.
¿Existe alguna promoción Microsoft para migrar a cloud?
Microsoft mantiene iniciativas de migración y anunció Bridge to Cloud 3 para 2026. Las condiciones, elegibilidad y fechas deben confirmarse en el momento de cotizar.
¿Cómo se calcula el ROI?
Comparando TCO de mantener NAV con TCO de migrar y midiendo mejoras en cierres, trabajo manual, inventario, servicio, soporte, integración y velocidad de cambio.
¿Cuándo NO debería migrar todavía?
Cuando no existe inventario de código, los datos no tienen owner, hay integraciones críticas no entendidas o el negocio no dispone de capacidad para probar y decidir.
¿Cuál es el primer paso para obtener una cifra fiable?
Identificar la versión exacta de NAV y hacer un assessment técnico-funcional de personalizaciones, datos, integraciones, sociedades, procesos y objetivos.
La versión exacta debe contrastarse siempre con Microsoft antes de cerrar alcance
Microsoft actualiza rutas, requisitos y lifecycle. Las referencias siguientes permiten validar el escenario técnico cuando se prepare una migración real.
Migrar Dynamics NAV a Business Central online
Rutas soportadas desde NAV, fases de migración y tratamiento de personalizaciones.
Migrar on-premises a Business Central online
Versiones de Business Central compatibles con cloud migration y requisitos actuales.
Upgrade paths on-premises
Caminos soportados entre NAV, BC14, BC25 y versiones actuales.
Antes de decidir si tu migración cuesta 50k€, 90k€ o 150k€+, hay que saber qué NAV estás comprando de nuevo
Podemos revisar versión, C/AL, add-ons, datos, histórico, sociedades, países, integraciones, fabricación, reporting, usuarios y objetivos para situar el proyecto en un rango defendible. Te diremos qué merece migrar, qué puede retirarse, cuándo una reimplantación puede reducir deuda y qué debería quedar preparado para Power Platform, Power BI, Copilot y agentes.
Cuéntanos qué NAV tienes y qué quieres conseguir con Business Central
Indícanos versión aproximada, usuarios, sociedades, personalizaciones, integraciones, sectores/procesos críticos y si el objetivo es migrar a SaaS, actualizar on-premise o revisar una reimplantación. Con esa información podremos acotar mejor el escenario.
¿Conectamos?
La tecnología bien aplicada suele facilitar las cosas. Si sospechas que también puede ser de ayuda para ti, concédenos la oportunidad de conocerte y demostrarte hasta qué punto es así.
Suscríbete a nuestra enews mensual, y no te pierdas los mejores contenidos sobre Microsoft Dymanics 365
Información respecto al tratamiento de los datos solicitados, de acuerdo con el RGPD 2016/679 y la LOPDGDD 3/2018: el responsable es Ibermática SA; la finalidad es la recogida y tratamiento de los datos personales que solicitamos para atender tu consulta, enviarte nuestras publicaciones, newsletters, promociones de productos y/o servicios, y recursos exclusivos; la legitimación se establece mediante el consentimiento expreso; no se cederán datos a terceros, salvo obligación legal; en cualquier momento puedes ejercer tus derechos de acceso, rectificación, supresión, portabilidad, limitación u oposición al tratamiento de tus datos, así como retirar el consentimiento prestado o formular reclamaciones ante la Autoridad de Control, enviando la solicitud por correo electrónico a: arco@ibermatica.com; puedes consultar la información adicional y detallada sobre Privacidad y Protección de Datos de Carácter Personal en la Política de Privacidad de Ibermática S.A.
¿Por qué Ayesa?
Somos uno de los principales implantadores de Microsoft, con casi 2000 clientes que han depositado su confianza en nosotros para la implantación de Dynamics 365, Business Central (NAV / Navision) y Dynamics 365 Finance & Operations (AX / Axapta). Además, destacamos en el despliegue de proyectos sobre AZURE y Microsoft 365. Nuestra experiencia en el campo de la inteligencia artificial y el uso de Copilot nos sitúa a la vanguardia de la innovación tecnológica.
Con una plantilla de más de 12.000 profesionales y una sólida presencia en 23 países, estamos comprometidos en ayudar a nuestros clientes a definir y aprovechar oportunidades en el nuevo contexto digital. Desde la tecnología hasta las personas, ofrecemos un enfoque integral que garantiza el éxito en cada proyecto.
- ÚLTIMAS ENTRADAS DEL BLOG -
-
Microsoft Copilot en Dynamics 365 Finance & Operations: qué puede hacer realmente en el ERP
-
Microsoft Purview: gobierno y seguridad de datos para una empresa preparada para IA
-
Microsoft 365 Copilot y productividad: qué mejora de verdad y cómo medir su impacto
-
Seguridad y Cumplimiento en Microsoft Dynamics 365 Business Central: Lo que Debes Saber
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)