Actualizar Magento 2.3 a 2.4: el salto del que nadie le avisó

La mayoría de las guías de actualización dan por hecho que va una o dos versiones por detrás. Si está en Magento 2.3, no va una o dos versiones por detrás: va por detrás de una versión mayor de PHP, de un motor de búsqueda obligatorio que nunca ha usado y de dos sustituciones de framework distintas, todo lo cual ocurrió mientras usted no actualizaba.

Por eso «estamos en Magento 2, así que es solo un cambio de versión» se convierte en un mal trimestre. Los números de versión son adyacentes. Las plataformas que hay debajo no lo son.

Dónde está 2.3 en realidad

Magento 2.3 llegó al fin de soporte el 8 de septiembre de 2022. Desde entonces no se ha publicado ningún parche de seguridad oficial para la línea. Una tienda que todavía lo ejecuta tiene detrás unos cuatro años de vulnerabilidades publicadas y sin parchear; y publicadas es la palabra clave, porque la divulgación le dice a los atacantes exactamente dónde mirar.

La dimensión de cumplimiento normativo es la misma que aplica a cualquier plataforma sin soporte: PCI DSS exige los parches críticos dentro de una ventana definida, y una versión que no recibe parches hace que eso sea imposible de cumplir, no simplemente difícil.

Así que la pregunta no es si moverse. Es cómo secuenciar un movimiento que cruza más infraestructura de la que cruza nunca una actualización normal.

Qué cambió de verdad entre usted y la versión actual

Cuatro cosas, y cada una es un proyecto y no un interruptor.

1. De PHP 7 a PHP 8. Magento 2.3 corría sobre PHP 7.x. Las versiones 2.4 actuales requieren PHP 8.3 u 8.4, y 2.4.9 pasa a 8.4 u 8.5. Es una versión mayor del lenguaje, no una versión menor: funciones eliminadas, manejo de tipos más estricto y semántica de errores cambiada. Cualquier módulo a medida o extensión escrita sin demasiado cuidado contra PHP 7 necesitará trabajo, y los fallos son con frecuencia silenciosos y no fatales.

2. La búsqueda dejó de ser opcional. Magento 2.4.0 eliminó de raíz el motor de búsqueda de catálogo de MySQL e hizo de Elasticsearch un requisito duro. Si está en 2.3 usando la búsqueda de MySQL, no está configurando una opción nueva: está levantando, ajustando y operando una infraestructura de búsqueda que su tienda nunca ha tenido. Después 2.4.8 sustituyó Elasticsearch por OpenSearch, así que el recorrido completo pasa por tres estados distintos:

3. Zend Framework pasó a ser Laminas. Magento 2.4.0 sustituyó Zend Framework por Laminas. Cualquier código que importe clases Zend_ directamente —que es una gran cantidad de código antiguo de terceros— se rompe. Después 2.4.9 sustituyó Laminas MVC por MVC nativo de PHP, lo que significa que una tienda en 2.3 que llega a 2.4.9 cruza dos migraciones de framework y no una. Lo que cuesta esa segunda lo cubrimos en 2.4.8 frente a 2.4.9.

4. La autenticación de dos factores pasó a ser obligatoria para el acceso al admin en 2.4.0. Es ingeniería menor y un cambio operativo real: cada usuario del admin necesita darse de alta, y cualquier automatización que inicie sesión en el admin necesita replantearse.

Elija el destino antes de elegir el camino

El instinto es ir directamente a la versión más nueva. Para una tienda que viene de 2.3, eso suele ser la decisión equivocada.

2.4.8 es el destino sensato para la mayoría de las tiendas en 2.3. Es una línea madura, sus casos límite los han encontrado otras personas, la compatibilidad de extensiones es amplia, y tiene soporte hasta el 31 de mayo de 2028. Y lo más importante: significa cruzar una migración de framework en lugar de dos.

2.4.9 es el destino correcto si tiene pocas extensiones de terceros, un equipo cómodo siendo adoptante temprano, o está reconstruyendo tanta parte de la tienda que la disrupción extra se absorbe de todos modos. Le da soporte hasta el 31 de mayo de 2029.

