Una tienda Magento puede funcionar durante años sin que nadie toque su número de versión, y ese es justamente el problema. Cada línea de versiones de Magento 2.4 recibe correcciones de seguridad durante un tiempo limitado, y una tienda que se queda en una línea antigua sigue funcionando mientras acumula en silencio vulnerabilidades conocidas. Planificar una actualización de Magento 2.4 antes del plazo, y no después de un incidente, la convierte en trabajo de rutina. Esta guía explica cómo funcionan las líneas de versiones y las fechas de soporte, en qué se distinguen los parches de las actualizaciones y la lista de verificación que seguimos.
Fin del soporte de Magento: cómo funcionan las líneas de versiones
Magento Open Source y Adobe Commerce se publican en líneas: 2.4.6, 2.4.7, 2.4.8 y, desde mayo de 2026, Magento 2.4.9. Dentro de cada línea, las versiones de parche con sufijo -p, como 2.4.8-p3, entregan correcciones de seguridad y críticas sin funciones nuevas. La política de ciclo de vida de Adobe Commerce establece cuánto tiempo se da soporte a cada línea, por lo general unos tres años desde su lanzamiento, y algunas líneas se amplían para los clientes de Adobe Commerce. Los plazos de soporte pueden diferir entre la edición de pago y la de código abierto, así que lea la política de su edición en lugar de fiarse de una fecha citada de segunda mano.
En la práctica, una tienda en 2.4.6 o anterior está en el final de su soporte estándar, o ya lo superó, y debería planificar su cambio ahora; una tienda en 2.4.7 tiene tiempo, pero no mucho de sobra. Cuando llega el fin del soporte de Magento para su línea, la tienda sigue funcionando; simplemente deja de recibir correcciones, y toda vulnerabilidad publicada después de esa fecha queda abierta.
Parches de seguridad de Magento entre actualizaciones
Los parches de seguridad de Magento llegan de dos maneras: como la siguiente versión -p de su línea y, ocasionalmente, como una corrección urgente aislada (hotfix) cuando una falla crítica no puede esperar. SessionReaper (CVE-2025-54236) es el ejemplo que conviene recordar. Adobe publicó la corrección en septiembre de 2025 en el boletín de seguridad APSB25-88, y cuando se hicieron públicos los detalles técnicos, los atacantes comenzaron a explotar a gran escala las tiendas sin parchear. Las tiendas que aplicaron el hotfix de inmediato quedaron en una situación muy distinta a las que esperaron su siguiente actualización planificada.
Para correcciones individuales entre versiones, Adobe ofrece la Quality Patches Tool, que aplica parches seleccionados desde la línea de comandos y lleva un registro de lo aplicado. Suscríbase también a las notificaciones de seguridad de Adobe, para que un boletín crítico llegue a alguien que pueda actuar en cuestión de días.
Una lista de verificación de actualización de Magento
En nuestro trabajo de desarrollo con Magento 2, cada actualización se ensaya en una copia de la tienda antes de tocar la tienda real; la lista siguiente muestra lo que eso implica.
- Registre el estado actual: versión de Magento, PHP, servidor de base de datos, OpenSearch, Redis, Varnish y Composer, y la lista de módulos instalados.
- Revise los requisitos del sistema de la versión de destino. Una línea nueva suele necesitar versiones más recientes de PHP, de la base de datos o del motor de búsqueda, lo que puede implicar actualizar el servidor antes que la aplicación.
- Revise las extensiones de terceros. De cada una: ¿se sigue usando?, ¿tiene mantenimiento?, ¿su proveedor es compatible con la versión de destino? Elimine lo que nadie usa y reemplace lo que está abandonado. Las extensiones de terceros causan más retrasos en las actualizaciones que el propio Magento.
- Revise el código personalizado en busca de ediciones a archivos del núcleo, preferencias de clase que reemplazan clases del núcleo y API obsoletas. Los módulos personalizados que cambian el comportamiento mediante plugins y observadores suelen actualizarse sin problemas.
- Construya un entorno de staging a partir de una copia reciente de producción, con los datos de los clientes anonimizados, que ejecute las mismas versiones de software que usará el servidor real.
- Actualice en staging con Composer, ejecute la actualización de configuración (setup upgrade), compile, despliegue el contenido estático y corrija lo que falle.
- Pruebe los recorridos que generan ingresos: búsqueda, páginas de producto, carrito, proceso de pago con cada método de pago y de envío, cuentas de clientes, gestión de pedidos en el administrador e integraciones.
- Planifique el lanzamiento: una copia de seguridad completa, una ventana de tiempo tranquila, el modo de mantenimiento y un plan de reversión por escrito.
- Vigile los primeros días: registros de errores, volumen de pedidos, fallos de pago y velocidad de las páginas.
Rutas de actualización de Magento 2.4: saltar versiones y mover la infraestructura
Una tienda varias líneas atrasada no necesita detenerse en cada versión intermedia: Composer puede ir directamente a la de destino, y los scripts de actualización de la base de datos se ejecutan en orden. El trabajo que no se puede omitir es el de la infraestructura. PHP, la base de datos y el motor de búsqueda tienen versiones compatibles para cada línea de Magento, y un salto desde una línea antigua puede significar reemplazar gran parte de la pila del servidor. Suele ser el momento de decidir si el hosting actual todavía se ajusta a la tienda.
¿Actualizar o cambiar de plataforma?
Una actualización suele ser la decisión correcta cuando la tienda hace lo que el negocio necesita y el problema es la deuda técnica. Si el negocio ha cambiado a su alrededor, por ejemplo si el catálogo se ha reducido y el equipo quiere tener menos que mantener, o si los requisitos B2B han superado a las extensiones instaladas, compare la actualización con un cambio a otra plataforma. Nuestro servicio de cambio de plataforma de comercio electrónico cubre esa vía.
Preguntas frecuentes: actualización de Magento 2.4
¿Con qué frecuencia se debe actualizar una tienda Magento?
Aplique cada versión de parche de seguridad de su línea poco después de publicada, y las correcciones urgentes críticas en cuestión de días. Planifique el paso a una línea más nueva mucho antes de que termine el soporte de su línea actual; para la mayoría de las tiendas eso significa una actualización mayor cada uno o dos años.
¿Una actualización cambiará el aspecto de mi tienda?
No debería, pero los temas que reemplazan muchas plantillas del núcleo pueden necesitar ajustes. Los temas basados en Luma y los de Hyvä necesitan cada uno su propia revisión de compatibilidad en staging antes de la actualización real.
¿Recibe Magento Open Source el mismo soporte que Adobe Commerce?
Ambos reciben parches de seguridad para las líneas con soporte, pero la edición de pago tiene opciones de soporte adicionales y, en algunas líneas, plazos más largos. Revise la política de ciclo de vida de su edición.
¿Usa una versión antigua de Magento 2.4? Nuestro equipo de desarrollo con Magento 2 y Adobe Commerce se encarga de actualizaciones, parches de seguridad, auditorías de extensiones e integraciones, y este mismo sitio funciona con Magento Open Source 2.4.8, así que la rutina también es la nuestra. Contáctenos con su versión actual y las extensiones de las que depende, y definiremos el alcance de la actualización.
