Migrar extensión Business Central a la nube: guía 2026

Migrar una extensión de Microsoft Dynamics 365 Business Central desde un entorno on-premise (o el antiguo NAV/Navision) a la nube SaaS es una decisión técnica y de negocio que muchas empresas españolas tienen pendiente. En 2026, con el programa de descuentos de Microsoft activo y el roadmap del producto cloud claramente priorizado, es el momento de planificarla con cabeza.

Esta guía explica qué implica realmente la migración, qué riesgos tiene, cuánto cuesta, en cuánto tiempo se hace y cómo Davisa acompaña el proceso para clientes con personalizaciones específicas (especialmente con la extensión dvproject).

Por qué migrar a Business Central Cloud en 2026

No es una decisión religiosa de “cloud es mejor que on-premise”. Es una decisión basada en datos:

1. Mantenimiento

Aspecto	On-premise	Cloud (SaaS)
Servidor	Lo gestionas tú o tu partner	Microsoft
Backups	Tu IT o un servicio externo	Incluidos, automáticos
Actualizaciones	1-2/año, requieren parar el sistema	Mensuales, sin parar
Seguridad y parches	Tu responsabilidad	Microsoft
Coste anual de mantenimiento	8-15% del proyecto, BREP 16% sobre licencia	Incluido en suscripción mensual

2. Acceso y movilidad

• ✓ Acceso desde cualquier sitio sin VPN.
• ✓ Apps móviles funcionando out-of-the-box.
• ✓ Integración nativa con Microsoft 365 (Teams, Outlook, SharePoint).

3. Funcionalidades nuevas

Microsoft prioriza el desarrollo en cloud. La IA (Copilot), las integraciones con Power Platform, las nuevas APIs, las mejoras del producto llegan primero a SaaS. On-premise queda en mantenimiento.

4. Programa Microsoft de transición 2026

Microsoft mantiene activo el programa de transición de NAV/BC on-premise a BC Cloud con:

• 40% de descuento en licencias el primer año (sobre coste recurrente cloud).
• Eliminación del BREP (cuota anual de mantenimiento on-premise).
• Pricing especial para migraciones de NAV 2013+ con personalizaciones.

Las condiciones específicas dependen del estado de tu licencia actual. Davisa, como partner Microsoft Solutions Partner Business Central, ayuda a estructurar la migración aprovechando estos descuentos.

Lo que sí cambia técnicamente

No es “subir el servidor a Azure”. Es un cambio de modelo:

De C/AL a AL