Viniendo de cuatro años por detrás, el argumento a favor del año extra de recorrido es más débil que el argumento a favor de aterrizar en código probado. Puede tomar 2.4.9 como un proyecto planificado en 2027, cuando ya sea la línea madura. Saltar hacia delante está bien; llegar a un framework nuevo con un parque de extensiones de hace una década es donde los proyectos se atascan.

El camino por fases

No intente esto como un solo comando de Composer. Cada cambio de infraestructura debería ser verificable por separado, para que cuando algo falle sepa qué lo causó.

Fase 1 — póngase al día dentro de 2.3. Pase primero al último nivel de parche de 2.3. Es trabajo dentro de la misma línea, de bajo riesgo, y le da un punto de partida conocido y bueno en lugar de uno arbitrario.

Fase 2 — haga el inventario. Antes de tocar versiones, produzca la lista que es su verdadero perfil de riesgo:

# What you're really running
bin/magento --version
composer show magento/product-community-edition | grep versions

# Everything third-party, which is where the risk lives
composer show | grep -v "^magento/"

# Find direct Zend imports — these break on 2.4.0
grep -rn "Zend_" app/code/ --include="*.php" | head -50

Ese último comando es la alerta temprana más barata que puede ejecutar. Cada resultado es una decisión.

Fase 3 — PHP primero, en 2.3 donde sea posible. Suba lo más posible en el rango de PHP que soporte su nivel de parche de 2.3 antes de cambiar la versión de Magento. Aislar la migración del lenguaje de la migración de la plataforma significa que las roturas relacionadas con PHP aparecen sobre un código que todavía entiende.

Fase 4 — levante la búsqueda. Aprovisione y ajuste Elasticsearch u OpenSearch como una pieza de infraestructura aparte, con su propia verificación, antes de que se convierta en una dependencia dura a mitad de actualización. Nuestras notas de ajuste de Redis y OpenSearch cubren la configuración que importa bajo carga real: los valores por defecto no son lo que quiere.

Fase 5 — cruce a 2.4. Ahora el cambio de versión de Magento ocurre contra un PHP conocido y una infraestructura de búsqueda conocida, lo que lo reduce a lo que debería haber sido: una actualización de aplicación.

Fase 6 — pruebe la regresión de los caminos que generan ingresos. El checkout primero y con más dureza, cada método de pago y de envío, como invitado y con sesión. Después el catálogo y la navegación por capas, que son las superficies más afectadas por el cambio de motor de búsqueda. La metodología completa está en nuestra guía de actualización de Magento 2.

Cuánto cuesta esto de forma realista

Defínalo como un proyecto, no como una tarea de mantenimiento. En una tienda con un tema personalizado, una veintena de extensiones y cuatro años de desviación, la auditoría y la corrección de extensiones dominan: de forma habitual, más que el propio trabajo de actualización. El aprovisionamiento de infraestructura es una cantidad conocida. Las pruebas de regresión son proporcionales a cuánto de su checkout es a medida.

El número que sorprende a la gente no es la ingeniería. Es que un intervalo de cuatro años significa que varios de sus proveedores de extensiones ya no existen, y cada uno de esos es una decisión de construir o sustituir que nadie puede tomar por usted.

Qué haríamos

Ejecute hoy el grep de Zend_ y la lista de extensiones. Veinte minutos de trabajo le dicen si esto es una actualización contenida o una reconstrucción parcial, y esa es la diferencia entre un plan y una estimación.

Después apunte a 2.4.8, haga los cambios de infraestructura por fases para que cada uno pueda fallar por su cuenta, y trate la auditoría de extensiones como la ruta crítica que es en realidad. Las tiendas que salen de esto limpiamente son las que dejaron de llamarlo actualización lo bastante pronto como para planificarlo bien; y lo que evita que esté aquí otra vez en 2030 es el soporte y parcheo continuo de Magento entre versiones, no el próximo gran salto.

Emyrix actualiza tiendas Magento que se quedaron atrás: auditorías de extensiones, migración de infraestructura por fases y el trabajo de desarrollo en Magento 2 cuando una extensión hay que reconstruirla en lugar de sustituirla. Si está en 2.3 y quiere saber qué implica de verdad su actualización, escríbanos.

Las fechas de soporte de versiones y los requisitos de plataforma proceden de la política de ciclo de vida del software y las notas de versión de Adobe, que son las fuentes autorizadas y conviene consultar directamente para su edición y tipo de licencia.