Actualizar Magento 2.2 a 2.4: el problema es 2.3, no 2.4

Hay una versión de este proyecto que sale mal, y empieza con alguien leyendo las notas de la versión 2.4 y definiendo el trabajo a partir de ellas. Las notas de 2.4 no están equivocadas. Simplemente no son la parte que le va a costar dinero.

Si está en Magento 2.2, la versión que remodela su tienda es 2.3. No es su destino y nadie va a dejarle ahí, pero su base de datos y cada módulo a medida que tiene tienen que pasar por ella. En 2.3.0 llegaron dos cambios que no puede rodear, y ninguno de los dos aparece en una comparación de 2.2 contra 2.4 porque no son visibles desde ninguno de los dos extremos.

Dónde está 2.2 en realidad

El soporte de la línea Magento 2.2 terminó en diciembre de 2019. Desde entonces no se ha publicado ningún parche de seguridad oficial.

Eso son cerca de siete años. Es más tiempo del que lleva Magento 1 sin soporte, lo que sorprende a la gente, porque 2.2 todavía parece moderno de una forma en que Magento 1 no lo parece. El admin resulta familiar. El código parece código de Magento 2. Nada de ejecutarlo se siente como ejecutar software abandonado, y ese es precisamente el problema: la tienda no le da ninguna señal de que algo va mal hasta que va muy mal.

La posició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; una versión que no recibe parches hace que eso sea imposible de cumplir, no simplemente difícil.

Por qué 2.3 no es opcional

La guía de Adobe es actualizar de forma incremental a través de las versiones menores, y en la práctica Composer no resolverá limpiamente un salto de 2.2 a 2.4 de todos modos. Pero la resolución de dependencias es la razón pequeña. La real es que en 2.3.0 llegaron dos cambios estructurales, y los dos modifican cosas que son suyas y no de Adobe.

Esquema declarativo

Antes de 2.3, un módulo que necesitaba una tabla de base de datos escribía InstallSchema.php y UpgradeSchema.php: scripts PHP que se ejecutaban en secuencia y hacían cambios de forma imperativa. Desde 2.3.0, Magento lee un archivo db_schema.xml que describe las tablas que quiere un módulo, y calcula la diferencia por sí mismo.

Dos consecuencias, y la segunda es la que pilla a la gente:

Cada módulo a medida suyo que crea o altera una tabla necesita convertirse. Magento incluye un comando de conversión que genera un db_schema.xml inicial a partir de sus scripts de instalación existentes, y hace un trabajo razonable con tablas sencillas. Es un punto de partida, no una respuesta: cualquier cosa condicional, cualquier cosa que manipulara datos y no estructura, y cualquier cosa ingeniosa necesita una persona.

El camino de vuelta se cierra. Una vez que el esquema declarativo ha aplicado sus cambios, bajar a 2.2 no es una ruta de recuperación realista. Esto cambia su plan de rollback de «revertir el deploy» a «restaurar la base de datos», que es un ejercicio distinto con un presupuesto de tiempo distinto. Averigüe cuánto tarda una restauración completa con datos de tamaño de producción antes de la ventana de mantenimiento, no durante ella.

Multi-Source Inventory

MSI también llegó en 2.3.0, y cambió dónde vive el stock. En lugar de una cantidad por producto, Magento ganó fuentes y stocks en sus propias tablas, con la cantidad vendible calculada a partir de ellas.

Por compatibilidad, las tablas de inventario heredadas se mantienen sincronizadas, y por eso muchas tiendas actualizan y no ven nada roto el primer día. El riesgo no está en el checkout: está en todo lo que lo rodea:

• Integraciones con ERP y WMS que escriben niveles de stock directamente en las tablas heredadas. A menudo siguen pareciendo funcionar mientras los dos modelos se separan.
• Código a medida y extensiones que leen el stock directamente en lugar de a través del registro de stock de Magento.
• Informes y exportaciones construidos contra la estructura antigua de tablas.
• Cualquier cosa que diera por hecho un solo almacén, que es la mayoría de lo escrito antes de 2018.

Busque referencias directas y trate cada resultado como una decisión:

# Custom code reaching into inventory tables or the legacy stock item
grep -rn "cataloginventory_stock_item\|StockRegistryInterface\|getStockItem" \
  app/code/ --include="*.php"

# Install/upgrade schema scripts that need converting to db_schema.xml
find app/code -name "InstallSchema.php" -o -name "UpgradeSchema.php"

Esos dos comandos llevan unos minutos y le dicen más sobre la forma de este proyecto que una semana de reuniones de planificación.

La distancia de PHP

Una tienda en 2.2 corre sobre PHP 7.1, o 7.0 en las primeras versiones de la línea. Las versiones 2.4 actuales requieren PHP 8.3 u 8.4, y 2.4.9 pasa a 8.4 u 8.5.

