Adobe Commerce on Cloud: las fechas para no quedarte offline

Adobe ha puesto por escrito que suspenderá el tráfico de las tiendas en Adobe Commerce on Cloud que sigan en versiones sin soporte. La primera fecha no es junio de 2027: es el 30 de octubre de 2026, y afecta también a quien ya está en 2.4.8 o 2.4.9.

Profile picture for user admin
By Way2 Ecommerce
· Actualizado:

Adobe ha escrito en su documentación oficial algo que no es habitual leer en la página de una plataforma de ecommerce. En la política de ciclo de vida de Adobe Commerce dice que, a partir del 1 de junio de 2027, dejará de mantener los entornos de Adobe Commerce on Cloud que funcionen con versiones sin soporte, que eso incluye suspender el tráfico de la infraestructura afectada y que, en sus propias palabras, "tu tienda online quedará offline".

La frase está circulando estos días, casi siempre con la fecha de junio de 2027 como única referencia. Hay una fecha anterior que se comenta mucho menos. En la página donde Adobe detalla las acciones obligatorias y los plazos, actualizada el 14 de octubre de 2026, el primer límite es el 30 de octubre de 2026. Afecta a las dependencias del servidor (base de datos, buscador, cola de mensajes) y se aplica a todas las versiones de Adobe Commerce on Cloud, incluidas la 2.4.8 y la 2.4.9.

Esto es lo que vas a encontrar:

  1. A quién afecta y a quién no
  2. Cómo funciona Adobe Commerce on Cloud: quién actualiza qué
  3. Las fechas, versión por versión
  4. Las dependencias: el plazo más cercano
  5. Qué pasa si no llegas a tiempo
  6. Actualizar a 2.4.9 o migrar a Adobe Commerce as a Cloud Service
  7. Si tu tienda es Magento Open Source o está en tu propio servidor
  8. Cuánto margen tienes
  9. Qué hacer esta semana
  10. Preguntas frecuentes

Antes de entrar en fechas, una opinión: creemos que Adobe hace bien. En septiembre publicó un parche urgente para una vulnerabilidad con la puntuación máxima, 10 sobre 10, que permite ejecutar código en la tienda sin autenticarse y que Adobe confirma que se está explotando contra tiendas Adobe Commerce (boletín APSB26-146). Una plataforma gestionada no puede seguir alojando indefinidamente tiendas que dejaron de parchearse hace años, porque comparten infraestructura y reputación con las demás. Si no tienes claro si tu tienda está expuesta a algo así, en otro artículo repasamos las señales de que tu Magento necesita una auditoría técnica.

A quién afecta y a quién no

La medida se aplica solo a Adobe Commerce on Cloud, el producto en el que Adobe aloja tu tienda sobre su propia infraestructura (el antiguo "Magento Commerce Cloud"). Adobe lo deja escrito: la guía no se aplica a Adobe Commerce as a Cloud Service ni a las instalaciones on-premises.

  • Te afecta si tu tienda funciona en Adobe Commerce on Cloud con cualquier versión de la 2.4.4 a la 2.4.9. Lo más rápido para saberlo: si tienes acceso a la Cloud Console de Adobe y tus entornos aparecen allí como proyectos, estás en Cloud.
  • No te afecta directamente si tienes Adobe Commerce con licencia instalado en tu propio servidor o en un hosting que no es de Adobe, ni si usas Magento Open Source. Nadie va a apagarte la tienda, aunque eso no significa que estés a salvo (lo vemos más abajo).
  • Tampoco afecta a Adobe Commerce as a Cloud Service, el producto SaaS lanzado en 2025, que no tiene versiones que gestionar porque Adobe lo actualiza de forma continua.

Cómo funciona Adobe Commerce on Cloud: quién actualiza qué

Es fácil pensar que, si pagas a Adobe por alojar la tienda, Adobe se encarga también de tenerla al día. No es así. Adobe Commerce on Cloud funciona con lo que Adobe llama un modelo de responsabilidad compartida, y el reparto es este:

  • Adobe pone la infraestructura: servidores, sistema operativo, cortafuegos, CDN, escalado y disponibilidad según el contrato. También ejecuta las actualizaciones de servicios como la base de datos o el buscador en staging y producción, cuando se le pide por ticket.
  • Mantener la tienda al día es cosa tuya o de tu agencia: la versión de Adobe Commerce, los parches de seguridad, los módulos de terceros, el código a medida y la versión de PHP. Según Adobe, el comerciante debe aplicar los parches "inmediatamente después de su publicación" y mantener todos los servicios y dependencias en versiones con soporte.

