Actualizar Business Central sin frenar el negocio ni arrastrar problemas
SaaS, on-premise, nuevas versiones, extensiones, integraciones, NAV y migración a la nube: cada escenario necesita una ruta distinta.
Actualizar Business Central no debería empezar descargando una versión ni reservando una ventana técnica. Debe empezar identificando qué necesita el negocio, qué riesgos existen, qué dependencias pueden romperse y si la empresa debe actualizar, migrar, reimplantar o rediseñar parte de su solución.
Evaluación inicial de versión, extensiones, personalizaciones, integraciones, infraestructura y continuidad operativa.
Actualizar Business Central no es una única operación
La misma búsqueda puede esconder situaciones completamente distintas. Una empresa en Business Central online puede necesitar preparar una nueva release y validar extensiones. Otra puede trabajar con Business Central on-premise y llevar varias versiones de retraso. Otra puede venir de NAV, mantener código C/AL y necesitar pasos intermedios antes de llegar a la versión actual o a SaaS.
También existe un cuarto caso: el sistema está técnicamente actualizado, pero los procesos, informes, integraciones y personalizaciones se han quedado atrás. En ese escenario, instalar la última versión no resuelve el problema. Solo actualiza la base tecnológica de una solución que sigue sin responder al negocio.
La ruta correcta depende de versión de origen, modelo de despliegue, extensiones, datos, arquitectura, criticidad operativa, soporte disponible y objetivo futuro. Empezar por el diagnóstico evita convertir una actualización en una cadena de incidencias.
Mantener el modelo actual, llevar plataforma y aplicación a una versión posterior y adaptar extensiones e integraciones.
Cambiar de versión, arquitectura o modelo de despliegue, trasladando datos y reconstruyendo las capacidades necesarias.
Rediseñar configuración, procesos y datos cuando conservar la estructura anterior cuesta más que construir un modelo limpio.
Qué debe resolver una actualización bien planteada
Antes de hablar de calendario, identifica qué significa “actualizar” en tu empresa
La decisión cambia por completo según el punto de partida. Mezclar escenarios genera presupuestos poco comparables, expectativas incorrectas y proyectos que empiezan sin saber qué se está intentando conseguir.
Business Central online ante una nueva release
La plataforma se mantiene dentro del servicio, pero la empresa debe probar extensiones, integraciones, procesos críticos y nuevas funcionalidades antes de la ventana de producción.
Objetivo: convertir cada actualización en una rutina controlada, no en una sorpresa semestral.
Business Central on-premise con una versión reciente
La empresa necesita aplicar actualizaciones acumulativas o avanzar a una nueva versión manteniendo infraestructura, extensiones y modelo operativo.
Objetivo: actualizar sin romper compatibilidades y sin dejar el entorno fuera de la política de soporte.
Business Central on-premise con varias versiones de retraso
La ruta puede exigir pasos intermedios, conversión de extensiones, revisión de SQL, plataforma, aplicaciones y componentes asociados.
Objetivo: definir una secuencia soportada y comparar su coste con una migración a SaaS.
Dynamics NAV o Navision
Las versiones antiguas pueden necesitar un salto previo a Business Central on-premise antes de migrar online. Además, las personalizaciones C/AL deben transformarse o replantearse.
Objetivo: no confundir actualización técnica con modernización del ERP.
Paso de on-premise a Business Central SaaS
No basta con mover datos. Hay que validar extensiones, identidades, integraciones, aplicaciones, histórico, seguridad y operación futura.
Objetivo: reducir deuda técnica y preparar el ERP para Microsoft 365, Power Platform, Copilot e IA.
Sistema actualizado, procesos agotados
La versión es reciente, pero persisten Excel, tareas manuales, informes lentos, integraciones frágiles y personalizaciones que dificultan cada cambio.
Objetivo: combinar actualización con una hoja de ruta funcional y de automatización.
En SaaS, Microsoft actualiza el servicio. La empresa debe asegurar que el negocio está preparado.
Business Central online cuenta con dos grandes ciclos de actualización al año, iniciados en abril y octubre, además de actualizaciones menores en otros meses. El servicio no está pensado para permanecer indefinidamente en una versión antigua. La ventaja es que la empresa evita grandes proyectos técnicos de plataforma; la exigencia es mantener extensiones, integraciones y procesos preparados para evolucionar.
El centro de administración permite gestionar ventanas y fechas, recibir notificaciones y trabajar con entornos sandbox. Microsoft recomienda probar las aplicaciones y procesos en un entorno que ejecute la nueva versión antes de desplegarla en producción. Esto convierte la actualización en un proceso de validación continua.
La organización que espera a la última semana para comprobar extensiones, informes o integraciones está usando mal el modelo SaaS. La actualización debe tener propietarios, calendario, criterios de prueba y evidencias de aceptación.
El objetivo no es impedir que cambie la versión. Es conseguir que cada cambio llegue probado, documentado y con una respuesta clara ante cualquier incidencia.
Crear o actualizar una sandbox con la nueva versión y datos suficientemente representativos para validar los procesos críticos.
Comprobar compatibilidad, dependencias, permisos, cambios de API, disponibilidad de nuevas versiones y soporte del fabricante.
Probar intercambios de datos, colas, APIs, conectores, automatizaciones, interfaces bancarias y sistemas externos.
Validar cierres, facturación, compras, cobros, pagos, inventario, fabricación, proyectos y obligaciones legales.
Comunicar novedades relevantes, preparar instrucciones y evitar que los usuarios descubran cambios durante una operación crítica.
Definir responsables, evidencias, incidencias bloqueantes, alternativas operativas y comunicación durante el despliegue.
Abrir pantallas no es probar una actualización
La prueba debe reproducir operaciones completas y excepciones reales. Una extensión puede instalarse correctamente y fallar cuando interviene una dimensión, un lote, una devolución, una divisa, una aprobación o una integración. Los casos deben diseñarse alrededor del riesgo empresarial.
Registro, impuestos, dimensiones, bancos, conciliación, pagos, cobros, diferimientos, activos, consolidación y cierre.
Pedidos, precios, descuentos, aprobaciones, reservas, entregas, devoluciones, facturas, abonos y documentos electrónicos.
Recepciones, ubicaciones, lotes, series, transferencias, picking, inventarios, valoración y conexión con almacenes externos.
Listas, rutas, consumos, producción, capacidad, costes, partes, recursos, planificación, avances y facturación.
CRM, comercio electrónico, nómina, bancos, EDI, SGA, MES, portales, Power Platform, Power BI y aplicaciones sectoriales.
Errores de datos, documentos bloqueados, permisos, reintentos, anulaciones, caídas de servicios y operaciones fuera del flujo ideal.
En local, actualizar significa intervenir sobre más capas y asumir más responsabilidad
Microsoft mantiene Business Central on-premise bajo sus políticas de ciclo de vida, pero el soporte exige conservar el software dentro de las condiciones aplicables. La empresa controla el calendario y la instalación, aunque también debe coordinar plataforma, aplicación, base de datos, extensiones, infraestructura, seguridad y pruebas.
| Capa | Qué debe revisarse | Riesgo si se ignora |
|---|---|---|
| Ruta de versiones | Compatibilidad entre origen y destino, actualizaciones intermedias, versión de aplicación y versión de plataforma. | Elegir un salto no soportado o descubrir tarde que hacen falta varias etapas. |
| Base de datos y SQL | Versiones compatibles, rendimiento, copias, espacio, conversión y recuperación. | Paradas prolongadas, errores de conversión, degradación o imposibilidad de volver atrás. |
| Infraestructura | Servidores, sistema operativo, almacenamiento, redes, certificados, servicios y capacidad. | Actualizar el ERP sobre una base tecnológica que ya está cerca de quedar obsoleta. |
| Extensiones y código | Compatibilidad, compilación, eventos, APIs, permisos, dependencias y versión de cada aplicación. | Bloqueo del proyecto, pérdida de funcionalidad o creación de una nueva capa de deuda. |
| Integraciones | Servicios, interfaces, endpoints, autenticación, formatos, colas, ficheros y tareas programadas. | Un ERP disponible que no puede recibir pedidos, emitir pagos o alimentar sistemas externos. |
| Datos | Calidad, volumen, campos personalizados, tablas heredadas, histórico y tiempos de conversión. | Ventanas de parada irreales, errores de negocio y arranque con información inconsistente. |
| Operación | Plan de despliegue, aceptación, responsables, soporte, comunicación, contingencia y vuelta atrás. | Improvisación durante el arranque y decisiones críticas tomadas bajo presión. |
Una actualización acumulativa no es lo mismo que un salto de versión
Aplicar correcciones dentro de una versión puede ser una intervención acotada. Saltar entre versiones mayores puede afectar a plataforma, código, extensiones, base de datos, compatibilidad y modelo funcional. El alcance debe definirse con precisión antes de comprometer plazo y presupuesto.
Actualizar la versión actual, migrar a SaaS o reimplantar: tres caminos con costes distintos
La actualización conserva buena parte del modelo existente. Suele encajar cuando procesos, datos, personalizaciones e integraciones están razonablemente controlados y la organización necesita avanzar de versión sin rediseñar la solución.
La migración a SaaS añade una decisión de arquitectura. Puede reducir infraestructura y facilitar futuras actualizaciones, integración e innovación, pero obliga a revisar extensiones, conectividad, identidades, aplicaciones y dependencia de componentes locales.
La reimplantación tiene sentido cuando el ERP se ha convertido en una acumulación de código, datos, procesos y excepciones difíciles de sostener. Es más exigente desde el punto de vista organizativo, pero puede ser más rentable que reconstruir cada personalización antigua.
Encaja cuando: la solución funciona, la deuda está controlada, la ruta es soportada y el objetivo principal es mantener soporte, seguridad y acceso a mejoras.
Encaja cuando: la empresa quiere reducir infraestructura, actualizar de forma continua y conectar el ERP con el ecosistema Microsoft.
Encaja cuando: conservar el diseño anterior exige más esfuerzo que configurar un modelo limpio y la organización está preparada para revisar procesos y datos.
Cuándo una actualización deja de ser la opción prudente
Una versión nueva no arregla automáticamente procesos viejos
Actualizar puede ser una oportunidad para retirar personalizaciones, mejorar datos, ordenar permisos, simplificar integraciones y eliminar tareas manuales. También puede convertirse en una mudanza costosa si el proyecto se limita a reproducir cada decisión histórica.
La pregunta correcta no es “¿podemos llevarlo?”. Es “¿merece la pena llevarlo y qué debería sustituirlo?”.
El mayor riesgo no suele estar en Business Central. Está en todo lo que se ha construido alrededor.
Un ERP puede actualizarse correctamente y dejar de operar como sistema empresarial porque una extensión, interfaz, fichero, servicio o automatización ya no responde como antes. Por eso el inventario de dependencias debe realizarse antes de estimar el proyecto.
Extensiones propias
Revisar código, eventos, APIs, tablas, permisos, dependencias, pruebas existentes, documentación y capacidad del equipo para mantenerlas.
Aplicaciones de terceros
Confirmar versiones disponibles, roadmap, licencias, compatibilidad con el destino, soporte del fabricante y posibles cambios funcionales.
Integraciones
Identificar endpoints, autenticación, formatos, propietarios, frecuencia, volumen, errores, reintentos y respuesta ante indisponibilidad.
Informes y analítica
Comprobar informes personalizados, Excel conectados, Power BI, consultas, vistas, réplicas, data warehouses y procesos de cierre.
Automatizaciones
Revisar tareas programadas, flujos de Power Automate, colas, servicios, robots, procesos nocturnos y dependencias de cuentas técnicas.
Conocimiento
Saber quién entiende cada componente, qué documentación existe y qué ocurriría si la persona o proveedor clave no estuviera disponible.
Qué determina el coste de actualizar Business Central
No existe una tarifa universal porque la actualización puede ir desde validar una nueva release online hasta transformar una solución on-premise con varias versiones de retraso, código heredado e integraciones críticas.
La estimación debe separar diagnóstico, preparación técnica, adaptación de extensiones, migración de datos, pruebas, formación, despliegue y soporte posterior. También debe dejar claro qué asume el cliente, qué depende de terceros y qué riesgos pueden modificar el alcance.
Una oferta económica sin inventario de personalizaciones e integraciones no es una estimación precisa. Es una hipótesis comercial que probablemente cambiará cuando aparezca la complejidad real.
Dependencias no documentadas, desarrollos sin propietario, integraciones ocultas y requisitos que aparecen durante las pruebas.
Usuarios clave no disponibles, ventanas irreales, retrasos de terceros o falta de tiempo para repetir pruebas completas.
Procesos críticos que no se validan, contingencias inexistentes o arranque sin capacidad suficiente de soporte.
Invertir en una actualización que mantiene la empresa atrapada en la misma arquitectura y obliga a repetir el proyecto poco después.
Cómo actualizar Business Central con control
La secuencia debe proteger la operación y, al mismo tiempo, impedir que el proyecto se limite a conservar deuda técnica. Cada fase debe producir decisiones, evidencias y responsables claros.
Diagnóstico
Versión, despliegue, infraestructura, extensiones, datos, integraciones, procesos, soporte, incidencias y objetivos del negocio.
Elección de ruta
Comparar actualización, migración a SaaS y reimplantación según coste, riesgo, tiempo y arquitectura futura.
Inventario de dependencias
Clasificar aplicaciones, código, interfaces, informes, tareas, cuentas técnicas y responsables.
Preparación
Adaptar extensiones, actualizar aplicaciones, limpiar datos, preparar infraestructura, crear entornos y definir casos de prueba.
Pruebas integrales
Validar procesos completos, excepciones, seguridad, rendimiento, informes e integraciones con usuarios responsables.
Ensayo y transición
Medir tiempos, documentar pasos, preparar contingencia, formar usuarios y confirmar criterios de aceptación.
Despliegue
Ejecutar la actualización con responsables, seguimiento, comunicación, soporte reforzado y control de incidencias.
Estabilización y evolución
Cerrar incidencias, documentar, medir resultados y activar la hoja de ruta funcional, de automatización, datos e IA.
Cuándo no conviene aplazar más la actualización
No toda versión antigua exige una intervención inmediata, pero algunas señales indican que la empresa está acumulando un riesgo que ya afecta a continuidad, coste o capacidad de evolución.
El problema más serio no es estar una versión por detrás. Es no saber cuánto costaría actualizar, depender de un entorno sin soporte suficiente y descubrir la complejidad cuando aparece una necesidad urgente.
Actualizar también puede ser el momento de cambiar de partner
Algunas empresas no están bloqueadas por Business Central, sino por una relación de servicio que se ha vuelto reactiva. Falta documentación, las mejoras se eternizan, las incidencias no se convierten en aprendizaje y nadie plantea cómo preparar la siguiente versión.
Un cambio de partner no debe comenzar tocando el sistema. Debe comenzar revisando accesos, contratos, licencias, documentación, desarrollos, integraciones, incidencias, entornos y conocimiento. La actualización puede ser una oportunidad para ordenar esa transición, pero no conviene mezclar ambos movimientos sin un plan de continuidad.
Saber qué existe, quién lo controla, qué documentación falta y qué riesgos están abiertos.
Asegurar soporte durante el traspaso, la actualización, las pruebas y la estabilización.
Pasar de resolver incidencias a gestionar versiones, mejoras, automatización y adopción.
Ocho formas de convertir una actualización en un problema
Empezar sin inventario
Las dependencias aparecen durante el proyecto y transforman una estimación controlada en una negociación permanente.
Probar solo el estándar
Los procesos básicos funcionan, pero fallan extensiones, informes, interfaces o excepciones que sostienen la operación real.
No reservar usuarios clave
La validación se retrasa o la realiza alguien que no puede confirmar si el resultado es correcto para el negocio.
Migrar todo el histórico
Aumenta tiempo, complejidad y coste sin demostrar que toda la información deba seguir dentro del ERP operativo.
Conservar cada personalización
Se paga por reconstruir limitaciones antiguas en lugar de aprovechar estándar, extensiones modernas o Power Platform.
No ensayar la parada
La ventana se calcula por intuición y el negocio descubre demasiado tarde cuánto dura la conversión real.
Olvidar la adopción
Los usuarios reciben una versión nueva, pero no entienden cambios, mejoras ni nuevos procedimientos.
No definir el siguiente paso
La empresa invierte en actualizar y vuelve inmediatamente al mantenimiento reactivo sin una hoja de ruta de evolución.
Conecta la actualización con la decisión empresarial completa
La versión es solo una pieza. El modelo de despliegue, la migración desde NAV, el coste del proyecto, el soporte y la estrategia de automatización determinan el valor real de la actualización.
Capacidades, implantación, migración, comparativas, integraciones y evolución del ERP Microsoft.
Coste total, seguridad, control, actualizaciones, integraciones, Copilot e IA.
Escenarios de inversión según personalización, datos, integraciones, usuarios y ambición.
Aplicaciones, flujos, datos y automatización alrededor de Business Central con gobierno.
Cómo preparar ERP, datos, procesos e integraciones para Copilot y agentes inteligentes.
Designaciones, especializaciones, certificaciones y capacidad para proyectos Microsoft empresariales.
Dudas habituales al actualizar Business Central
¿Cada cuánto se actualiza Business Central online?
Microsoft organiza dos grandes ciclos de actualización al año, iniciados en abril y octubre, y publica actualizaciones menores en otros meses. Los administradores pueden gestionar fechas y ventanas dentro de los periodos disponibles y preparar entornos sandbox para validar la nueva versión.
¿Se puede evitar una actualización de Business Central SaaS?
El servicio online está diseñado para mantenerse actualizado. Es posible gestionar la programación dentro de las opciones disponibles, pero no conservar indefinidamente una versión antigua. La estrategia correcta es probar con antelación y mantener extensiones e integraciones preparadas.
¿Qué hay que probar antes de actualizar?
Procesos críticos completos, extensiones, integraciones, informes, permisos, automatizaciones y excepciones. No basta con acceder al sistema o crear un documento sencillo. Las pruebas deben cubrir cierres, facturación, pagos, inventario, fabricación, proyectos y operaciones específicas de la empresa.
¿Cómo sé qué versión de Business Central tengo?
La información de versión puede consultarse desde el entorno y, en Business Central online, desde el centro de administración. Para definir una ruta correcta también conviene identificar versión de aplicación, plataforma, extensiones instaladas y modelo de despliegue.
¿Puedo actualizar directamente desde cualquier versión on-premise?
No siempre. Microsoft publica rutas de actualización y matrices de compatibilidad. Según la versión de origen, puede ser necesario pasar por versiones intermedias. La ruta debe confirmarse antes de estimar alcance, calendario y ventana de parada.
¿Se puede actualizar desde NAV a Business Central online?
Sí, pero las versiones antiguas de NAV no migran directamente a la nube. Microsoft indica que deben actualizarse primero a una versión compatible de Business Central on-premise. Además, las personalizaciones C/AL deben convertirse en extensiones AL o replantearse mediante una reimplantación.
¿Actualizar y migrar a SaaS es lo mismo?
No. Actualizar puede significar avanzar de versión manteniendo el modelo on-premise. Migrar a SaaS implica cambiar el modelo de despliegue y revisar identidades, extensiones, integraciones, datos, aplicaciones y operación dentro del servicio online.
¿Qué ocurre con las personalizaciones?
Deben inventariarse y clasificarse. Algunas se adaptan, otras se sustituyen con estándar o aplicaciones, otras pueden resolverse con Power Platform y otras deberían retirarse. Mantenerlas todas sin análisis suele aumentar coste y deuda técnica.
¿Cuánto dura una actualización de Business Central?
Depende de la versión, el modelo de despliegue, los pasos intermedios, el volumen de datos, las extensiones, las integraciones y la disponibilidad de usuarios para probar. Una release SaaS puede requerir una preparación recurrente; un salto de varias versiones on-premise puede convertirse en un proyecto de varios meses.
¿Cuánto cuesta actualizar Business Central?
El coste depende de la ruta, personalizaciones, datos, infraestructura, integraciones y pruebas. Para estimarlo hay que realizar un diagnóstico. Dar una cifra cerrada sin revisar estas variables suele generar desviaciones posteriores.
¿Cuándo conviene reimplantar en lugar de actualizar?
Cuando la solución acumula demasiadas personalizaciones, procesos obsoletos, datos inconsistentes, integraciones frágiles y conocimiento no documentado. La reimplantación permite construir un modelo más limpio, aunque exige mayor participación del negocio y gestión del cambio.
¿Puede Ayesa hacerse cargo si el partner actual no responde?
Sí. El primer paso debe ser revisar accesos, documentación, licencias, desarrollos, integraciones, incidencias, entornos y responsabilidades. Después se puede plantear una transición ordenada, la actualización y una hoja de ruta de evolución sin comprometer la continuidad.
Criterios contrastados con Microsoft Learn
La página se apoya en la documentación oficial sobre ciclos de actualización, gestión desde el centro de administración, política de soporte on-premise, rutas de actualización y migración desde NAV o Business Central local.
Revisa tu versión antes de que la actualización se convierta en una urgencia
Podemos analizar tu entorno y definir si conviene actualizar, migrar a Business Central SaaS, reimplantar o combinar la intervención técnica con una hoja de ruta funcional.