Actualizar Magento 2.4.6 a 2.4.9: la versión realista

Si está en Magento 2.4.6, el soporte termina el 11 de agosto de 2026 y tiene que moverse. La pregunta evidente es si moverse hasta 2.4.9 —la línea más reciente, soportada hasta el 31 de mayo de 2029— o parar en 2.4.8 y volver a mirarlo dentro de un par de años.

Este artículo trata de lo que implica de verdad el salto a 2.4.9. Es un trabajo mayor de lo que sugiere el número de versión, y la mayor parte de la dificultad está en dos sitios que la gente subestima: la infraestructura, que tiene que moverse antes que el código, y la compatibilidad de las extensiones, que es donde se desliza el calendario.

Primero: ¿debería ir a 2.4.9 siquiera?

Conviene responderlo con honestidad antes de planificar nada.

Vaya a 2.4.9 si: ya está en PHP 8.4, sus proveedores de extensiones han publicado versiones compatibles, tiene poco código a medida, o está haciendo una reconstrucción sustancial de todos modos y quiere el recorrido más largo posible.

Pare en 2.4.8 si: tiene presión de tiempo por la fecha de fin de soporte, tiene módulos a medida importantes, o depende de extensiones que no han confirmado soporte para 2.4.9. 2.4.8 está soportada hasta el 31 de mayo de 2028, que es un sitio perfectamente razonable en el que quedarse mientras el ecosistema se pone al día.

No hay premio por llegar pronto. 2.4.9 es la versión más significativa a nivel de arquitectura desde que se lanzó Magento 2, y las tiendas que peor lo pasaron con ella fueron las que actualizaron el primer día sin auditar sus extensiones.

El camino son dos pasos, no uno

No se va de 2.4.6 a 2.4.9 con un solo comando de Composer.

Adobe soporta una actualización directa 2.4.6 → 2.4.8. Desde 2.4.8 se pasa a 2.4.9. Las tiendas en 2.4.6 y 2.4.7 necesitan ese paso intermedio; solo las tiendas en 2.4.8 actualizan directamente.

Eso es útil en realidad, porque le da un punto de parada natural. Llegue a 2.4.8, despliéguelo, ejecútelo en producción unas semanas y confirme que la tienda es estable. Después planifique 2.4.9 como un proyecto aparte. Intentar hacer las dos en una sola ventana de release significa que, cuando algo se rompa, no sabrá qué actualización lo causó.

Si ahora mismo tiene el tiempo limitado, haga el paso 2.4.6 → 2.4.8 y pare. Vuelve a estar en soporte. Todo lo que sigue puede esperar a un proyecto con su alcance bien definido.

La infraestructura tiene que moverse primero

Esta es la parte que pilla a los equipos desprevenidos. 2.4.9 sube el mínimo de casi todos los componentes del stack, y nada de ello es opcional. De los requisitos de sistema de Adobe:

Tres cosas que señalar.

Trate PHP 8.3 como descartado para 2.4.9. 2.4.8 soporta 8.3 y 8.4. Para 2.4.9, las versiones soportadas por Adobe son 8.4 y 8.5; 8.3 se mantiene solo para que el propio camino de actualización funcione, no como una versión sobre la que instalar o correr a largo plazo. En la práctica eso significa que si planifica el paso intermedio sobre PHP 8.4, ha satisfecho ambas, y hace la migración de PHP una vez en lugar de dos. Conviene meterlo en el plan desde el principio.

OpenSearch 3 cambia el formato de los índices respecto a 2.x. Necesitará una reindexación completa, y en un catálogo grande eso es una operación programada, no algo que se encaja en una ventana de deploy. Adobe mantiene la compatibilidad con 2.x, así que puede desacoplarlo de la actualización de Magento si lo necesita, pero hágalo de forma deliberada y no descubriéndolo esa noche.

Las actualizaciones de RabbitMQ tienen que ser incrementales. Adobe es explícito en que no se salta de 3.8 a 4.1: se pasa por 3.9, 3.10 y así hasta 3.13 primero, y después a 4.1. Si su cola de mensajes está en una versión antigua, esto es su propio miniproyecto con su propio calendario.

