From October 30, Adobe Commerce on Cloud stores on outdated services face suspension

On October 30, 2026, Adobe starts enforcing a new security policy on Adobe Commerce on Cloud. An environment that still runs Elasticsearch, MariaDB 10.5 or older, or RabbitMQ 3.9 or older after that date “may have Admin access suspended, while the storefront remains online, and/or have inbound traffic suspended, taking the storefront offline.” More deadlines follow in May 2027, and after that the older Magento versions themselves have to be upgraded.

The policy applies to Adobe Commerce on Cloud (PaaS) on versions 2.4.4 through 2.4.9. It does not apply to Adobe’s SaaS product or to stores you host yourself. If that is you, the short section near the end is the relevant part. Dates and quotations below were checked against Adobe’s own pages on October 20, 2026.

Due dates

These are the services Adobe requires you to move off:

This applies to every Magento version, including 2.4.8 and 2.4.9, and to every environment, not only production.

The Magento version has its own deadline. Stores on 2.4.4 or 2.4.5 must upgrade to 2.4.9, or migrate to Adobe’s SaaS, by June 1, 2027. Stores on 2.4.6 or 2.4.7 have until June 1, 2028. Adobe has set no deadline for 2.4.8 and 2.4.9. Cloud stores older than 2.4.4 are not listed in the policy, but Adobe’s lifecycle policy applies the same suspension to any unsupported version from June 1, 2027.

If you are on 2.4.4 or 2.4.5, confirm your dates with Adobe. The policy page gives these two versions October 30, 2026 for all service upgrades in one table and the dates above in another. Ask in your support ticket and get the answer in writing.

What happens if you miss it

Adobe may suspend Admin access for all users while the storefront stays online, suspend traffic so the storefront goes offline, or both. If the environment is still not compliant after a traffic suspension, “Adobe may terminate the cloud services”, and decommissioning permanently deletes all data, environments and branches. Adobe states no notice period before either step.

If you cannot make a deadline, the policy says to “contact your account team or Adobe Support as soon as possible” for “a short extension”. It does not say how long an extension can be.

Check what you run

You need two things: the Magento version and the version of every service in every environment.

The Magento version is in the bottom-right corner of any Admin page, or comes from bin/magento --version. For the services, Adobe’s policy points to the Cloud Console: open the environment and check each service on its “Containers” tab, which shows the version currently running.

On Pro, check the running service rather than the repository. Adobe’s knowledge base describes Staging and Production environments where changes to services.yaml “are ignored” and the old versions keep running. The file shows what was requested. The running service shows what you have. Also note that New Relic keeps calling the cache “Redis” even after a move to Valkey, so do not read the service from monitoring labels.

The upgrade procedure

On Pro, Adobe upgrades Staging and Production services for you, through a support ticket. The policy asks for that ticket “at least 30 days before your enforcement date”. For October 30 that point passed on September 30, so if you have not filed yet, file now and ask about an extension in the same ticket. Production changes also need at least two business days’ notice, not counting weekends, and more lead time during busy periods.

On Starter, Adobe’s services page describes the change as self-service: merging an updated .magento/services.yaml to the production branch upgrades production. Services cannot be downgraded afterwards, so take a backup first. The policy itself tells all Cloud customers to open a ticket, so confirm with Adobe who makes the change on your project.

Either way, some of the work stays with you:

• test the upgrade on a non-production environment first, at least checkout, search, cart and your integrations,
• redeploy after Adobe finishes, which also rebuilds the RabbitMQ queues,
• run a full reindex after an OpenSearch change,
• have someone from your team or partner online for the whole Production window, because Adobe does not test your application.

Adobe’s services page suggests validating service upgrades one at a time and warns that “Database upgrades carry the highest operational impact and deserve the most caution.” On Pro, rehearse on Staging with production-sized data. The time it takes there is your best estimate for the Production window.

A service upgrade as a Magento upgrade

Each Magento patch supports specific service versions, listed in Adobe’s system requirements, and Adobe supports only the combinations listed there. The version you are asked to reach may therefore not run on the Magento version you have. These cases follow from that table:

