Checklist para actualizar Magento 2.4.x: antes, durante y después

Una actualización segura de Magento 2.4.x tiene tres fases. Antes: comprueba qué línea de versiones sigue teniendo soporte, confirma las versiones de PHP, OpenSearch y base de datos que necesita la versión de destino y revisa cada extensión y cada módulo propio frente a ella. Durante: actualiza en una copia de staging con datos de producción y después haz pruebas de regresión del checkout y de cada integración. Después: despliega en una franja planificada con un rollback probado y vigila errores, pedidos y rendimiento durante los primeros días. Abajo tienes la checklist que seguimos en cada actualización, escrita para dueños de tiendas online y para agencias que nos encargan sus actualizaciones.

Las versiones y fechas de este artículo se han comprobado con la documentación oficial de Adobe en noviembre de 2026. Adobe actualiza estas páginas con frecuencia, así que vuelve a revisarlas cuando planifiques.

Antes de la actualización

1. Saber en qué punto está tu versión

Adobe da a cada línea de versiones 2.4.x tres años de soporte estándar desde su fecha de lanzamiento, con correcciones de calidad y parches de seguridad. Algunas líneas antiguas reciben tiempo adicional. Las versiones de Magento Open Source siguen las mismas líneas 2.4.x y el mismo calendario de parches que Adobe Commerce; Adobe publica las fechas del ciclo de vida para Adobe Commerce.

Qué significa esto en la práctica:

• En 2.4.4 o 2.4.5: solo recibes correcciones de seguridad aisladas, ninguna corrección de calidad, y ese periodo no se va a ampliar. Planifica ya una actualización de versión menor.
• En 2.4.6: el soporte estándar ha terminado. Tienes tiempo, pero no mucho.
• En 2.4.7 o 2.4.8: aplica cada parche de seguridad (las versiones -pN ) y planifica con calma la siguiente actualización de versión menor.
• En Adobe Commerce Cloud: a partir del 1 de junio de 2027, Adobe deja de mantener los entornos Cloud que ejecutan versiones sin soporte.

Comprueba también que estás en el último parche de tu línea. Los parches de seguridad aislados de Adobe solo se pueden aplicar sobre él, así que una tienda con varios parches de retraso no puede recibir una corrección urgente con rapidez.

La línea 2.4.10 está en fase alfa en el momento de escribir esto. No planifiques una actualización en producción sobre una versión alfa o beta.

2. Comprobar los requisitos de la plataforma

Buena parte del riesgo de una actualización está fuera del propio Magento: PHP, el motor de búsqueda, la base de datos y la caché. Requisitos de sistema de Adobe para el último parche de cada línea (self-hosted):

Puntos que pillan desprevenidos a los equipos:

• Saltos de PHP. Pasar de 2.4.6 a 2.4.9 significa pasar de PHP 8.1/8.2 a 8.5. Cada módulo propio y cada extensión tienen que funcionar con la nueva versión de PHP, no solo el core de Magento. El propio PHP 8.2 solo recibe correcciones de seguridad hasta el 31 de diciembre de 2026.
• Motor de búsqueda. Elasticsearch 7.17 llegó al fin de su soporte el 15 de enero de 2026, y 2.4.9 solo admite OpenSearch 3. Si todavía usas Elasticsearch, la migración de la búsqueda forma parte del proyecto. Reserva presupuesto para la reindexación y para revisar cualquier extensión de búsqueda con OpenSearch.
• Base de datos. MySQL 8.0 llegó al fin de su soporte el 30 de abril de 2026. Comprueba qué versiones de MySQL o MariaDB admite tu versión de destino antes de tocar el código.
• Caché. Los parches recientes indican Valkey en lugar de Redis. Tu hosting o tu configuración Cloud tienen que ofrecer la versión que espera la versión de destino.
• Commerce Cloud tiene su propia tabla de requisitos, distinta de la de self-hosted. Si estás en Cloud, usa los valores de Cloud.

3. Crear una matriz de compatibilidad de extensiones