Si está en un hosting Magento gestionado, la mayor parte de esto es una conversación con su proveedor. Si se aloja usted mismo, son seis o más actualizaciones coordinadas de componentes del servidor antes de que la actualización de Magento pueda siquiera empezar. Presupuéstelo aparte.

Los tres cambios de framework que rompen cosas

2.4.9 sustituye tres componentes fundamentales. Cada uno rompe una categoría distinta de código.

Laminas MVC → MVC nativo de PHP

El más impactante de los tres. Magento se construyó sobre Zend Framework, que pasó a ser Laminas, y Adobe ha ido eliminando las dependencias de Laminas a lo largo de la línea 2.4.x. En 2.4.9 la propia capa MVC es PHP nativo.

Cualquier cosa que importe de los espacios de nombres Laminas\Mvc\ —controladores, routers, manejadores de peticiones, gestores de eventos— falla en tiempo de compilación. No es un aviso de deprecación; es un fallo duro.

Audítelo directamente:

grep -rn "Laminas\\\\Mvc" app/code/ vendor/ --include="*.php" | \
  awk -F: '{print $1}' | cut -d/ -f1-4 | sort -u

Eso le da la lista de módulos con los que tiene que lidiar. Para cada uno: su propio código se refactoriza, las extensiones de terceros necesitan una actualización del proveedor, y todo lo abandonado necesita sustituirse o un fork.

Zend_Cache → Symfony Cache

Las dependencias de Symfony en general pasaron a Symfony 7.4 LTS. Los backends de caché a medida, los plugins de caché y cualquier cosa que referencie clases Zend_Cache directamente necesita revisión. Las clases a medida que extienden componentes de Symfony pueden necesitar firmas de método actualizadas.

grep -rn "Zend_Cache\|Zend\\\\Cache" app/code/ vendor/ --include="*.php" | \
  awk -F: '{print $1}' | sort -u

TinyMCE → HugeRTE

TinyMCE 5 y 6 llegaron al fin de soporte y TinyMCE 7 introdujo condiciones de licencia incompatibles con el modelo de código abierto de Magento. HugeRTE es el fork de código abierto que lo sustituye.

Las extensiones que añaden botones básicos a la barra de herramientas sobrevivirán en su mayoría. Las que usan las APIs profundas de plugins de TinyMCE o implementaciones de diálogos a medida pueden necesitar reescribirse. Pruebe cada flujo que dependa del WYSIWYG: edición de descripciones de producto, páginas CMS, bloques CMS, plantillas de correo y cualquier personalización del page builder.

También conviene saber que la biblioteca OAuth de terceros se abandonó en favor de las funciones OAuth nativas de PHP, así que las integraciones a medida que la tocan también necesitan revisión.

El problema de PHP 8.2 en su propio código

Separado de los cambios de framework, y fácil de pasar por alto.

Si sus módulos a medida se escribieron para PHP 8.2 con los avisos de deprecación silenciados —que es la mayoría de los códigos—, ese código fallará ruidosamente en 8.4 y 8.5. Los tipos de parámetro nullable implícitos, la creación de propiedades dinámicas y varios comportamientos de funciones de fecha y cadena cambiaron.

Ejecute análisis estático antes de tocar nada:

