Upgrade de Magnolia 6.2 a 6.3 destrabado en un día: el bloqueo estaba en el Content Editor

B-FY es una empresa española de ciberseguridad que opera su sitio sobre Magnolia. Su equipo técnico había decidido actualizar de la versión 6.2 a la 6.3 y llevaba tres semanas intentándolo sin conseguirlo.

Un upgrade que falla sin decir por qué es el caso difícil: el error aparece lejos de su causa, y la retrocompatibilidad que debería ayudar es justamente lo que lo esconde.

Magnolia 6.2 es la transición de la interfaz 5UI a la 6UI, con el salto de Vaadin 7 a Vaadin 8.

• Cambios de fondo entre interfaces: el paso de 5UI a 6UI cambió el namespacing de clases, los parámetros y las definiciones YAML.
• La red de seguridad enmascara: 6.2 mantiene retrocompatibilidad, así que lo que está mal sigue funcionando hasta que deja de hacerlo.
• Tres semanas sin causa raíz: el equipo interno había descartado lo evidente sin llegar al origen del bloqueo.

El costo no eran las horas sino quedar clavado en una versión vieja, que es como se acumula la deuda que después obliga a un proyecto entero.

El trabajo fue de diagnóstico y no de desarrollo: los bloques del cliente ya estaban en sintaxis 6UI, así que el error no estaba donde todos lo buscaban.

Descartado el contenido, quedaba el entorno. La causa estaba en un módulo que el propio bundle de Magnolia instala.

Dónde estaba realmente el bloqueo

• Las webapps y los bundles de Magnolia instalan Content Editor en la rama 1.3.x, que exige definiciones 5UI.
• Los bloques de B-FY ya estaban definidos en 6UI, así que el módulo y el contenido pedían cosas incompatibles.
• El síntoma aparecía en los bloques y la causa estaba en la versión del módulo que los interpreta.

La corrección

• Actualización del Content Editor module y de todas sus dependencias a la rama 2.1.x, mediante un parche en el POM de la WebApp.
• Paso de Stories App a la rama 2.x, por la misma dependencia.
• Resolución de las incompatibilidades del mismo tipo que fueron apareciendo después, una por una.

Verificación y salto

• Comprobación en el momento: el editor funcionando y los bloques renderizando en una página de prueba.
• El salto en sí fue casi instantáneo, aplicando el parche y actualizando la webapp, sin ventana de servicio.

Arquitectura y tecnología

• Magnolia CMS 6.2 a 6.3, con transición de interfaz 5UI a 6UI sobre Vaadin 8.
• Content Editor module 1.3.x a 2.1.x y Stories App a 2.x, vía parche en el POM de la WebApp.

Conocé más sobre soporte y mantenimiento de Magnolia.

Conocé más sobre desarrollo de software.

Tres semanas de intentos contra un día de trabajo, y la diferencia entera estuvo en el diagnóstico y no en la ejecución.

KPIs iniciales

• 3 semanas de intentos del equipo interno de B-FY sin lograr el upgrade.
• Instancia clavada en 6.2, con la causa raíz sin identificar.

KPIs alcanzados

• 1 día de trabajo para identificar la causa raíz y resolverla.
• Cero downtime: el salto fue casi instantáneo, sin ventana de servicio ni corte para el usuario final.
• Resultado verificado en el momento, con el editor operativo y los bloques renderizando.
• Hoy operan en 6.3 de forma estable.

Impacto estratégico

• La instancia dejó de acumular deuda de versión y quedó en condiciones de seguir actualizándose.
• Con la causa documentada, el equipo interno puede reconocer el mismo patrón en los próximos saltos.