Qué cambia el «fin de soporte» para una tienda en 2.4.6
Según la tabla de ciclo de vida publicada por Adobe, el soporte estándar de la 2.4.6 terminó el 11 de agosto de 2026. Desde esa fecha, una tienda que sigue en 2.4.6 ya no recibe correcciones de calidad ni de seguridad en el marco estándar.
Adobe prevé un año de soporte extendido, hasta el 31 de agosto de 2027. No tiene coste adicional, pero está reservado a los clientes de Adobe Commerce en las versiones 2.4.6 y 2.4.7.
Para una agencia, la pregunta ya no es «¿hay que actualizar?» sino «¿a qué versión, con qué procedimiento y en qué fecha?». Una tienda en línea lleva un catálogo, pagos y pedidos: no se cambia su pila un viernes por la tarde directamente en producción.
Qué implica en concreto estar sin soporte
- Sin más correcciones estándar — las correcciones de calidad y de seguridad de la 2.4.6 ya no se publican en el soporte estándar; solo el soporte extendido, reservado a Adobe Commerce, prolonga el dispositivo.
- Exigencia PCI — la página de Adobe sobre actualizaciones indica que los comerciantes deben estar en el último parche o parche de seguridad para cumplir PCI. Una pila congelada queda fuera de ese marco.
- Una base que envejece alrededor de Magento — Adobe señala que MySQL 8.0 alcanzó el fin de soporte el 30 de abril de 2026 y Elasticsearch 7.17 el 15 de enero de 2026, y recomienda migrar a MariaDB y OpenSearch.
- Extensiones que recalificar — cada extensión de terceros debe comprobarse contra la versión de destino antes de fijar una fecha. Una sola extensión bloqueante basta para desplazar todo el calendario.
- Un respiro, no un destino — el soporte extendido da tiempo, no una meta: la propia 2.4.7 sale del soporte estándar en mayo de 2027.
- Un parque a varias velocidades — si sus clientes tienen tiendas en 2.4.6, 2.4.7 y 2.4.8, necesita una única tabla de seguimiento, no un recuerdo por cliente.
Leer el calendario de Adobe sin equivocarse de alcance
La página de política de ciclo de vida de Adobe define el soporte estándar como un periodo de tres años desde la disponibilidad general. Cubre las correcciones de calidad, las de seguridad y la asistencia.
Cuidado con el alcance: esta tabla está escrita para Adobe Commerce. No menciona Magento Open Source. Si sus clientes están en Open Source, no tome estas fechas como suyas. Compruébelas con Adobe y, mientras tanto, razone con el caso desfavorable, el de una versión que ya no recibe correcciones. Este artículo no da deliberadamente ninguna fecha de fin de soporte para Open Source.
Fechas de soporte leídas en la página de Adobe (Adobe Commerce)
Desplace la tabla
| Versión | Fin del soporte estándar | Fin del soporte extendido |
|---|---|---|
| 2.4.6 | 11 de agosto de 2026 | 31 de agosto de 2027 |
| 2.4.7 | 31 de mayo de 2027 | 31 de mayo de 2028 |
| 2.4.8 | 31 de mayo de 2028 | No indicada en la página |
| 2.4.9 | 31 de mayo de 2029 | No indicada en la página |
Elegir el destino: 2.4.7, 2.4.8 o 2.4.9
La 2.4.9 está disponible desde el 12 de mayo de 2026 y su soporte estándar llega hasta el 31 de mayo de 2029: es el destino que da más recorrido. La 2.4.7 sale del soporte estándar en mayo de 2027; detenerse ahí obliga a repetir la misma operación antes de esa fecha. La 2.4.8 ofrece un escalón intermedio hasta mayo de 2028.
El calendario no decide por sí solo. Pesan más dos criterios. El primero es la lista de extensiones del cliente: una extensión sin versión compatible con la 2.4.9 exige un parche o un escalón más bajo. El segundo es la distancia de la pila de servidor, que crece con cada versión saltada y que se lee en la tabla siguiente.
La pila de servidor de la 2.4.9: lo que cambia antes de Composer
Adobe solo da soporte a las combinaciones de su página de requisitos del sistema. La nota de esa página es explícita: la 2.4.9 se prueba con MariaDB 12.3, así que la base de datos se actualiza antes que Magento.
La tabla compara la 2.4.6-p15 y la 2.4.9 para una instalación local, tal como la página de Adobe la describe para Adobe Commerce. Para Open Source, confirme cada fila en la misma fuente antes de pedir o reconfigurar un servidor.
Requisitos en local leídos en la página de Adobe
Desplace la tabla
| Componente | 2.4.6-p15 | 2.4.9 |
|---|---|---|
| PHP | 8.2 u 8.1 | 8.5 |
| Composer | 2.2.26 o superior | 2.10 |
| OpenSearch | 2.19 o 3 | 3 |
| MariaDB | 10.11 | 12.3 |
| MySQL | No soportado | 8.4 |
| Valkey | 8.1 | 9.0 |
| RabbitMQ | 4.3 | 4.3 |
| nginx | 1.30 | 1.30 |
| Varnish | 8 | 9 |
Un punto salta a la vista en esta tabla: ninguna versión de PHP es común a la 2.4.6 y a la 2.4.9. PHP cambia, pues, a la vez que el código, y la base pasa de MariaDB 10.11 a 12.3. No es una actualización de parche, es una migración de pila. Se ensaya en una máquina aparte, con las mismas versiones que el destino, antes de ejecutarla en producción.
El plan de corte reducido: pila paralela y preproducción primero
Lo más seguro es no tocar la producción en su sitio. Monte una pila de preproducción con las versiones de destino de la tabla, restaure en ella una copia de la base de datos y de los medios, repita la actualización de principio a fin y cronometre cada paso. Si el ensayo cabe en una ventana aceptable para el comerciante, lo repite idéntico en producción.
Si no, prepare una segunda pila de producción, resincronice la base justo antes del cambio y dirija el tráfico hacia ella en el último momento. La interrupción se limita al cambio, que sitúa en horas valle, y la pila original queda intacta como marcha atrás.
Queda la pregunta de toda agencia: ¿quién asume la relación con el cliente y el riesgo? La relación con el comerciante y el procedimiento siguen en sus manos. En infraestructura dispone de servidores de preproducción y producción separados, acceso root para alinear PHP, motor de búsqueda y base de datos, y snapshots antes de cada actualización.
Procedimiento de actualización con Composer, a ensayar primero en preproducción
Fijar el punto de partida
Haga un snapshot del servidor y una exportación de la base antes de cualquier comando. Anote la versión exacta con
bin/magento --versiony la lista de paquetes concomposer show.Alinear la pila
En la pila de destino, instale las versiones de la tabla: PHP, Composer, OpenSearch, MariaDB. Compruébelas con
php -vycomposer --versionantes de seguir.Activar el mantenimiento
Ejecute
bin/magento maintenance:enable. En preproducción es un reflejo que conviene ensayar para medir la duración real de la indisponibilidad.Detener el cron y vaciar las colas
Retire el cron con
bin/magento cron:removey vacíe los consumidores conbin/magento cron:run --group=consumers. Espere a que termine el procesamiento, que se sigue conps aux | grep 'bin/magento queue'.Guardar el archivo de Composer
Copie el archivo con
cp composer.json composer.json.bak. Es su red de seguridad si la resolución de dependencias toma mal camino.Pedir la versión de destino
Use
composer require-commerce, y nocomposer require:composer require-commerce magento/product-community-edition <versión de destino> --no-update. Para Adobe Commerce, el paquete esmagento/product-enterprise-edition. Este comando supone instalado el pluginmagento/composer-root-update-plugin, como piden los requisitos previos de Adobe.Actualizar las dependencias
Ejecute
composer updatey lea la salida hasta el final: un conflicto de extensión se anuncia ahí antes de cualquier daño. Una extensión que limita la versión de Magento se corrige aquí, no en producción.Limpiar y migrar
Borre el contenido de
var/cache/,var/page_cache/ygenerated/code/, y ejecutebin/magento setup:upgrade. Según su modo de despliegue, repita despuésbin/magento setup:di:compileybin/magento setup:static-content:deploy; la página de Adobe consultada no detalla estos dos comandos, siga su procedimiento habitual.Reabrir y verificar
Ejecute
bin/magento maintenance:disable, reinstale el cron conbin/magento cron:instally reinicie Varnish si lo usa. Recorra después la tienda: catálogo, búsqueda, carrito, pago de prueba, correos de pedido.
Prever la marcha atrás antes de lanzar la actualización
Un snapshot restaura el estado del servidor completo, una copia de seguridad de la base solo restaura los datos: la diferencia se explica en snapshot vs copia de seguridad de VPS. Pruebe la restauración en preproducción antes de la fecha de actualización.
Una marcha atrás solo es limpia mientras no se haya hecho ningún pedido en la nueva pila. Después, hay que reproducir esos pedidos a mano: fije de antemano el momento a partir del cual ya no se vuelve atrás.
Solución de problemas: los errores que vuelven durante una actualización
Estos mensajes proceden de la documentación de Adobe y de Composer. Cada uno tiene remedio, y ninguno debe resolverse en producción.
Mensajes de error y remedios
Your requirements could not be resolved to an installable set of packages— Composer rechaza la combinación pedida. O bien el PHP de la máquina está fuera de las versiones soportadas por el destino, o bien una extensión de terceros limita Magento. Ejecutecomposer why-not magento/product-community-edition <versión de destino>para ver quién bloquea.- Aviso sobre valores raíz en conflicto — sin opción, Composer conserva sus valores personalizados y muestra un aviso.
--interactive-root-conflictspermite revisarlos uno a uno;--force-root-updatessobrescribe sus valores con los de Adobe, solo para proyectos sin personalización. We're sorry, an error has occurred while generating this email— Adobe indica restablecer propietario y permisos de los archivos como root y vaciarvar/cache/,var/page_cache/ygenerated/code/antes de recargar la tienda.- Falta el paquete
magento/inventory-composer-installer— para una actualización desde la 2.3 hacia la 2.4.6-p13, Adobe pide ejecutar antescomposer require magento/inventory-composer-installer, paquete ausente en esa versión.
Industrializar la actualización en todo el parque
Una actualización lograda en una tienda vale poco si no se convierte en rutina. Lleve una tabla por cliente con la versión y el parche de Magento, PHP, la base de datos, el motor de búsqueda, la lista de extensiones y la fecha del último ensayo en preproducción. Adobe recomienda actualizar en cada ciclo de parches: ese ritmo evita caer, dentro de dos años, en la misma urgencia.
Los demás vencimientos del parque están en el calendario de fin de vida 2027, y la lista de comprobación del lado PHP en PHP 8.2 fin de vida: planificar la migración. Alinee los tres en un solo calendario de mantenimiento.
Haga el inventario de las tiendas que siguen en 2.4.6, con su edición (Adobe Commerce u Open Source) y sus extensiones. Elija el destino, la 2.4.9 en la mayoría de los casos. Monte la pila de preproducción con las versiones de la tabla, ensaye el procedimiento y anote la duración de cada paso. Comunique después al comerciante una fecha de cambio, una ventana y un punto sin retorno. El resto ya no es improvisación, es una operación planificada.