Por eso hay tiendas en Cloud que llevan años en la 2.4.4 o la 2.4.5: la infraestructura está al día, pero la aplicación no la ha actualizado nadie. Y es justo lo que Adobe quiere cortar, porque su propio Security and Compliance Notice recuerda que el modelo compartido exige estar siempre en una versión con soporte. En Adobe Commerce as a Cloud Service este reparto no existe, porque ahí las actualizaciones las hace Adobe.

Las fechas, versión por versión

Adobe ha añadido una columna nueva a su tabla de ciclo de vida, "fechas límite de seguridad (solo Cloud)". Junto con la página de acciones obligatorias (el Security and Compliance Notice), el calendario queda así:

Tu versión en CloudSituación de soporte hoyDependenciasVersión de Adobe Commerce
2.4.4 o 2.4.5Solo parches de seguridad aislados hasta el 31 de mayo de 202730 octubre 20261 junio 2027
2.4.6Soporte extendido hasta finales de agosto de 202730 octubre 2026 o 31 mayo 2027, según el software1 junio 2028
2.4.7Soporte estándar hasta el 31 de mayo de 202730 octubre 2026 o 31 mayo 2027, según el software1 junio 2028
2.4.8 o 2.4.9Soporte estándar30 octubre 2026 o 31 mayo 2027, según el softwareSin fecha por ahora

Conviene corregir una idea que se repite estos días: que cualquier tienda en 2.4.6 o anterior tiene hasta junio de 2027. Según la tabla de Adobe, el límite de versión para la 2.4.6 es el 1 de junio de 2028, igual que para la 2.4.7. Quien sí tiene hasta junio de 2027 es la 2.4.4 y la 2.4.5. Ese año extra de la 2.4.6 tampoco da para mucha calma, porque las dependencias van por su cuenta y porque la propia Adobe marca el cumplimiento PCI de la 2.4.6 con PHP 8.2 como "en riesgo" desde finales de 2026, cuando ese PHP deja de tener soporte (con PHP 8.1 ya lo está desde enero de 2026).

Un detalle para quien vaya a planificar: cuando una tienda tiene que subir de versión, Adobe no pide llegar a "una versión soportada" cualquiera. Para las tiendas de la 2.4.4 a la 2.4.7, el destino que indica es la 2.4.9 (o la última disponible), o migrar a Adobe Commerce as a Cloud Service.

Las dependencias: el plazo más cercano

Este es el apartado que menos se está contando y el que tiene la fecha más cercana. Adobe exige versiones con soporte de PHP, MariaDB, Elasticsearch/OpenSearch, Redis y RabbitMQ, y lo exige también a quien ya está en 2.4.8 o 2.4.9:

SoftwareSi tienesDebes pasar aFecha límite
MariaDB10.5 o anterior10.6 o superior30 octubre 2026
ElasticsearchCualquier versiónOpenSearch (2.19 en 2.4.4 y 2.4.5; 3 desde la 2.4.6)30 octubre 2026
RabbitMQ3.9 o anterior3.13 o superior30 octubre 2026
PHP8.1 o anterior8.2 o superior31 mayo 2027
MariaDBEntre 10.6 y 10.1010.11 o superior31 mayo 2027
OpenSearch1.x2.19 o 3, según tu versión31 mayo 2027
Redis5 o anteriorValkey 8 o superior31 mayo 2027
RabbitMQEntre 3.10 y 3.124.3 o superior31 mayo 2027

En Adobe Commerce on Cloud estas actualizaciones no las haces tú: abres un ticket y las ejecuta Adobe, que pide hacerlo al menos 30 días antes de la fecha límite. Para el 30 de octubre, ese margen terminó el 30 de septiembre. Si alguno de tus entornos está en esa primera fila, lo que toca es escribir hoy a soporte o a tu equipo de cuenta en Adobe. Adobe invita a pedir una prórroga corta si te preocupa no llegar, aunque no promete concederla.

No todos los cambios pesan lo mismo. Pasar de una versión de MariaDB a otra suele ser de bajo riesgo, y Adobe lo dice así. Pasar de Elasticsearch a OpenSearch o de Redis a Valkey es cambiar de software, y PHP 8.1 a 8.2 puede hacer aflorar avisos de código obsoleto en módulos propios y de terceros. En nuestra opinión, son esos tres cambios los que hay que probar en un entorno de staging con calma, revisando como mínimo búsqueda, carrito, checkout e integraciones, porque son los que pueden romper algo que hoy funciona.