Haz una lista de cada módulo de terceros en composer.json y app/codey rellena una fila por extensión:

• versión instalada y proveedor;
• la versión compatible con tu versión de destino de Magento y de PHP (según el changelog del proveedor, no solo la etiqueta del marketplace);
• estado de la licencia o del soporte, ya que algunas actualizaciones requieren una renovación de pago;
• si el módulo se sigue usando.

Marca cada fila como actualizar, sustituir, parchear nosotros o eliminar. Los módulos abandonados son un motivo frecuente de que las estimaciones de una actualización crezcan. Eliminar los módulos que nadie usa suele ser la solución más barata.

4. Revisar el código propio y las APIs obsoletas

• Modificaciones del core. Busca cambios en vendor/, clases del core sobrescritas y parches de Composer. Cada uno tiene que revisarse de nuevo con la nueva versión.
• Los plugins y preferences sobre clases del core se rompen cuando cambian las firmas de los métodos.
• Cambios incompatibles con versiones anteriores. Adobe publica una lista por versión. Por ejemplo, 2.4.9 pasa a Symfony 7.4 LTS, así que las clases propias que extienden clases del core de Symfony necesitan declaraciones de tipos y firmas de métodos actualizadas. También rechaza los pedidos creados por API sin dirección de facturación, algo importante si un conector de ERP o de marketplace crea pedidos.
• En Adobe Commerce, ejecuta el Upgrade Compatibility Tool de Adobe contra la versión de destino. Informa de problemas críticos, errores y avisos en tus módulos y en el código del core. No está disponible para Magento Open Source; allí, la misma revisión se hace a mano y con análisis estático.

5. Preparar staging y copias de seguridad

• Un entorno de staging igual que producción: las mismas versiones de PHP, motor de búsqueda, base de datos y caché que el destino, no que las actuales.
• Una copia reciente de los datos de producción, anonimizada si el entorno de staging está menos protegido que producción.
• Copias de seguridad que hayas restaurado al menos una vez: volcado de la base de datos, media/, app/etc/env.php y el código desplegado (o el artefacto de la release). Una copia de seguridad que nunca has restaurado es una esperanza, no una copia de seguridad.
• Un code freeze o al menos una estrategia de ramas clara, para que las funcionalidades que se desarrollen durante la actualización no choquen con ella.

Durante la actualización

6. Actualizar en pasos pequeños y revisables

1. Actualiza primero la infraestructura en staging: PHP, motor de búsqueda, base de datos y caché.
2. Actualiza Magento y las extensiones con Composer, un grupo cada vez, y haz commit después de cada paso.
3. Ejecuta setup:upgrade, compila la DI, despliega el contenido estático y corrige cada error y cada aviso de deprecación. No los silencies.
4. Vuelve a aplicar o elimina los parches de Composer; algunos dejan de ser necesarios tras una actualización.
5. Vuelve a generar los assets del frontend y revisa el tema, sobre todo si sobrescribe plantillas del core.

7. Hacer pruebas de regresión de lo que genera ingresos

Los tests automatizados ayudan, pero el mínimo es un plan de pruebas por escrito que cubra los flujos de negocio reales:

• Checkout: invitado y con sesión iniciada, cada método de pago (incluidos 3-D Secure y wallets), cada método de envío, cupones, tarjetas regalo, impuestos y moneda por store view.
• Cuenta de cliente: registro, inicio de sesión, restablecimiento de contraseña, historial de pedidos, volver a pedir.
• Catálogo y búsqueda: páginas de categoría, navegación por capas, resultados de búsqueda y autocompletado tras la reindexación, productos configurables y bundle, precios por grupo de clientes.
• Integraciones: sincronización con el ERP y el inventario, exportación de pedidos, webhooks de pago y envío, feeds de marketplaces, herramientas de email y marketing, eventos de analítica y del gestor de etiquetas. Prueba ambos sentidos, con credenciales reales (de sandbox).
• Administración y operaciones: creación de pedidos y facturación, abonos, importaciones, cron jobs, consumidores de colas y emails transaccionales.
• Funciones B2B en Adobe Commerce: cuentas de empresa, catálogos compartidos, presupuestos, listas de pedido.

