Lo bueno y lo que conviene saber antes: una guía honesta para equipos técnicos con Dynamics Navision que se plantean dar el salto a la nube.
Este artículo se suma a los que estamos publicando mis compañeras Ana y Virginia y yo sobre la migración de Navision (Dynamics NAV) a Business Central y si te conviene o no. Después del prisma económico y del funcional, toca el técnico.
Si quieres el contexto completo, puedes leer también el coste real de no migrar de Navision, por qué es el momento de migrar a Business Central y cómo automatizar procesos al pasar de NAV a Business Central.
Si tu empresa sigue trabajando con Navision, es muy probable que hayas oído hablar de "pasar a Business Central en la nube". Lo que se cuenta menos es que no se trata de mover tu servidor SQL a otro sitio. Es un cambio en el modelo de producto.
Pasas de un ERP instalado que controlas por completo (cliente, servidor, SQL y la posibilidad de modificar cualquier parte del ERP, por pequeña que sea) a un servicio gestionado por Microsoft. Ese servicio se amplía con extensiones en AL (no te asustes: sigue siendo bastante parecido a C/AL), se integra mediante APIs y se opera desde el Admin Center.
En este artículo quiero contarte, sin adornos, qué ganas, qué pierdes y qué tendrás que rehacer, porque sí, hay cosas que habrá que rehacer. Creemos que es la mejor forma de que tomes una decisión bien informada.
En NAV (al menos en las últimas versiones) trabajas con una arquitectura de tres capas: cliente NAV (Windows o web), servidor NAV y servidor SQL. El departamento de IT o el partner suele encargarse de todo el ciclo de vida de la infraestructura: cuentas para los servicios de Windows, certificados, puertos, IIS, copias de seguridad, actualizaciones de servidores, seguridad y monitorización.
En Business Central SaaS, conceptualmente, la arquitectura es la misma: esas capas siguen existiendo. La diferencia es que ninguna la administramos nosotros. Microsoft opera el servicio, la base de datos en Azure SQL, el escalado, la disponibilidad, los backups y las actualizaciones. Nuestro trabajo pasa a centrarse en gestionar entornos, aplicaciones, permisos e integraciones.
Cada suscripción de Business Central incluye un entorno de producción y hasta tres sandbox simultáneos. Creo que es más que suficiente para mantener uno de desarrollo, uno de preproducción y uno más volátil, por ejemplo, para las incidencias del día a día.
Y desde el Admin Center puedes crear en cuestión de minutos un sandbox que sea copia de producción, con toda la información hasta el momento exacto en que pulsaste "copiar entorno". Esto es gloria.
Además, los entornos de producción y sandbox cuentan con backups automáticos que se conservan 28 días, y los administradores pueden restaurar a cualquier punto dentro de esa ventana desde el Admin Center. Los entornos eliminados pasan por un periodo de recuperación de 14 días antes de borrarse definitivamente. ¿Has eliminado un entorno por error y un compañero no había terminado sus pruebas? Todavía puedes recuperarlo.
Microsoft lanza actualizaciones menores mensuales para corregir bugs y hacer pequeñas mejoras, y además dos grandes actualizaciones al año con novedades importantes. Este año, por ejemplo, ha presentado el agente de gastos con Copilot y el preview su propio conector de EDI enmarcado dentro de la nueva gestión de E-Documents que está creando, entre otras cosas. Todo se puede probar por adelantado creando un sandbox de tipo preview de la nueva versión.
Y como desarrollamos en extensiones, el código base de Microsoft no se toca: cada actualización es un proceso continuo. Recibimos correos automáticos cuando hay alguna incompatibilidad debida a un cambio interno, junto con las claves para solucionarla.
¿He mencionado ya la IA? En este nuevo entorno de desarrollo también se convierte en una aliada real. Integrada en Visual Studio Code, puede ayudarte a entender código, generar estructuras repetitivas, proponer pruebas o documentar desarrollos, siempre bajo la revisión del equipo técnico. Y, al trabajar con DevOps, esas aportaciones no quedan aisladas: pasan por ramas, revisiones de código, pipelines y trazabilidad. La IA no sustituye el criterio del desarrollador ni el conocimiento funcional, pero puede acelerar tareas y mejorar la calidad del ciclo de desarrollo.
Te he prometido honestidad. Ya he confesado mi amor por Business Central y que no vuelvo a NAV, pero eso no me impide ver algunos elefantes en la habitación.
Ya no tenemos acceso a la base de datos SQL. Esto, que reconozco que también tiene su parte positiva, elimina las consultas ad-hoc sobre las tablas, la reindexación o preparar vistas en SQL para modelar datos en informes. Para extraer datos existe la exportación a fichero BACPAC en una cuenta de Azure Storage propia, limitada a 10 exportaciones al mes por entorno. Los informes, integraciones o herramientas que hoy leen directamente de SQL tendrán que rehacerse sobre APIs, queries o réplicas analíticas. Como contrapartida, BC puede enviar telemetría de rendimiento y errores a Azure Application Insights para monitorizar lo que antes se investigaba directamente en la base de datos.
El núcleo de BC no se puede modificar. A veces fastidia y frustra, pero a la larga da tranquilidad: tenemos un núcleo estable y, a día de hoy, no me he encontrado nada que no se pudiera hacer. Microsoft ha publicado puntos de extensión en todos sus objetos (salvo los de sistema, por motivos obvios) y, si falta alguno, se puede solicitar a Microsoft. En ocasiones también habrá que duplicar algún proceso para adaptarlo a nuestras necesidades (módulo de Cartera, te miro a ti).
Se elimina el acceso a DLL, rutas locales, impresoras del servidor, etc. Cualquier llamada de este tipo debe sustituirse por servicios externos (por ejemplo, Azure Functions invocadas mediante HttpClient), y la descarga o importación de ficheros debe reorientarse hacia una integración con SharePoint. El NAS (NAV Application Server) también desaparece ("yo estuve ahí, Gandalf, hace 2000 años, cuando el NAS se cayó y no se procesaron las ventas del fin de semana") y pasa a ser sustituido por las Job Queues y el Task Scheduler.
No se puede depurar en producción con la inmediatez de NAV. Lo identifico como algo negativo, pero entiendo la lógica: con un debugger enganchado se pueden bloquear ejecuciones de otros usuarios de la empresa. Microsoft ofrece una especie de grabación de las secuencias por las que ha pasado el proceso para analizarlas después, aunque no es lo mismo. Acabo recurriendo, si se puede y por comodidad, a un sandbox copia recién hecha del entorno de producción (así además trabajamos con datos reales, que es bueno).
Al ser un servicio compartido, hay límites que en un servidor propio no existían: la capacidad de base de datos incluida en la suscripción es limitada (80GB por la suscripción y luego +3GB/licencia premium o +2GB/licencia essentials) y ampliarla tiene coste, y las operaciones tienen límites de tiempo de ejecución y de llamadas a las APIs. Conviene tenerlos presentes desde el principio, sobre todo si tienes procesos pesados o muchos años de histórico.
Realmente, la pregunta que debe responder una solicitud de migración es: ¿quieres una migración completa, con todos tus históricos, o una reimplantación? Lo más probable es que las dos requieran una reingeniería de procesos. Cada vez con más frecuencia los caminos de NAV y BC se separan a nivel de arquitectura y de desarrollo, y eso no tiene vuelta atrás.
Si estás valorando la migración, este es el inventario técnico que te recomiendo hacer primero. Cada elemento es algo que funcionaba en NAV y que tendrá que sustituirse en SaaS:
| En NAV | En Business Central SaaS |
|---|---|
| Modificaciones directas del código estándar | Extensiones AL basadas en eventos |
| Variables DotNet, DLL y componentes COM/Automation | AL nativo o servicios externos (por ejemplo, Azure Functions) |
| Accesos a rutas de red o al disco del servidor | Flujos de subida/descarga y almacenamiento en la nube |
| Impresoras instaladas en el servidor | Universal Print, impresoras por email o navegador |
| Integraciones por SOAP o con autenticación básica | REST API / OData v4 con OAuth 2.0 |
| Informes o integraciones que leen directamente de SQL | APIs, queries o réplicas analíticas |
| Procesos ejecutados por el NAS (NAV Application Server) | Job Queue y Task Scheduler |
Después de todo lo anterior, creo que la idea principal está clara: pasar de Navision a Business Central SaaS no consiste en mover lo que ya tienes a la nube y seguir trabajando igual. Cambian la infraestructura, el desarrollo, las integraciones y, en muchos casos, también los procesos.
¿Compensa? Para mí, sí. No echo de menos administrar servidores, pelearme con actualizaciones acumulativas ni trabajar directamente sobre el código estándar. Prefiero desarrollar con extensiones, controlar los cambios desde DevOps y apoyarme en herramientas de IA dentro de Visual Studio Code. Pero eso no significa que el camino sea automático ni que todo lo anterior pueda trasladarse sin más.
Habrá que revisar personalizaciones, rehacer integraciones y decidir qué merece la pena conservar. Algunas limitaciones de SaaS pueden resultar incómodas, pero también obligan a construir soluciones más mantenibles y preparadas para evolucionar.
Mi recomendación es sencilla: antes de hablar de fechas, haz inventario. Averigua qué has modificado, qué depende de SQL, qué procesos siguen siendo necesarios y cuáles sobreviven únicamente porque "siempre se ha hecho así". A partir de ahí podrás decidir si necesitas una migración completa o si una reimplantación tiene más sentido.
Si quieres hacer ese inventario con apoyo, en CrossPoint nuestro Assessment de Migración empieza justo por ahí: analizamos tu versión de NAV, tus personalizaciones, integraciones y dependencias de SQL para ayudarte a decidir entre migración completa y reimplantación, y qué merece la pena conservar.
¿Hablamos?
Actualizado en noviembre de 2026. Los límites y condiciones del servicio pueden cambiar: confírmalos en la documentación de Microsoft o con tu partner.