Qué pasa si no llegas a tiempo

Según el Security and Compliance Notice de Adobe, a los entornos que no cumplan los plazos Adobe puede aplicarles una de estas dos medidas, o las dos:

  • Suspensión del acceso al panel de administración para todos los usuarios del entorno, con la tienda todavía online. Puedes vender, pero no gestionar pedidos, catálogo ni precios desde el admin.
  • Suspensión del tráfico a la infraestructura afectada: la tienda queda offline.

Y solo si después de suspender el tráfico el entorno sigue sin cumplir, Adobe puede dar de baja el servicio. En ese caso, según Adobe, todos los datos y recursos del entorno (instancias, entornos y ramas) se eliminan de forma permanente y no se pueden recuperar.

No es una secuencia fija: Adobe no dice que vaya a empezar siempre por el admin, ni cuánto tiempo pasa entre una medida y otra. Aun así, todo parece indicar que Adobe va en serio: ha puesto la medida por escrito en dos páginas de documentación, con fechas concretas y con la consecuencia más grave detallada. Si tu tienda está en Cloud, conviene asegurarse de tener copias de la base de datos y de los ficheros fuera de la infraestructura de Adobe, con independencia de que pienses cumplir los plazos.

Actualizar a 2.4.9 o migrar a Adobe Commerce as a Cloud Service

Adobe ofrece dos caminos y no esconde cuál prefiere:

  • Actualizar a Adobe Commerce on Cloud 2.4.9. Conservas tu arquitectura, tus extensiones y tu código, adaptados a la nueva versión. Adobe proporciona el Upgrade Compatibility Report, que detecta qué módulos y ficheros hay que tocar. El inconveniente es que el problema vuelve: cuando la 2.4.9 llegue a su fin de soporte habrá una nueva fecha límite.
  • Migrar a Adobe Commerce as a Cloud Service. Es la opción que Adobe recomienda como destino a largo plazo para todos sus clientes de Cloud: un SaaS que Adobe actualiza por ti, con herramientas de migración gratuitas. A cambio, las personalizaciones se hacen de otra manera. Los módulos PHP que hoy corren dentro de la aplicación dejan de tener cabida, y en la evaluación de migración cada funcionalidad se asigna a una capacidad nativa, a un servicio de Adobe o a una aplicación externa de App Builder, o se retira si ya no se usa. Luma no está soportado, y la guía de Adobe plantea rehacer la tienda sobre Edge Delivery Services. Por eso el código que tienes hoy no se traslada tal cual, y Adobe reconoce que adaptar las personalizaciones suele ser la parte más costosa de la migración.

Nos inclinamos a pensar que, para la mayoría de tiendas con plazo en junio de 2027, la migración a Adobe Commerce as a Cloud Service no es una salida rápida, porque implica rehacer buena parte de lo construido. Puede tener sentido como decisión estratégica, pero tomada con calma y después de cumplir los plazos. Para llegar a tiempo, la vía razonable suele ser actualizar a 2.4.9 y, una vez la tienda está al día, estudiar el resto.

Si tu tienda es Magento Open Source o está en tu propio servidor

Si tu Magento no está en Adobe Commerce on Cloud, nadie te va a cortar el tráfico el 1 de junio de 2027. El calendario de soporte estándar es el mismo, y cuando tu versión lo pierde dejas de recibir parches igual, solo que nadie te obliga a actuar. En Magento Open Source además el soporte acaba antes, porque el soporte extendido y el periodo de solo seguridad son exclusivos de Adobe Commerce. Eso hace más fácil posponer la actualización y, en nuestra opinión, también más arriesgado.

Un ejemplo concreto. El boletín de seguridad de julio de 2026 (APSB26-73) corregía catorce vulnerabilidades, ocho de ellas críticas. En la lista de versiones corregidas aparecen Adobe Commerce 2.4.4 y 2.4.5, que todavía están en su periodo de solo seguridad, pero Magento Open Source empieza en la 2.4.6. Si tu tienda es Open Source 2.4.4 o 2.4.5, ese parche no existe para ti. A eso se suma que PHP 8.1, el que suelen usar esas versiones, ya no recibe correcciones desde el 31 de diciembre de 2025.