Si vienes de NAV (versiones 2018 y anteriores), tu código está en C/AL — un lenguaje propietario que Microsoft ha reemplazado por AL (basado en sintaxis moderna similar a C#/TypeScript). Toda personalización debe reescribirse en AL.

Herramientas que facilitan el trabajo:

• txt2al (Microsoft): convierte código C/AL a AL como punto de partida (no es automático al 100%).
• Code Analyzer (AppSourceCop, PerTenantCop): detecta incompatibilidades con SaaS.
• Visual Studio Code + AL Language extension: el IDE estándar.

Restricciones del entorno SaaS

Algunas cosas que funcionaban on-premise no funcionan en cloud:

• ✗ Acceso directo al sistema de archivos del servidor.
• ✗ Ejecutar procedimientos almacenados de SQL Server directamente.
• ✗ Llamar a EXE externos o COM.
• ✗ Modificar tablas del sistema.

Si tu personalización dependía de esto, hay que rediseñarla. Microsoft proporciona alternativas (APIs estándar, Azure Functions, Power Automate) — pero requieren trabajo.

Datos a migrar

• Datos maestros (clientes, proveedores, ítems, recursos, cuentas).
• Saldos iniciales contables.
• Documentos abiertos (pedidos en curso, facturas pendientes, jobs activos).
• Histórico que necesites consultar (con criterio — no todo el histórico tiene que migrar).

Las 6 fases de una migración tipo

Fase	Duración	Entregable
1. Análisis y gap	4-6 semanas	Documento de alcance + estimación firme
2. Refactorización a AL	8-16 semanas	Extensión publicable en cloud
3. Configuración entorno cloud	2-3 semanas	Tenant productivo + sandbox
4. Migración de datos	2-4 semanas	Datos completos en cloud
5. Pruebas y formación	3-4 semanas	UAT firmado + equipo formado
6. Arranque productivo	1-2 semanas	Sistema en producción + soporte 30 días

Total estándar: 3-5 meses. Casos complejos: hasta 12 meses.

Riesgos reales y cómo se mitigan

Riesgo 1: dependencia de conectividad

Si la oficina pierde internet, el ERP no está disponible.

Mitigación:

• Conexión secundaria 4G/5G como backup.
• Procedimientos de continuidad para situaciones críticas (emisión manual de albaranes, cierre diferido de caja).
• SLAs claros con el ISP.

Riesgo 2: incompatibilidades de código

Alguna personalización no encaja en las restricciones SaaS.

Mitigación:

• Análisis de gap en fase 1 antes de cualquier compromiso de plazos.
• Plan de rediseño funcional para cada incompatibilidad.

Riesgo 3: tiempos de respuesta diferentes

Operaciones masivas (recálculo de inventarios, cierres de periodo) pueden cambiar.

Mitigación:

• Rediseño de procesos batch a procesos asíncronos.
• Uso de Job Queue de BC para tareas largas.

Riesgo 4: actualizaciones automáticas

BC SaaS se actualiza mensualmente. Algo puede dejar de funcionar tras una actualización.

Mitigación:

• Entorno sandbox para probar cada actualización antes de prod.
• Suscripción a las notas de release de Microsoft.
• Plan de regresión automatizada de tests críticos.

Caso típico: cliente con NAV 2017 + extensión dvproject

Una constructora con NAV 2017, 25 usuarios, dvproject Construcción personalizado:

Antes:

• Servidor on-premise propio, mantenimiento IT externo: 15.000 €/año.
• BREP NAV + dvproject: ~14.000 €/año.
• Actualizaciones forzadas cada 2 años con downtime de 1 semana.
• Sin movilidad real (RDP desde móvil = experiencia mala).

Migración (proyecto 5 meses):

• Análisis de gap, refactorización código C/AL → AL, migración datos, formación.
• Inversión: ~70.000 € proyecto.
• Aprovecha descuento Microsoft 40% primer año.

Después:

• BC Cloud Premium 25 usuarios: ~2.100 €/mes neto tras descuento primer año.
• dvproject Cloud licencia anual.
• Sin servidor propio, sin BREP, sin mantenimiento IT.
• App móvil del jefe de obra funcionando.
• Actualizaciones mensuales sin parar.

Payback: 18-24 meses contando ahorros directos (servidor, BREP, mantenimiento IT) y mejora de productividad por movilidad.

Errores típicos al migrar

1. Migrar sin limpiar datos previos: si tu maestro de clientes tenía 12.000 registros con 4.000 duplicados, el cloud te los lleva todos. Limpia ANTES.
2. No hacer análisis de gap formal: empezar la refactorización sin saber qué encaja. Se descubre tarde y duele.
3. Subestimar formación del equipo: el interfaz cloud es similar pero no idéntico. Sin formación, baja la productividad las primeras semanas.
4. No prever procesos críticos sin internet: cierre de caja, emisión de albarán, captura de pedido en cliente — necesitan plan B.
5. Migrar todo el histórico: 15 años de movimientos contables migrados = ralentización y coste. Migra lo necesario, archiva el resto.

Cuándo NO migrar todavía

Honestidad: no toda migración es buena hoy.

• ✗ Si tu NAV/BC on-premise es estable, funciona y no tienes presión de innovación, puedes esperar 12-18 meses más. El producto cloud sigue mejorando.
• ✗ Si tu negocio depende de integraciones muy específicas con maquinaria local sin equivalente cloud, valora cuidadosamente.
• ✗ Si tu equipo IT no está preparado para gestionar el cambio cultural, prepáralo antes.

Cierre — la migración es un proyecto, no un upgrade

Migrar a Business Central Cloud no es pulsar un botón. Es un proyecto técnico que, bien hecho, da retorno claro en 18-24 meses y deja a la empresa con una base mucho más sólida para los siguientes 5-10 años.

Davisa Informática ha migrado decenas de clientes de NAV/BC on-premise a Business Central Cloud — con y sin dvproject. Si tu empresa está valorando este paso, habla con un asesor de Davisa. 30 minutos, te hacemos una valoración honesta del esfuerzo, los riesgos y los ahorros reales que aplicarían a tu caso.