Bramvia — Business Central Experts
Tu ERP se actualiza solo: cómo evitar que eso sea un problema
Business Central publica actualizaciones acumulativas cada mes y dos grandes oleadas al año, y en la nube se aplican automáticamente. Es una ventaja enorme — siempre que tengas un proceso. Aquí está el que usamos.
Una de las mayores ventajas de Business Central en la nube es que se actualiza solo. Se acabaron los proyectos de actualización de seis meses que caracterizaban a NAV.
También es la característica que más nervios genera en un director de TI: algo va a cambiar en tu sistema sin que tú lo decidas.
Ambas cosas son ciertas. La diferencia entre que sea una ventaja o un riesgo está enteramente en si tienes un proceso.
Qué se actualiza y cada cuánto
- Actualizaciones acumulativas: mensuales. La de agosto de 2026 corresponde a la versión 28.4. Incluyen correcciones y funcionalidad regulatoria.
- Oleadas mayores: dos al año. Traen funcionalidad nueva y son las que pueden cambiar comportamientos.
- Capacidades de IA: continuas. Copilot y los agentes evolucionan entre oleadas.
En la nube, los entornos se actualizan automáticamente en el plazo de unos días o semanas, con notificación por correo. Puedes influir en la ventana temporal, pero no evitar la actualización indefinidamente.
Dónde aparecen los problemas de verdad
Después de bastantes migraciones, el patrón se repite. Los problemas casi nunca vienen de la funcionalidad estándar de Microsoft, que llega muy probada. Vienen de:
Personalizaciones mal construidas. Si alguien modificó la aplicación base en lugar de crear extensiones limpias, cada actualización es una lotería. Esta es la razón número uno por la que una empresa acaba atrapada en una versión antigua.
Integraciones frágiles. Conexiones montadas contra estructuras internas en lugar de contra APIs. Funcionan hasta que la estructura cambia.
Informes que nadie prueba. Un informe crítico de cierre que falla el día 3 del mes, porque nadie lo ejecutó en el sandbox.
Procesos no documentados. Cuando algo cambia y nadie recuerda por qué se hacía así, el diagnóstico se alarga días.
El proceso que recomendamos
No es complicado, pero hay que tenerlo:
Mantén un entorno sandbox permanente. No uno que creas cuando hay problemas. Uno que existe siempre y refleja producción.
Activa el acceso anticipado a las oleadas mayores. Te da semanas de margen para probar antes de que llegue a producción.
Ten una lista de procesos críticos escrita. Cierre mensual, facturación, expedición, integraciones, los cinco informes que dirección mira. Se prueban siempre, en cada oleada.
Revisa las notas de la versión con criterio. No hace falta leerlo todo: busca lo que toca tus módulos y tus extensiones.
Asigna un responsable. Si la actualización es de todos, no es de nadie. Alguien debe mirar el correo de notificación y actuar.
Lo que esto significa al elegir partner
Aquí hay una consecuencia práctica que conviene tener clara al contratar desarrollo: la calidad del código determina cuánto te cuestan las actualizaciones durante los próximos diez años.
Una extensión bien construida, que se engancha a la funcionalidad estándar mediante eventos y no toca la base, sobrevive a las actualizaciones. Una modificación de la aplicación base funciona el primer día y se convierte en un lastre permanente.
Es una diferencia que no se ve en la demo ni en el presupuesto. Se ve dos años después.
Por eso, cuando evalúes propuestas, pregunta explícitamente: ¿esto se implementa como extensión o modificando el estándar? La respuesta te dice mucho más que el precio.
Si tu sistema actual da miedo actualizarlo
Es una señal, no un detalle técnico. Un ERP al que se teme actualizar acaba quedándose sin soporte, y eso sí es un problema de cumplimiento y de seguridad.
Podemos auditar tus personalizaciones e integraciones y decirte con honestidad si tu instalación está preparada para el ritmo de actualización de la nube, o qué habría que arreglar antes. La evaluación es gratuita.