Actualizar Business Central sin convertir cada nueva versión en un proyecto de riesgo
SaaS, on-premise, NAV, extensiones, apps, integraciones, fiscalidad, fabricación, datos, pruebas y cutover: actualizar bien significa mantener el ERP preparado para cambiar sin perder control.
Actualizar Dynamics 365 Business Central no debería empezar por una fecha de instalación. Debe empezar por saber qué versión tienes, qué depende de ella, qué procesos no pueden fallar y si realmente conviene actualizar, migrar a SaaS o reimplantar parte de la solución. En online, Microsoft mantiene un ciclo continuo de releases; en on-premise, la empresa controla el despliegue pero también asume más responsabilidad. En ambos casos, la diferencia entre una actualización rutinaria y una crisis suele estar en extensiones, integraciones, datos, pruebas y gobierno.
Actualizar no siempre es subir de versión. A veces significa migrar. Y otras, dejar de conservar una arquitectura que ya no merece seguir.
Una empresa en Business Central online puede estar totalmente al día y aun así necesitar trabajo para preparar la próxima release. Una empresa on-premise puede necesitar una actualización técnica. Otra puede acumular varias versiones y requerir pasos intermedios. Una organización todavía en NAV puede enfrentarse además a C/AL, SQL, integraciones antiguas e histórico.
Existe un escenario adicional que se pasa por alto: la versión es reciente pero los procesos siguen sostenidos por Excel, personalizaciones, informes manuales o interfaces frágiles. En ese caso, instalar una nueva versión no moderniza el ERP. Solo moderniza su número de versión.
El diagnóstico correcto separa mantenimiento de versión, migración de arquitectura y rediseño funcional. Mezclar los tres genera presupuestos difíciles de comparar y proyectos que cambian de objetivo durante la ejecución.
Antes de hablar de calendario, identifica qué significa “actualizar” en tu empresa
Cada punto de partida necesita una ruta, unos riesgos y un presupuesto distintos. Esta clasificación permite empezar con un objetivo explícito.
Nueva release SaaS
Microsoft mantiene plataforma y aplicación. La empresa debe validar extensiones, apps, integraciones, procesos críticos, permisos y cambios funcionales.
Versión reciente
Aplicar updates o avanzar versión manteniendo infraestructura, SQL, extensiones y modelo operativo dentro del soporte aplicable.
Varias versiones de retraso
Puede requerir saltos intermedios, conversión de código, compatibilidad de SQL/plataforma y una comparación seria con migración a SaaS.
Modernización, no simple update
Código C/AL, integraciones, histórico, versión SQL y procesos requieren una ruta específica antes de alcanzar Business Central actual u online.
On-Premise → SaaS
La versión es una parte. También cambian identidad, extensiones, conectividad, APIs, apps, operación, soporte y roadmap de innovación.
Versión actual, modelo agotado
El ERP está soportado pero convive con Excel, tareas manuales, interfaces frágiles o personalizaciones que dificultan cada cambio.
Business Central 28.4 ya muestra por qué “estar actualizado” es una disciplina continua, no una intervención semestral
Microsoft publica Business Central en release waves de seis meses y actualizaciones menores mensuales. En agosto de 2026, Microsoft Learn muestra la versión 28.4 dentro de 2026 release wave 1. La siguiente gran ola corresponde al ciclo que comienza en octubre.
La consecuencia para clientes y partners es importante: no tiene sentido esperar dos años para revisar compatibilidad. Extensiones, APIs, automatizaciones, apps, informes y procedimientos deberían mantenerse en un estado que permita absorber cambios pequeños de forma recurrente.
En SaaS, Microsoft gestiona la plataforma. Tú gestionas la preparación del negocio.
El Business Central administration center permite ver entornos, versiones, operaciones, notificaciones y configuración de updates. Los administradores pueden seleccionar una ventana de actualización, programar una fecha dentro del periodo disponible y crear sandboxes o entornos preview para pruebas.
Microsoft exige una ventana mínima de seis horas. Si una actualización no termina antes del fin de la ventana, se cancela para preservar disponibilidad y se reprograma automáticamente siete días después, salvo situaciones específicas del periodo obligatorio.
Esto permite gobernar cuándo se actualiza, pero no convierte SaaS en una plataforma congelable. El servicio está diseñado para evolucionar. El trabajo del cliente es mantener su solución preparada.
Update window
Zona horaria y periodo de al menos seis horas en el que Microsoft puede iniciar la actualización.
Next Update
Versión objetivo y fecha de próxima actualización visibles desde el admin center.
Notifications
Destinatarios informados cuando una versión queda disponible o se programa una actualización.
Sandbox
Entorno para reproducir procesos, extensiones, apps e integraciones antes de producción.
Preview
Permite preparar major releases con antelación y revisar nuevas capacidades.
Operations
Historial y estado de operaciones para investigar fallos y confirmar resultados.
Microsoft puede detectar incompatibilidad técnica. Solo tu empresa puede demostrar que el proceso sigue funcionando.
Antes de una major release, Microsoft comprueba rutinariamente las per-tenant extensions existentes frente a incompatibilidades técnicas. Si detecta problemas, envía notificaciones. Esto es útil, pero no prueba la lógica funcional.
Una extensión puede compilar y seguir generando un resultado erróneo al aplicar una dimensión, lote, divisa, workflow, devolución o proceso de cierre. Por eso Microsoft recuerda expresamente que la validación lógica y funcional sigue siendo responsabilidad del publisher y del cliente.
La estrategia madura combina validación técnica, regression tests funcionales y pruebas end-to-end del negocio.
Compatibilidad técnica
Compilación, APIs, símbolos, eventos, dependencias, obsolescencias y schemas.
Compatibilidad funcional
El resultado del proceso sigue siendo correcto para usuarios, negocio y contabilidad.
Compatibilidad operativa
Rendimiento, integración, jobs, impresión, automatización y secuencias siguen dentro de SLA.
Marketplace apps
El fabricante debe publicar versiones compatibles y mantener su app dentro del ciclo del producto.
PTE
El cliente/partner debe mantener su extensión propia compatible con próximas versiones.
Evidence
No basta con “funciona”: cada prueba crítica debería dejar resultado, responsable e incidencia.
Abrir una pantalla y crear un pedido no es probar una actualización
El test debe cubrir la cadena que crea valor y las excepciones que más daño pueden causar. Una actualización es segura cuando la empresa puede demostrar que procesos completos siguen funcionando, no cuando cada módulo responde por separado.
Una actualización industrial debe probar el flujo desde demanda hasta coste, no solo órdenes de producción
La fabricación concentra dependencias: artículo, BOM, ruta, política MRP, inventario, compras, capacidad, calendario, consumo, output, tracking y valoración. Un cambio aparentemente pequeño puede afectar fechas, disponibilidad o coste.
Además, nuevas funcionalidades como Quality Management o cambios en manufacturing analytics pueden crear oportunidades que merece evaluar durante la release, pero nunca a costa de mezclar validación obligatoria y adopción de novedad en el mismo paso.
MRP
Recalcular con datos representativos y comparar propuestas, mensajes de acción, fechas y cantidades.
BOM y rutas
Versiones, consumos, operaciones, tiempos, centros, máquinas y subcontratación.
Coste
Material, capacidad, indirectos, WIP y variaciones antes y después de la actualización.
Tracking
Lotes y series desde recepción, consumo, producción y expedición.
Warehouse
Recepción, ubicación, picking, movimientos y disponibilidad que alimenta planificación.
Power BI
Validar que datasets, APIs, semantic models e indicadores siguen recibiendo dato correcto.
La release puede cambiar el producto, pero una obligación legal puede cambiar el calendario del negocio
Business Central recibe cambios regulatorios y de localización a través de sus actualizaciones. En empresas multi-país, la gestión de versión debe coordinarse con localizaciones, apps fiscales, factura electrónica, bancos y cualquier solución que traduzca requisitos legales al ERP.
Una actualización que técnicamente funciona puede ser inaceptable si modifica un informe legal, una interfaz fiscal o una aplicación local sin prueba suficiente. Por eso el calendario debe incluir responsables financieros y fiscales, no solo IT.
Localización
Confirmar funcionalidades locales y cambios regulatorios de la versión destino.
Apps fiscales
Compatibilidad, versión, soporte del fabricante y pruebas con datos reales.
E-invoicing
Generación, firma, envío, recepción, estados, errores y trazabilidad.
Bancos
Ficheros, conexiones, conciliación y reglas de pago/cobro.
Calendario
Evitar ventanas cercanas a cierre, liquidaciones o hitos legales de alta criticidad.
Evidencia
Validación documentada por quienes responden del proceso legal y financiero.
La salud de una actualización se puede medir observando cuánto código propio necesita atención para sobrevivir a ella
Business Central moderno separa el estándar de las extensiones. Esa arquitectura permite evolucionar el core, pero no convierte el código propio en mantenimiento cero. Cada PTE necesita owner, repositorio, versión, pipeline, pruebas, dependencias y una estrategia de compatibilidad.
Microsoft dispone de analizadores, símbolos de obsolescencia y preview para anticipar cambios. Además, en online el propio servicio realiza comprobaciones técnicas de PTE antes de las major releases. Una organización que sigue corrigiendo extensiones en producción después de cada update necesita revisar su ALM, no culpar al calendario de Microsoft.
El mayor riesgo puede estar fuera de Business Central
Un ERP actualizado que deja de enviar pedidos al almacén, recibir producción del MES o conciliar bancos no está actualizado con éxito. Las interfaces deben inventariarse antes de estimar alcance y probarse con situaciones de error.
Conviene registrar para cada integración: owner, sistema maestro, endpoint, autenticación, frecuencia, volumen, SLA, mecanismo de reintento, logging, monitorización y procedimiento de contingencia. Este inventario también permite eliminar conexiones que ya no aportan valor.
| Integración | Qué probar | Excepción | Criterio de aceptación |
|---|---|---|---|
| API / web service | Autenticación, payload, respuesta y permisos. | Timeout, error 4xx/5xx, duplicado. | Sin pérdida ni duplicidad. |
| Power Automate | Triggers, conexiones, acciones y cuentas. | Conector expirado o cambio de schema. | Flujo completo y trazable. |
| MES / WMS / EDI | Secuencia, volumen, estados y reconciliación. | Caída, retraso, reintento. | Operación recuperable. |
| Power BI | APIs/queries, refresh, modelo y medidas. | Campo renombrado o dato vacío. | KPIs reconciliados. |
| Bancos / fiscal | Ficheros, respuesta, estados y firma. | Rechazo o formato inválido. | Aceptación por sistema destino. |
Actualizar on-premise significa intervenir sobre plataforma, aplicación, infraestructura y operación
Business Central on-premises 2019 release wave 2 y posteriores se encuentran bajo Modern Lifecycle Policy. Microsoft indica que el cliente controla sus despliegues y debe mantener el software al día de acuerdo con la política aplicable para recibir soporte.
A agosto de 2026, el lifecycle oficial muestra 28.x —2026 release wave 1— soportada hasta octubre de 2027; 27.x hasta abril de 2027 y 26.x hasta octubre de 2026. Estas fechas hacen visible el coste de retrasar decisiones: una versión puede pasar de “todavía funciona” a exigir una intervención urgente para volver a una rama soportada.
Ruta de versiones
Origen, destino, pasos intermedios, platform/application version y requisitos de upgrade.
SQL
Versión soportada, backup, espacio, rendimiento, conversión y estrategia de restore.
Infraestructura
Sistema operativo, certificados, red, almacenamiento, servicios, capacidad y monitorización.
Código
Extensiones, dependencias, APIs, permisos, compilación, eventos y datos de extensión.
Integraciones
Endpoints, autenticación, formatos, servicios, jobs y sistemas que dependen del ERP.
Operación
Ventana, freeze, comunicación, rollback, soporte, responsables y criterios de go/no-go.
La opción prudente es la que reduce coste futuro, no la que conserva más elementos del sistema actual
Conservar una solución estable puede ser eficiente. Conservar una acumulación de deuda porque “ya está pagada” puede hacer más caro cada siguiente cambio. La comparación debe medir esfuerzo inicial, riesgo, mantenimiento y capacidad futura.
Conservar el modelo
Encaja cuando procesos, datos, código e integraciones están controlados y el objetivo es avanzar versión con bajo rediseño.
Cambiar arquitectura
Encaja cuando la compañía quiere pasar a SaaS, reducir infraestructura o cambiar el modelo de integración y actualización.
Rediseñar el ERP
Encaja cuando conservar personalizaciones, datos y procesos heredados cuesta más que construir una configuración limpia.
Desde NAV, la actualización es también una decisión sobre código C/AL, datos e historia
Las versiones NAV no representan un único punto de partida. La ruta depende de versión, personalizaciones, add-ons, SQL, objetos, integraciones y modelo de destino. En muchos casos, llegar a Business Central online exige pasos técnicos intermedios.
La pregunta económica es si merece convertir cada objeto. Muchas personalizaciones existen porque hace años el estándar no resolvía algo que hoy ya cubre Business Central, una app, Power Platform o una integración moderna.
Por eso una migración desde NAV debería producir un inventario funcional, no solo técnico: qué conservar, qué sustituir, qué archivar, qué automatizar y qué retirar.
C/AL
Clasificar objetos, uso, owner, alternativa estándar y necesidad de conversión a AL.
Histórico
Distinguir operación, consulta, auditoría y analítica para no migrar todo al ERP productivo.
Integraciones
Sustituir accesos directos y tecnologías antiguas por APIs y patrones soportables.
Datos
Depuración de clientes, proveedores, artículos, dimensiones y datos maestros antes del cambio.
Reimplantación
Comparar coste de conversión con construir un modelo limpio cuando la deuda domina la solución.
Coste
Versiones, código, datos e integraciones explican más que el número de usuarios.
“¿Cuánto cuesta actualizar Business Central?” solo tiene sentido después de saber qué estamos actualizando
Una release SaaS recurrente puede requerir un esfuerzo pequeño y predecible cuando extensiones, apps y pruebas están bien gobernadas. Un salto on-premise con años de retraso puede convertirse en un proyecto relevante. Una migración desde NAV puede incluir conversión, reimplantación parcial, infraestructura, datos e integraciones.
Una estimación útil separa diagnóstico, preparación técnica, adaptación de código/apps, datos, integraciones, pruebas, formación, cutover y hypercare. También identifica qué depende de terceros y qué trabajo interno debe aportar el cliente.
Versión
Origen, destino y número de saltos o conversiones necesarias.
Código
Cantidad, calidad, dependencias, pruebas y disponibilidad de una versión compatible.
Datos
Volumen, campos personalizados, limpieza, histórico y tiempos de conversión.
Integraciones
Número, criticidad, tecnología, cambios de autenticación y pruebas.
Operación
Ventana de parada, sociedades, países, horarios y procesos críticos.
Personas
Usuarios clave, owners, terceros y capacidad interna para validar y decidir.
La actualización debe poder repetirse por otro equipo leyendo un procedimiento, no depender de memoria individual
Un runbook transforma conocimiento tácito en un proceso operable. Debe indicar secuencia, responsables, evidencias, puntos de decisión, comunicación, rollback o alternativa y criterios de cierre.
No programes producción porque “parece que todo está bien”. Define antes qué debe estar verde.
Un go/no-go profesional evita decidir bajo presión. Los criterios deben acordarse antes de la ventana de actualización y distinguir bloqueantes de incidencias aceptables con workaround.
Extensiones
Todas las críticas compatibles, desplegadas y probadas en versión destino.
Integraciones
Flujos críticos probados en ambos sentidos y con escenarios de error.
Procesos
Casos críticos aceptados por owners con evidencia y sin bloqueantes.
Soporte
Equipo y proveedores disponibles durante la ventana y primeras horas posteriores.
Contingencia
Alternativa documentada para cada proceso que no puede detenerse.
Decisor
Persona autorizada para aprobar, aplazar o abortar con criterios preacordados.
La posibilidad de volver atrás cambia entre SaaS y on-premise, pero la necesidad de contingencia existe en ambos
En Business Central online, Microsoft gestiona el proceso de actualización del entorno y dispone de mecanismos operativos para cancelar determinadas actualizaciones y restaurar el estado inmediatamente anterior durante ese proceso. Eso no significa que el cliente pueda tratar una major release como un despliegue local que revierte libremente semanas después.
En on-premise, un rollback puede implicar base de datos, aplicación, servicios, extensiones y sistemas externos. Requiere backup consistente, procedimiento, tiempos medidos y cuidado con transacciones generadas después del punto de retorno.
La contingencia empresarial debe responder qué hará cada proceso si la actualización no se completa a tiempo o si una integración crítica falla después del cambio.
Técnica
Restore, cancelación, reversión, logs, copias, versiones, paquetes y secuencia de sistemas dependientes.
Operativa
Cómo facturar, recibir, producir, expedir, pagar o registrar si el sistema no está disponible en la ventana prevista.
Datos
Qué transacciones pueden haber ocurrido durante la ventana y cómo se evita pérdida o duplicidad al recuperar.
Gobierno
Quién decide activar contingencia, cuándo se comunica y qué criterio devuelve la operación a normalidad.
No conviertas cada release en un proyecto de transformación. Pero tampoco ignores la oportunidad de retirar deuda.
El objetivo de la rutina SaaS es que la actualización técnica sea predecible. Eso no significa activar todas las novedades. La organización puede separar dos carriles: compatibilidad obligatoria y adopción de innovación.
Después de asegurar continuidad, un pequeño comité puede revisar nuevas capacidades que reduzcan personalización, mejoren productividad o habiliten automatización. Así la empresa obtiene valor de mantenerse actualizada sin inflar cada release.
La actualización debe revisar también lo que vive alrededor del ERP
Power Automate puede depender de conectores, campos y permisos. Power BI puede depender de APIs, queries y modelos semánticos. Power Apps puede usar Dataverse o endpoints del ERP. Copilot y agentes necesitan permisos, contexto y capacidades online compatibles.
Una release bien gobernada incorpora estos activos al inventario de dependencias y evita tratarlos como proyectos ajenos a Business Central.
Power Automate
Conexiones, triggers, acciones, cuentas, permisos y lógica de excepción.
Power Apps
Conectores, Dataverse, roles, datos y operaciones sobre Business Central.
Power BI
Refresh, APIs, queries, semantic models, RLS y reconciliación de KPIs.
Copilot
Disponibilidad de capacidades, permisos, idioma/región y cambios relevantes para usuarios.
Agentes
Acciones, scopes, auditoría y límites de autonomía deben seguir alineados con versión y modelo de datos.
Gobierno
Ownership, entornos, ALM y criterios de cambio comunes para evitar automatización huérfana.
La mejor señal de una solución sana es que actualizar cada vez cuesta menos riesgo, no que se haga cada vez más tarde
Una organización puede medir su madurez de actualización. Los indicadores no sirven para premiar rapidez, sino para detectar si deuda técnica, falta de pruebas o dependencia de terceros están aumentando.
Lead time
Días desde preview/disponibilidad hasta entorno preparado y aceptado.
PTE incompatibles
Número de extensiones propias que requieren corrección para cada major update.
Incidencias post-update
Severidad, recurrencia y causa raíz tras cada actualización.
Cobertura de pruebas
Porcentaje de procesos críticos con caso, owner y evidencia actualizada.
Automatización test
Parte de la regresión que puede repetirse sin intervención manual.
Deuda retirada
Extensiones, interfaces e informes eliminados o simplificados durante el ciclo.
A veces la versión no está bloqueada. Lo está el modelo de servicio.
Una relación de soporte puede convertirse en reactiva: incidencias que se repiten, documentación incompleta, código sin repositorio claro, integraciones conocidas por una sola persona, releases tratadas como urgencias y ninguna hoja de ruta funcional.
Cambiar de partner no debería empezar por sustituir al proveedor el mismo día. Empieza por asegurar accesos, repositorios, licencias, entornos, documentación, apps, credenciales, SLAs, integraciones y conocimiento suficiente para proteger continuidad.
Doce formas de convertir una actualización en una incidencia de negocio
Modernizar no siempre significa hacer el mismo proyecto
Estas referencias muestran contextos diferentes de Business Central. CYCASA es especialmente relevante como ejemplo de revisión y reimplantación desde una base NAV; Massada, IED Electronics y JIT Housing ilustran otros modelos operativos sobre Business Central. No se presentan como proyectos equivalentes de actualización.
Reimplantación sobre Business Central
Un caso relevante para entender por qué auditar el entorno anterior puede llevar a reimplantar en lugar de conservar cada decisión histórica.
Gestión y operaciones conectadas
Business Central como base integrada para procesos de gestión, fabricación, compras y trazabilidad.
Plataforma para crecimiento industrial
Una referencia de electrónica industrial donde robustez e integración son parte del valor del ERP.
Business Central en construcción industrializada
Un contexto en el que procesos industriales, información y trazabilidad necesitan evolucionar de forma conectada.
Actualizar Business Central puede cruzar ERP, Azure, Power Platform, seguridad, datos e IA
Cuando una actualización afecta a integraciones, reporting, infraestructura, identidad o automatización, el proyecto necesita más que conocimiento de versión. La capacidad end-to-end permite tratar dependencias y futuro dentro del mismo diseño.
El siguiente paso depende de tu punto de partida
Dudas habituales al actualizar Business Central
¿Cada cuánto se actualiza Business Central online?
Business Central tiene dos grandes ciclos al año, iniciados en abril y octubre, y actualizaciones menores en otros meses. Microsoft Learn indica además que las minor updates se publican mensualmente.
¿Cuál es la versión actual de Business Central en agosto de 2026?
Microsoft Learn muestra Business Central 28.4 como actualización de agosto de 2026 dentro de 2026 release wave 1.
¿Puedo evitar indefinidamente una actualización de Business Central SaaS?
No. El servicio está diseñado para mantenerse actualizado. Puedes gestionar fecha y ventana dentro de los periodos permitidos, pero no convertir online en una plataforma congelada permanentemente.
¿Cuánto debe durar la update window?
Microsoft exige una ventana mínima de seis horas para un entorno online. La ventana debe configurarse en el Business Central administration center.
¿Qué ocurre si la actualización no termina dentro de la ventana?
Microsoft indica que se cancela para garantizar disponibilidad y se reprograma automáticamente siete días después, salvo condiciones específicas del periodo obligatorio.
¿Qué es un preview environment?
Un sandbox en una versión preview que permite probar funcionalidad y compatibilidad antes de una major release. Microsoft suele poner la preview disponible aproximadamente un mes antes.
¿Microsoft comprueba mis extensiones antes de una major release?
Business Central realiza comprobaciones técnicas rutinarias sobre per-tenant extensions y notifica incompatibilidades detectadas. Esto no sustituye las pruebas funcionales del cliente.
¿Qué debo probar antes de actualizar?
Procesos críticos end-to-end, extensiones, apps, integraciones, informes, permisos, jobs, automatizaciones, fiscalidad y excepciones. No basta con abrir el sistema o crear documentos simples.
¿Tengo que probar también Power BI y Power Automate?
Sí cuando dependen de Business Central. APIs, queries, conectores, permisos o schemas pueden afectar a refreshes, flujos y aplicaciones periféricas.
¿Qué hay que probar en fabricación?
MRP, BOM, rutas, órdenes, consumos, outputs, capacidad, lotes/series, warehouse, costes, scrap e integraciones con MES o sistemas de planta.
¿Qué pasa con las aplicaciones de terceros?
Debes confirmar que el fabricante ofrece una versión compatible con la versión objetivo, conocer sus dependencias y probar el proceso funcional que cubre la app.
¿Actualizar una PTE significa solo recompilar?
No. Además de compatibilidad técnica hay que validar lógica, datos, permisos, integraciones y comportamiento funcional con la versión nueva.
¿Business Central on-premise sigue soportado?
Sí para versiones dentro de la política aplicable. Desde 2019 release wave 2, Business Central on-premises está bajo Modern Lifecycle Policy y el cliente debe mantenerse al día según esa política.
¿Hasta cuándo está soportada la versión 28.x on-premise?
La página oficial de lifecycle de Microsoft muestra 2026 release wave 1, versión 28.x, con soporte hasta el 13 de octubre de 2027.
¿Y la versión 26.x?
Microsoft muestra 2025 release wave 1, versión 26.x, con fin de soporte en octubre de 2026. Conviene revisar la fecha exacta y planificar con margen.
¿Puedo saltar directamente desde cualquier versión on-premise?
No siempre. La ruta depende de la versión de origen, versión destino, plataforma y requisitos de upgrade publicados por Microsoft.
¿Actualizar y migrar a SaaS es lo mismo?
No. Actualizar puede mantener on-premise y avanzar de versión. Migrar a SaaS cambia el modelo de despliegue, identidad, operación, integración y mantenimiento.
¿Cuándo conviene reimplantar?
Cuando conservar código, datos, procesos e integraciones heredadas cuesta más que construir un modelo limpio y la empresa está dispuesta a revisar cómo trabaja.
¿Se puede actualizar desde NAV a Business Central online?
Sí, pero normalmente mediante rutas intermedias según versión. Además, las personalizaciones C/AL deben transformarse a AL, sustituirse o retirarse.
¿Debo migrar todo el histórico de NAV?
No necesariamente. Conviene separar datos necesarios para operar, histórico útil para consulta y datos que pueden archivarse o explotarse en una capa analítica.
¿Cómo sé si una actualización está lista para producción?
Mediante criterios de go/no-go acordados: extensiones compatibles, integraciones probadas, procesos críticos aceptados, incidencias bloqueantes cerradas, soporte disponible y contingencia definida.
¿Qué es hypercare?
Un periodo de soporte reforzado después del cambio para monitorizar procesos, clasificar incidencias, reconciliar datos y estabilizar operación antes de volver al soporte normal.
¿Cuánto cuesta actualizar Business Central?
Depende del escenario. Una release SaaS bien gobernada puede ser un proceso recurrente; un salto on-premise o una migración desde NAV puede convertirse en un proyecto relevante. Hay que inventariar versión, código, datos e integraciones.
¿Puede ser buen momento para cambiar de partner?
Sí si la relación actual genera dependencia, falta de documentación o mantenimiento reactivo. La transición debe planificarse antes del update para proteger accesos, código, integraciones y soporte.
¿Actualizar Business Central puede reducir deuda técnica?
Sí. Cada ciclo puede utilizarse para retirar extensiones, simplificar integraciones, sustituir funcionalidades por estándar y mejorar pruebas. Lo importante es separar compatibilidad obligatoria de iniciativas de transformación.
¿Qué debería quedar preparado para la siguiente release?
Inventario de dependencias, owners, test suite, calendario, repositorios, pipelines, documentación, contactos de terceros, criterios de go/no-go y lecciones aprendidas.
Criterios contrastados con Microsoft Learn
Esta guía utiliza como referencia la documentación oficial de Microsoft sobre ciclos de actualización, administración de entornos, compatibilidad de extensiones y lifecycle on-premise. Las fechas y versiones cambian; conviene revisarlas antes de tomar una decisión de proyecto.
Gestión de actualizaciones
Update windows, programación, notificaciones, operaciones y comportamiento ante fallos.
Novedades y versiones
Release waves, minor updates y versiones recientes de Business Central.
Apps y PTE
Preview, compatibilidad técnica y obligaciones para mantener apps/extensiones actualizables.
Revisa tu versión antes de que actualizar se convierta en una urgencia
Podemos analizar versión, modelo SaaS/on-premise, extensiones, apps, integraciones, datos, infraestructura, procesos críticos, pruebas, soporte y calendario para definir si conviene actualizar, migrar a SaaS, reimplantar o combinar la intervención técnica con una hoja de ruta funcional. La meta es salir de este ciclo con menos deuda y con la siguiente release ya preparada.
Cuéntanos qué versión utilizas y qué te preocupa de la actualización
Indícanos si estás en SaaS, Business Central on-premise o NAV, qué extensiones y apps utilizas, qué integraciones son críticas y qué fecha o release estás valorando. Revisaremos el escenario antes de proponer una ruta.