Viene de una versión de Magento sin soporte: ¿debería apuntar a 2.4.8 o a 2.4.9?

Si su tienda está en Magento 2.4.6 o anterior, ahora mismo corre sin parches de seguridad, y la decisión que tiene delante es en qué versión aterrizar. 2.4.8 está soportada hasta el 31 de mayo de 2028. 2.4.9 está soportada hasta el 31 de mayo de 2029. La más nueva tiene un recorrido más largo, así que la respuesta parece evidente.

Normalmente no lo es. El destino correcto depende menos de las versiones en sí que del tipo de proyecto que está ejecutando de verdad, y hay un detalle de calendario este año que cambia la respuesta para muchas tiendas.

Las dos versiones, con honestidad

2.4.8 (abril de 2025, soportada hasta el 31 de mayo de 2028) es una versión de estabilidad. Es madura, va por su quinto nivel de parche, y el ecosistema ha tenido más de un año para pulir los casos límite. Actualizar de 2.4.6 a 2.4.8 es un camino muy transitado: Adobe lo soporta directamente, los proveedores de extensiones confirmaron la compatibilidad hace tiempo, y la mayoría de los problemas con los que se tope ya los ha tenido y documentado otra persona.

2.4.9 (mayo de 2026, soportada hasta el 31 de mayo de 2029) es una modernización de la plataforma. Laminas MVC sustituido por MVC nativo de PHP, Zend_Cache sustituido por Symfony Cache, TinyMCE sustituido por HugeRTE, las dependencias de Symfony pasadas a 7.4 LTS, la biblioteca OAuth abandonada en favor de funciones nativas de PHP. Es el cambio de arquitectura más significativo desde que se lanzó Magento 2. También sube el mínimo de infraestructura: PHP 8.4 u 8.5, MySQL 8.4 o MariaDB 11.4, OpenSearch 3, RabbitMQ 4.1.

Tenga en cuenta que de todos modos no puede saltar directamente ahí. Las tiendas en 2.4.6 o 2.4.7 pasan primero por 2.4.8; solo las tiendas en 2.4.8 actualizan directamente. Así que la pregunta real no es «2.4.8 o 2.4.9», sino «¿paro en 2.4.8 o sigo adelante?»

Ese replanteamiento importa, porque significa que elegir 2.4.8 no cierra ninguna puerta. Es decidir dónde hacer una pausa.

El detalle de calendario que se le escapa a casi todo el mundo

2.4.9-p1 se espera en torno a noviembre de 2026.

Es más tarde de lo que el ecosistema supuso al principio: las primeras especulaciones lo situaban entre 30 y 45 días después de la GA de mayo. La cadencia revisada significa que 2.4.9 se queda en su versión GA inicial, más los parches de seguridad aislados que salgan entretanto, durante la mayor parte de este año.

El primer parche después de una versión mayor es cuando pasan dos cosas: se corrigen los casos límite de la adopción temprana, y los proveedores de extensiones terminan de ponerse al día. Actualizar antes de que llegue significa que ese descubrimiento lo absorbe usted.

Esta es la razón por la que esto es útil y no desalentador. Un proyecto de 2.4.6 a 2.4.9 en una tienda de complejidad media dura de forma realista entre seis y diez semanas. Si empieza ahora la auditoría y el trabajo de infraestructura, llega al deploy en producción más o menos cuando sale 2.4.9-p1. El calendario encaja. No está eligiendo entre «actualizar ahora» y «esperar al ecosistema»: puede hacer la preparación durante la espera.

El marco de decisión

Cuatro preguntas. Las dos primeras hacen la mayor parte del trabajo.

1. ¿Está haciendo un rediseño o un cambio de plataforma de todos modos?

Si sí, vaya a 2.4.9. Es el caso más claro en cualquiera de las dos direcciones. Si está reconstruyendo el tema, pasando a Hyvä o reformando la tienda de forma sustancial, ya está absorbiendo la disrupción, volviendo a probarlo todo y tocando el stack de extensiones. Hacer el trabajo de framework de 2.4.9 al mismo tiempo cuesta un esfuerzo marginal. Hacerlo por separado dentro de dieciocho meses significa pagar dos veces el coste de las pruebas de regresión.

El ecosistema de Hyvä se ha movido para soportar 2.4.9, así que esa combinación es viable; compruebe el tracker de módulos de compatibilidad para su versión concreta en lugar de darlo por hecho.

Si no, 2.4.8 probablemente es lo correcto. Una tienda estable que funciona bien no gana mucho con el framework nuevo. Los cambios de 2.4.9 son reducción de deuda, no funciones que sus clientes vayan a notar.

2. ¿Cuánto código a medida y cuántas extensiones?

Aquí es donde los proyectos de 2.4.9 se pasan de plazo.

Los cambios de framework rompen una categoría concreta de código: cualquier cosa que importe espacios de nombres Laminas\Mvc\ falla en tiempo de compilación, cualquier cosa que referencie Zend_Cache necesita revisión, y cualquier cosa que use las APIs profundas de plugins de TinyMCE necesita pruebas.