# PHPCompatibility via PHP_CodeSniffer
vendor/bin/phpcs -p . \
  --standard=PHPCompatibility \
  --runtime-set testVersion 8.4- \
  --extensions=php,phtml \
  --ignore=*/vendor/*,*/generated/*

# Magento's own coding standard also flags deprecated core APIs
vendor/bin/phpcs --standard=Magento2 app/code/

La salida suele ser más larga de lo que la gente espera y las correcciones son en su mayoría mecánicas. Hágalo pronto: es la única parte del proyecto que puede empezar hoy sin ningún trabajo de infraestructura.

Una secuencia que funciona

Más o menos como los llevamos nosotros:

Fase 1 — Auditoría (3-5 días). Inventario completo de extensiones con el estado de compatibilidad con 2.4.9 de cada proveedor por escrito. Búsqueda de dependencias de Laminas, Zend_Cache y TinyMCE. Análisis estático para PHP 8.4. Documentar las versiones actuales de infraestructura contra la tabla de destino. El resultado es un plan con alcance y un número real asociado, no una estimación.

Fase 2 — Infraestructura. PHP a 8.4, base de datos, OpenSearch, cola de mensajes, servidor web. Hágalo primero en staging y demuestre que la tienda 2.4.6 existente corre sobre el stack nuevo antes de añadir la actualización de Magento como segunda variable.

Fase 3 — Actualización a 2.4.8. Actualización con Composer, setup:upgrade, setup:di:compile, deploy del contenido estático. Arreglar lo que se rompa. Prueba de regresión completa de checkout, pagos, envíos, flujos del admin y cada integración. Deploy a producción. Pare aquí y ejecútelo unas semanas.

Fase 4 — Actualización a 2.4.9. Correcciones de compatibilidad de framework salidas de la auditoría de la fase 1. Actualizaciones de extensiones. Reindexación para OpenSearch 3 si no lo ha hecho ya. Regresión completa otra vez.

Las pruebas de compatibilidad de extensiones en staging tardan de forma realista entre 7 y 14 días y no se pueden comprimir. Es el paso que determina su calendario, y es el paso que, bajo presión de tiempo, la gente intenta saltarse.

El plan de rollback no es opcional

Téngalo preparado y probado antes del deploy, no diseñado durante el incidente:

• Un snapshot de la base de datos tomado justo antes, con una restauración que haya practicado y cronometrado de verdad
• Una release de código etiquetada que pueda redesplegar en minutos
• Un conmutador de tráfico —DNS, balanceador o blue/green— que haya probado
• Un checklist de go/no-go por escrito y una persona con nombre que toma la decisión

La pregunta incómoda que conviene responder por adelantado: si el checkout está roto y la causa no es evidente en 30 minutos, ¿hace rollback o sigue adelante? Decídalo cuando nadie esté en pánico.

Después de la actualización: qué revisar

Una vez en vivo, las cosas que más a menudo se rompen en silencio:

• Indexers. Confirme que todos están en Update by Schedule y corriendo. La reindexación de OpenSearch 3 en particular.
• Cron. bin/magento cron:status. Un cron roto después de una actualización es habitual y los síntomas tardan días en aparecer.
• Consumidores de la cola de mensajes. Sobre todo después de un cambio de versión de RabbitMQ.
• Backends de caché. Si pasó a Valkey, verifique que los tres backends (caché por defecto, caché de página, sesiones) están conectados y que los hit rates parecen normales.
• Integraciones de pago y envío. Todas, con una transacción de prueba real.
• Línea base de rendimiento. Los cambios de framework mueven las características de rendimiento en ambas direcciones. Vuelva a tomar la línea base contra sus números previos a la actualización, para que una regresión no se normalice.

Adobe informa de operaciones de caché sensiblemente más rápidas por el paso a Symfony Cache, así que hay una probabilidad razonable de que los números mejoren, pero confírmelo en lugar de darlo por hecho.

Cuánto cuesta esto

Para una tienda de complejidad media —un tema personalizado, entre 15 y 25 extensiones, un puñado de módulos a medida, una integración con un ERP—, un proyecto de 2.4.6 a 2.4.9 dura de forma realista entre seis y diez semanas de principio a fin, y la infraestructura y las pruebas de extensiones consumen la mayor parte. Los comandos de Composer son la parte más pequeña.

Si ese número resulta incómodo, el paso 2.4.6 → 2.4.8 por sí solo suele ser de dos a seis semanas y le devuelve al soporte hasta el 31 de mayo de 2028. Es un plan perfectamente defendible, y para muchas tiendas es el mejor. Elija el destino que elija, lo que evita que esté aquí otra vez dentro de dos años es el soporte y parcheo continuo de Magento entre actualizaciones, no la actualización en sí.

Emyrix ejecuta actualizaciones de versión de Magento y Adobe Commerce: auditoría, infraestructura, compatibilidad de extensiones y el propio deploy, con un plan de rollback que hemos probado de verdad. Si necesita saber qué implica su actualización antes de comprometerse, escríbanos.

Los requisitos de versión están tomados de los requisitos de sistema y las notas de la versión 2.4.9 de Adobe, que son las fuentes autorizadas y conviene consultar directamente; los entornos Cloud difieren ligeramente de los on-premises.