• 2.4.4 and 2.4.5 cannot run PHP 8.2. Every patch of both versions supports PHP 8.1 only. Meeting the May 31, 2027 PHP deadline means upgrading Magento by then, a day earlier than the June 1 version deadline.
• 2.4.6 cannot go beyond PHP 8.2, and PHP 8.2 stops receiving security fixes on December 31, 2026, per php.net. Adobe’s own lifecycle policy marks this as a PCI risk from the end of 2026. The only way off it is a Magento upgrade.
• Older patches need a patch upgrade for the October deadline. For example, OpenSearch 2 needs at least 2.4.4-p13 or 2.4.5-p12, and RabbitMQ 3.13 needs 2.4.4-p18. On an older patch, the patch upgrade comes first.
• OpenSearch 3 on 2.4.6 and 2.4.7 needs the latest patch (2.4.6-p15 or 2.4.7-p10). Those patches also require Valkey instead of Redis, RabbitMQ 4.3 and MariaDB 10.11 or newer, so reaching OpenSearch 3 can pull those changes forward too. Earlier 2.4.6 and 2.4.7 patches support OpenSearch 2. Whether that is enough for October 30 is a question for your ticket.
• The jump from an old version to 2.4.9 takes several steps. No single patch supports both the old and the new versions of every service, and RabbitMQ has to be upgraded one version at a time. Ask Adobe how many Production windows to plan for.

Two changes that are bigger than they look

Adobe itself warns that “Elasticsearch to OpenSearch and Redis to Valkey are migrations to different software rather than version upgrades.”

Elasticsearch to OpenSearch. On Cloud, the search engine is set in .magento.env.yaml (SEARCH_CONFIGURATION) and in the service relationships in .magento.app.yaml. Both need to point at the new service. Search extensions need checking too. Smile’s ElasticSuite, for example, supports OpenSearch 3 only from Magento 2.4.8, so a 2.4.6 or 2.4.7 store using it should settle the OpenSearch version with Adobe before October 30.

Redis to Valkey. Adobe’s Valkey page says to treat the switch as a fresh cache: sessions may not survive, and “users are logged out after the migration completes.” Remove the old Redis definition, because if both are available, Magento keeps using Redis. The latest patches of 2.4.5 to 2.4.7, and all of 2.4.8 and 2.4.9, no longer support Redis at all, so a store that keeps its patches current makes this move before the May 2027 deadline.

Steps per version

• Every Cloud store, now: check the running version of every service in every environment. If anything in the October rows applies, or you are on 2.4.4 or 2.4.5, open a support ticket now. Ask which dates apply to you, how many Production windows the work needs, and for an extension if October 30 is out of reach.
• 2.4.4 and 2.4.5: upgrade to 2.4.9, or migrate to Adobe’s SaaS, and finish by May 31, 2027. File the service tickets well before May 1, which is the last possible date, not a starting point.
• 2.4.6: start the upgrade to 2.4.9 now, because PHP 8.2 loses security support at the end of 2026.
• 2.4.7: move to PHP 8.3, which receives security fixes until December 31, 2027, and plan the upgrade to 2.4.9 before then. Adobe’s deadline is June 1, 2028.
• 2.4.8 and 2.4.9: check the service table above. There is no version deadline yet. Standard support for 2.4.8 ends on May 31, 2028.
• Older than 2.4.4: upgrade to 2.4.9 before June 1, 2027, and ask Adobe whether the October deadlines apply to you. OpenSearch support starts at 2.4.4-p13, so leaving Elasticsearch already requires a Magento upgrade.

If you host Magento yourself

Nothing in this policy takes a self-hosted store offline. It does not cover on-premises Adobe Commerce, Magento Open Source or Mage-OS. The same software still reaches end of life, though: Elastic’s support for Elasticsearch 7.17 ended on January 15, 2026, per its end-of-life page, and PHP 8.2 follows at the end of 2026. Our hosting post covers which hosts keep up with Adobe’s requirements.

The alternative Adobe offers

Every version deadline comes with a second option: moving to Adobe Commerce as a Cloud Service, which Adobe calls its “recommended long-term destination” for Cloud customers. Adobe’s migration overview makes clear that this is a rebuild: customizations become App Builder applications and storefronts are rebuilt on Edge Delivery Services. The SaaS does not support Luma storefronts. For most stores this is a replatforming project, and our replatform-or-fix post covers how to weigh it against an upgrade.

This is the version and service upgrade work our Magento service covers.