Es más lejos de lo que parece. Una tienda que viene de 2.3 cruza una versión mayor del lenguaje. Usted cruza una versión mayor y la mayor parte de la línea 7.x por el camino, incluido el comportamiento más estricto de 7.2 y las deprecaciones de 7.4, antes de llegar a los cambios rompedores de 8.0 de los que todo el mundo habla.

La parte útil es que el trabajo de PHP se puede aislar. Suba lo más posible en el rango de PHP que soporte cada versión de Magento antes de cambiar de versión de Magento, para que las roturas del lenguaje aparezcan contra un código que todavía reconoce.

El camino por fases

Seis movimientos, y ninguno debería combinarse para ahorrar tiempo:

Fase 1 — póngase al día dentro de 2.2. Pase al último nivel de parche de 2.2. Trabajo dentro de la misma línea, de bajo riesgo, y le da un punto de partida conocido y bueno.

Fase 2 — haga el inventario. Ejecute los dos comandos de arriba, más la lista de extensiones. Este es su verdadero perfil de riesgo:

bin/magento --version
composer show | grep -v "^magento/"

Fase 3 — convierta su esquema. Haga el trabajo de conversión a db_schema.xml como una pieza aparte, revisada como es debido, antes de que esté en la ruta crítica de una ventana de actualización.

Fase 4 — cruce a 2.3, y párese ahí a propósito. Aterrice en el último nivel de parche de 2.3, y después ejecute la tienda en él el tiempo suficiente para encontrar los problemas de inventario. Esta es la fase que la gente comprime, y es en la que aparece la desviación de MSI. Dele a su integración con el ERP un ciclo completo de stock para demostrar que funciona.

Fase 5 — cruce a 2.4. Desde aquí está en el mismo camino que cualquier tienda en 2.3, y es un camino sustancial por derecho propio: PHP 8, un motor de búsqueda obligatorio que nunca ha usado, la sustitución de Zend por Laminas y la autenticación de dos factores en el admin. Ese tramo lo escribimos aparte en actualizar Magento 2.3 a 2.4, y todo lo que dice aplica a usted.

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 la exactitud del stock en concreto, porque es lo que esta actualización tiene más probabilidades de haber cambiado en silencio. La metodología general está en nuestra guía de actualización de Magento 2.

Elija 2.4.8, salvo que tenga una razón

El instinto desde tan atrás es ir directamente a la versión más nueva y comprar el recorrido más largo. Suele ser la decisión equivocada.

2.4.8 es el destino correcto para la mayoría de las tiendas en 2.2. Sus casos límite los han encontrado otras personas, la compatibilidad de extensiones es amplia, y significa cruzar una migración de framework en lugar de dos. 2.4.9 tiene sentido si tiene pocas extensiones de terceros o está reconstruyendo tanta parte de la tienda que la disrupción extra se absorbe de todos modos. El intercambio entre ambas está explicado en 2.4.8 frente a 2.4.9.

Viniendo de siete años por detrás, aterrizar en código probado gana a aterrizar en código nuevo. Puede tomar 2.4.9 como un proyecto planificado más adelante, cuando ya sea la línea madura.

Cuánto cuesta esto de forma realista

Defínalo como un proyecto y no como una tarea de mantenimiento, y espere que la estimación esté dominada por cosas que no son Magento.

La auditoría de extensiones es la ruta crítica, y siete años es tiempo suficiente para que varios de sus proveedores ya no existan. Cada uno de esos es una decisión de construir o sustituir que nadie fuera de su negocio puede tomar. La conversión del esquema es proporcional a cuántos módulos a medida tiene. El trabajo de inventario es proporcional a cuánto de su operación pasa por un ERP.

La ingeniería es conocible. Lo que no es conocible hasta que se mira es cuánto de su tienda depende de suposiciones que dejaron de ser ciertas en 2018.

Qué haríamos

Ejecute hoy los dos greps. InstallSchema.php y el acceso directo al stock son los dos hallazgos que separan una actualización contenida de una reconstrucción parcial, y veinte minutos le dicen cuál de las dos tiene delante.

Después hágalo por fases para que cada cambio pueda fallar por su cuenta, quédese en 2.3 el tiempo suficiente para fiarse de sus números de stock, y apunte a 2.4.8. Lo que evita que repita esto en 2033 no es el tamaño de este salto: es el soporte y parcheo continuo entre versiones, para que la siguiente sea una release rutinaria y no un proyecto.

Emyrix actualiza tiendas Magento que se quedaron atrás: conversión de esquema, auditorías de extensiones y el trabajo de desarrollo en Magento 2 cuando un módulo hay que reconstruirlo en lugar de sustituirlo. Si está en 2.2 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.