Si estás en ese caso, en nuestro artículo sobre el fin de vida de las versiones de Magento tienes el detalle de lo que implica, y en el de Quality Patches Tool cómo ver qué correcciones oficiales tienes disponibles sin aplicar en tu versión.

Cuánto margen tienes

La pregunta útil es cuánto tarda en tu tienda concreta una actualización, contando hacia atrás desde la fecha que te toca. Lo que más alarga el proyecto suele ser:

  • El salto de versión. De 2.4.4 a 2.4.9 hay cinco versiones de diferencia, con cambios de PHP, de buscador y de librerías por el camino.
  • Las extensiones de terceros. Cada una necesita una versión compatible con la 2.4.9. Si el proveedor ya no la mantiene, hay que sustituirla o reescribirla.
  • El código a medida y, sobre todo, las integraciones con ERP, PIM o logística, que hay que volver a probar de punta a punta.
  • Las funcionalidades B2B de Adobe Commerce, si las usas, que suelen estar muy personalizadas.
  • Las ventanas del negocio. Para muchas tiendas, noviembre y diciembre son meses en los que no se toca producción. Si cuentas desde junio de 2027 y descuentas Black Friday y Navidad, el margen real empieza a contarse en enero.

Por eso nos parece razonable que una tienda en 2.4.4 o 2.4.5 sobre Cloud tenga el proyecto de actualización arrancado antes de que termine este año, aunque la fecha límite sea junio.

Qué hacer esta semana

  1. Comprueba tu versión. Aparece en la esquina inferior derecha de cualquier página del admin. Si está oculta, con bin/magento --version.
  2. Comprueba tus dependencias. En la Cloud Console, abre cada proyecto y entorno y revisa la pestaña "Containers": ahí ves la versión de cada servicio.
  3. Si tienes MariaDB 10.5 o anterior, Elasticsearch o RabbitMQ 3.9 o anterior, abre hoy un ticket con Adobe indicando entornos y servicios, y pregunta por una prórroga si no llegas al 30 de octubre.
  4. Si estás en 2.4.4 o 2.4.5, pide el Upgrade Compatibility Report y empieza a planificar la subida a 2.4.9.
  5. Revisa que aplicaste el parche de septiembre (APSB26-146) y la rotación de claves que Adobe pide junto a él. Al estar explotándose, es lo más urgente de esta lista.

Preguntas frecuentes

¿Adobe va a apagar las tiendas Magento Open Source?

No. La medida solo afecta a Adobe Commerce on Cloud. Las tiendas Magento Open Source y las de Adobe Commerce en servidor propio no dependen de la infraestructura de Adobe, así que Adobe no puede cortarles el tráfico. Sí dejan de recibir parches cuando su versión pierde el soporte.

Estoy en 2.4.6 en Adobe Commerce on Cloud. ¿Tengo hasta junio de 2027?

Para la versión, tienes hasta el 1 de junio de 2028. Pero las dependencias tienen fechas propias (30 de octubre de 2026 y 31 de mayo de 2027), y Adobe considera en riesgo el cumplimiento PCI de la 2.4.6 con PHP 8.2 desde finales de 2026.

Ya estoy en 2.4.8. ¿Tengo que hacer algo?

Por versión, no por ahora. Por dependencias, sí: si alguno de tus entornos usa MariaDB 10.5 o anterior, Elasticsearch o RabbitMQ 3.9 o anterior, la fecha es el 30 de octubre de 2026, y hay más cambios con fecha el 31 de mayo de 2027.

¿Qué pasa con mis datos si Adobe suspende el entorno?

Con la suspensión del tráfico la tienda queda offline. Si después el entorno sigue sin cumplir, Adobe puede dar de baja el servicio, y en ese caso indica que todos los datos del entorno se borran de forma permanente y no se pueden recuperar.

¿Puedo pedir más tiempo?

Puedes pedirlo. Adobe indica que, si te preocupa no llegar, contactes cuanto antes con tu equipo de cuenta o con soporte para pedir una prórroga corta. No dice que vaya a concederla siempre, así que conviene pedirla cuanto antes y no contar con ella para planificar.

¿Te ayudamos a llegar a tiempo?

Si tu tienda está en Adobe Commerce on Cloud y alguna de estas fechas te pilla cerca, podemos revisar contigo versión, dependencias y extensiones y decirte qué camino tiene sentido en tu caso. Lo hacemos dentro de una auditoría técnica Magento o, si prefieres no volver a estar pendiente de estas fechas, con nuestro mantenimiento Magento.

Cuéntanos en qué versión estás