Haz también una comprobación rápida de rendimiento: tasa de aciertos de la caché de página completa, tiempo de respuesta del servidor en las páginas clave y Core Web Vitals en las plantillas que hayas cambiado.

8. Planificar la ventana de despliegue y el rollback

• Elige una franja de poco tráfico , lejos de campañas, rebajas y otros picos de temporada.
• Escribe el runbook del despliegue: pasos, quién hace qué, duración prevista y el punto de decisión para el rollback.
• Define los criterios de rollback antes del despliegue (por ejemplo: checkout roto, fallos de pago, errores de integración que no puedes resolver dentro de la ventana).
• Ten a mano la release anterior y una copia de seguridad reciente de la base de datos , y averigua cuánto tarda una restauración. En cuanto entran pedidos nuevos después de actualizar la base de datos, volver atrás la base de datos supone perderlos, así que el margen para el rollback es corto.
• Pon la tienda en modo mantenimiento solo durante los pasos que lo requieran, y comunica el calendario con antelación a los equipos de atención al cliente y de marketing.

Después de la actualización

9. Vigilar de cerca los primeros días

• Errores: logs de PHP y de excepciones, cron jobs fallidos, consumidores de colas atascados.
• Pedidos: compara el volumen de pedidos y la tasa de pagos fallidos con una semana normal. Una caída silenciosa suele ser la primera señal de un problema en el pago o en el checkout.
• Integraciones: confirma que los pedidos llegan al ERP, que el stock vuelve y que los webhooks funcionan.
• Búsqueda e indexación: indexadores válidos, resultados de búsqueda coherentes, sin una cola de reindexación que no para de crecer.
• Rendimiento: tiempos de respuesta, tasa de aciertos de la caché y Core Web Vitals comparados con los de antes de la actualización.

10. Cerrar el ciclo

• Elimina los módulos y parches que hayas sustituido y limpia los artefactos de despliegue antiguos.
• Actualiza la documentación: versiones, matriz de extensiones, runbook.
• Apunta en el calendario el siguiente parche de seguridad. Mantenerte en el último parche de tu línea hace que la siguiente actualización de versión menor sea pequeña.

Parche, versión menor o versión antigua: qué esperar

• Actualización de parche (por ejemplo, de 2.4.8-p4 a 2.4.8-p5): alcance pequeño, sobre todo pruebas. Debería ser rutina.
• Actualización de versión menor (por ejemplo, de 2.4.7 a 2.4.8 o 2.4.9): nuevas versiones de PHP y de servicios, actualización de extensiones y corrección del código propio. Es un proyecto, no una tarea.
• Actualización desde 2.3 o anterior: cuenta con un esfuerzo mayor, ya que hay varias versiones de PHP y muchos componentes obsoletos por medio.

Si también estás pensando en sustituir Luma, lee primero ¿Cuándo merece la pena Hyvä? . Una migración a Hyvä se puede combinar con una actualización de versión menor; en una versión sin soporte, primero va la actualización.

Ayuda con tu actualización

Si quieres que alguien más lo revise antes de empezar, ofrecemos una auditoría exprés gratuita: versiones, nivel de parches, rendimiento y seguridad básica, con un informe breve y una llamada de 20 minutos. Para la actualización en sí, nuestros paquetes de actualización a precio cerrado empiezan en 300 € para una actualización de parche y en 1.000 € para una actualización de versión menor 2.4.x con la actualización de PHP. El precio final se fija tras la auditoría. Para mantener la tienda con los parches al día después, consulta los planes de soporte Magento.

Fuentes (en inglés): Adobe Experience League: Política de ciclo de vida, Requisitos del sistema, Versiones publicadas, Calendario de versiones, Notas de la versión de Magento Open Source 2.4.9, Upgrade Compatibility Tool; Adobe Developer: Cambios incompatibles con versiones anteriores; Versiones de PHP con soporte.