Una tienda con un tema ligeramente personalizado y diez extensiones de proveedores importantes encontrará la mayor parte de esto ya resuelto. Una tienda con 25 extensiones, varias abandonadas, y años de módulos a medida acumulados tiene delante un esfuerzo de refactorización considerable, más el riesgo de que una extensión abandonada no tenga versión compatible con 2.4.9 y nunca la tenga.

La auditoría que responde a esto lleva unos días, y conviene ejecutarla antes de comprometerse con una versión de destino, no después.

3. ¿Cómo está su infraestructura hoy?

Si está en PHP 8.2 con MySQL 8.0 y Elasticsearch, la distancia hasta 2.4.9 son seis o más actualizaciones coordinadas de componentes del servidor antes de que empiece el trabajo de Magento. Eso es un proyecto con su propio calendario, sobre todo si se aloja usted mismo.

Un detalle de planificación que conviene incorporar en cualquier caso: 2.4.8 soporta PHP 8.3 y 8.4, y 2.4.9 apunta a 8.4 y 8.5, con 8.3 aceptado solo como camino de actualización, no para uso a largo plazo. Aterrice en PHP 8.4 para el paso a 2.4.8 y habrá satisfecho ambas, haciendo la migración de PHP una vez en lugar de dos. Esa sola decisión hace que un paso posterior a 2.4.9 sea considerablemente más barato, así que tómela ahora aunque vaya a parar en 2.4.8.

4. ¿Cómo de expuesto está ahora mismo?

Si ya ha pasado el fin de soporte, cada semana sin parches está acumulando riesgo. Los boletines recientes de Adobe han resuelto vulnerabilidades críticas que, en palabras del propio Adobe, podían llevar a la ejecución de código arbitrario: exactamente el tipo de cosa que se escanea a escala de internet, y exactamente aquello para lo que deja de recibir correcciones en cuanto su línea sale de soporte.

Cuando está activamente expuesto, la rapidez en llegar a una versión soportada gana a aterrizar en la más nueva. De 2.4.6 a 2.4.8 suelen ser de dos a seis semanas. De 2.4.6 a 2.4.9, de seis a diez. Si hoy está sin parchear, esa diferencia son cuatro semanas más de exposición por un beneficio que podría cobrar más adelante cuando le convenga.

Llegue a soporte. Después decida sobre 2.4.9 con una tienda que funciona y sin presión de fechas.

Dónde deja eso las cosas

Apunte a 2.4.8 si: su tienda es estable y no planea cambios importantes; tiene código a medida importante o extensiones sin soporte confirmado para 2.4.9; su infraestructura está muy lejos de los requisitos de 2.4.9; o está sin parchear ahora mismo y quiere el camino más corto de vuelta al soporte. Vuelva a mirar 2.4.9 en 2027.

Apunte a 2.4.9 si: está haciendo un rediseño o un cambio de plataforma de todos modos; su stack de extensiones es moderno y los proveedores han confirmado la compatibilidad; ya está en PHP 8.4 o cerca; o su código a medida es lo bastante ligero como para que los cambios de framework sean un trabajo pequeño.

En cualquier caso: ejecute primero la auditoría, haga el paso a PHP 8.4 una sola vez, y trate el deploy de 2.4.8 como un punto de control en el que puede parar y no como una etapa por la que pasa.

La opción que nadie mete en la comparación

Hay una tercera respuesta que es la correcta para algunas tiendas, y dejarla fuera de estos artículos es hacer un flaco favor.

Si su instalación de Magento es tan antigua que la actualización es en la práctica una reconstrucción —un tema sin mantener, extensiones abandonadas, módulos a medida que nadie recuerda haber escrito—, entonces la pregunta de la versión está por debajo de una más grande. Estará aquí otra vez en 2029 con la misma conversación, salvo que algo cambie estructuralmente.

No es un argumento para dejar Magento. Magento sigue encajando muy bien con catálogos grandes, precios B2B complejos, integración profunda con ERP y negocios que necesitan control real sobre la lógica de comercio. Pero «actualizar a 2.4.8 y arrastrar la deuda» y «reconstruir como es debido sobre 2.4.9» son propuestas realmente distintas con costes a cinco años distintos, y la segunda a veces es más barata. Conviene poner precio a las dos antes de dar nada por hecho.

Si quiere esa comparación hecha como es debido para su tienda —compatibilidad extensión por extensión, la distancia de infraestructura y un número real para cada opción—, eso es lo que produce una auditoría de actualización, y lleva días, no semanas.

Una vez elegido el destino, la mecánica práctica de llegar hasta él cubre la secuencia, los comandos de auditoría y el plan de rollback.

Emyrix hace auditorías de actualización y migraciones de Magento y Adobe Commerce, incluida la versión honesta de la conversación sobre «si merece la pena». Si está en una versión sin soporte y sopesando las opciones, escríbanos.

Las fechas de soporte y los requisitos de sistema proceden de la política de ciclo de vida del software y de la documentación de requisitos de sistema de Adobe, que son las fuentes autorizadas para su versión y tipo de licencia concretos.