Adobe Commerce Security Enforcement: Upgrade, Move to SaaS, or Replatform?

Adobe has published a security enforcement policy for Adobe Commerce on Cloud, and it has teeth. Environments that miss its deadlines “will have inbound traffic suspended, taking the storefront offline.” Merchants that stay non-compliant after that face something worse: Adobe “may terminate the cloud services, initiating the decommissioning process”, in which “all data and assets within the hosted commerce environment… will be permanently deleted and cannot be restored.”

The first deadline is 30 October 2026. It covers a specific set of infrastructure upgrades rather than the Commerce version itself, and it is easy to misread. Further deadlines follow in 2027 and 2028 for the Commerce application.

This article explains exactly what Adobe’s policy requires and when, using Adobe’s own Experience League documentation (checked on 9 October 2026 and listed at the end). It then sets out the three strategic options in front of an Adobe Commerce on Cloud merchant: upgrade in place, move to Adobe’s SaaS offering, or replatform. For B2B merchants we look at migrating from Adobe Commerce to Elastic Path. The option analysis is ours, and we are clear about one thing up front: a replatform cannot rescue you from the October date. Only the upgrade can.

Who the Policy Applies To

Adobe’s page is precise about scope: “Applies to: Adobe Commerce on Cloud (PaaS) environments running Adobe Commerce versions 2.4.4 through 2.4.9.” It adds: “This guidance does not apply to Adobe Commerce as a Cloud Service (SaaS) environments or Adobe Commerce on-premises deployments.”

If you run Adobe Commerce yourself, on your own infrastructure or a third-party host, this enforcement policy does not apply to you, although the lifecycle dates below still matter. If you are on Adobe’s managed PaaS, it applies to every environment, not just production: “Requirements apply to all your environments, so plan to upgrade every environment rather than production alone.”

What Is Due on 30 October 2026

Adobe’s dependency table sets 30 October 2026 for three upgrades:

These deadlines apply whichever 2.4.x version you run. Adobe notes that “Elasticsearch to OpenSearch and Redis to Valkey are migrations to different software rather than version upgrades”. Test your search and catalogue behaviour after the change, not just the fact that the service starts.

How the upgrade happens. “Adobe will help you upgrade these software dependencies directly.” The process is to “Open a support ticket listing the environments you need upgraded and the dependencies involved. Open your ticket at least 30 days before your enforcement date so Adobe can schedule the work.” Adobe will confirm the downtime window when scheduling.

By our arithmetic, 30 days before 30 October was the end of September. If you have not opened a ticket, Adobe’s page says: “If you have concerns about meeting the deadline and need a short extension, please contact your account team or Adobe Support as soon as possible.” Do that today. Adobe’s page does not describe a formal exception process or say that customers will be notified before enforcement, so the responsibility for acting sits with you.

What Is Due by 31 May 2027

Adobe’s dependency table gives the remaining upgrades a later date:

A caution for 2.4.4 and 2.4.5. Adobe’s summary table gives those versions a single dependency deadline, “Required by October 30, 2026”, without the May 2027 alternative it gives 2.4.6 and later. Adobe’s system requirements also list PHP 8.1 as the only tested PHP version for 2.4.4 and 2.4.5, so on either version PHP 8.2 is not a supported combination without a Commerce version upgrade. If you are on 2.4.4 or 2.4.5, confirm with Adobe Support which dependency dates apply to you.

One detail on PHP. Adobe’s lifecycle page lists PHP 8.2’s own end of life as 31 December 2026, with a note that PCI compliance is at risk from the end of 2026. Our recommendation is to target the newest PHP version your Commerce release supports, rather than the minimum the enforcement table names. On 2.4.4 and 2.4.5 that newest version is 8.1, below the minimum, so for those versions the PHP requirement is in practice a Commerce upgrade requirement.

What Is Due for the Commerce Version

Separately, Adobe sets deadlines to “Upgrade to latest Adobe Commerce on Cloud version, or migrate to Adobe Commerce as a Cloud Service”:

Adobe’s lifecycle table shows where each release stands:

Adobe describes the security-only period for 2.4.4, 2.4.5 and 2.4.6 as one that “provides limited isolated security fixes only (no quality fixes)”, and warns: “Treat the security-only period as migration time, not as a long-term support tier.”

If you are on 2.4.4 or 2.4.5, the practical position is that you need the dependency upgrades by 30 October 2026 and a version upgrade or SaaS migration by 1 June 2027. That second date is what makes this a strategic decision rather than an operations task.

Option 1: Upgrade in Place

What it is: stay on Adobe Commerce on Cloud, complete the dependency upgrades, and move to 2.4.9 (or the latest release), the target Adobe’s version table names. Adobe also lists 2.4.8 as fully supported, with no version upgrade currently required.

This is our assessment.

• It is the only option that addresses 30 October. The dependency upgrades are needed whatever you decide strategically.
• It resets the clock, but only to the next lifecycle date. Standard support for 2.4.8 ends on 31 May 2028 and for 2.4.9 on 31 May 2029. An upgrade buys a known period, after which the same decision returns.
• Its cost scales with your customisation. Merchants with heavily customised modules and extensions know that a 2.4.x upgrade is rarely just a version bump. If your last upgrade was painful, budget for this one to be similar.

Upgrading in place is the right answer for merchants whose platform fits their business well, whose customisation is manageable, and who want to defer a bigger decision.

Option 2: Move to Adobe Commerce as a Cloud Service

What it is: Adobe’s SaaS offering, which Adobe’s lifecycle page calls its “recommended long-term destination for all Adobe Commerce on Cloud customers.”

From Adobe’s documentation:

• It is “a fully managed, versionless platform that provides a seamless upgrade experience without manual intervention.” Updates are applied automatically after “a 30-day period to evaluate the new capabilities in your sandbox instances”. Adobe “guarantees backward compatibility for all updates” for customisations “that adhere to the API-first extensibility model.”
• Customisations must be rebuilt. “Customizations run as out-of-process Adobe Developer App Builder applications that integrate with Commerce through events and APIs. Modernizing a store’s customizations for this architecture is typically the most significant engineering effort in an Adobe Commerce as a Cloud Service migration.” On the platform, “Merchants cannot modify core application code.”
• The storefront is rebuilt too. Storefronts “are rebuilt on Edge Delivery Services”, and “Adobe Commerce as a Cloud Service does not support Luma storefronts.”
• Data migration covers core data. Adobe offers a migration assessment tool, developer tooling and a data migration service. Adobe states that the migration tools “are available at no cost to you”, but also that “The migration service supports first-party core commerce data only. The migration service does not handle custom, third-party entities.”

Our reading: moving to Adobe Commerce as a Cloud Service is a replatform in all but name. Adobe’s own description is a set of rebuilds: customisations re-implemented as external applications, a new storefront, data migrated, integrations re-established “using SaaS patterns”. That does not make it the wrong choice. For merchants committed to the Adobe ecosystem it may be the right one. But it should be compared with other platforms on equal terms, because the effort is of a similar kind.

Option 3: Replatform to Elastic Path

What it is: move to a composable, API-first commerce platform. For B2B merchants, Elastic Path is the option we know best.

The case is strongest for B2B merchants whose Adobe Commerce customisations exist mainly to model how they sell to businesses: account structures, customer-specific catalogues, contract pricing. Elastic Path’s documentation covers those as platform capabilities:

• Accounts with multiple buyers. “In a B2B scenario, an account will have multiple members from a business unit, all of whom can transact on behalf of their organization.” An account can “optionally have another account as a parent”, and accounts can be grouped with account tags.
• Catalog rules for customer-specific assortment. Catalog rules let you “Offer different products and prices for business customers versus retail customers”, give a group of buyers special pricing while others see a standard catalogue, and schedule catalogues for particular periods. Since November 2025, “Catalog rules can now target accounts based on their tags, enabling flexible tag-based segmentation for B2B scenarios.”
• Account-specific price books. Elastic Path’s price segmentation guide describes creating “a reseller specific price book” and a catalog rule that uses it as the primary pricing with a tier price book as the fallback.
• Native search that follows the segment. Elastic Path launched Catalog Search in February 2026, “built directly into Elastic Path Commerce Cloud and your catalogs, eliminating the need for third-party search vendors”. Since July 2026, “Catalog rules can optionally include a search profile so shopper search follows the same segment as catalog and pricing”.
• Least-privilege administration. “Commerce Manager now supports custom user roles, so admins can define exactly the access each team member needs”.

This is our assessment of the trade-offs.

• It is a genuine replatform. Data migration, integration rebuilds (ERP, PIM, payments, tax), a new front end and SEO preservation all have to be done properly. We set out the method in Replatforming to Elastic Path: Migrating from Salesforce Commerce Cloud and SAP Hybris, and the same approach applies to Adobe Commerce.
• It changes who owns platform upgrades. Our view is that the strongest long-term argument for a SaaS composable platform is that core platform upgrades move from your roadmap to the vendor’s. Confirm the upgrade and deprecation policy of any platform you shortlist, and remember that your own front end and integrations still need maintaining.
• It suits a phased approach. Composable architecture lets you move capability by capability behind an edge routing layer, rather than in a single big-bang cutover.

An Honest Timeline

This is our view of a realistic sequence for a 2.4.4 or 2.4.5 merchant considering a replatform:

1. Now to 30 October 2026: complete the October dependency upgrades with Adobe, or secure an extension through your account team. This is non-negotiable whatever you decide.
2. November to December 2026: run a structured comparison of the three options against your requirements, customisation inventory and total cost of ownership. Our total cost of ownership comparison of composable and monolithic platforms is a starting point.
3. January 2027 onwards: if you replatform, build in phases. Keep the Adobe environment compliant throughout. On 2.4.4 or 2.4.5, that means confirming with Adobe which dependency dates apply to you, because PHP 8.2 is not a supported combination on those versions.
4. Before 1 June 2027: you must be on a supported version, on Adobe’s SaaS offering, or off Adobe Commerce on Cloud. If a replatform will not finish in time, the fallback is a version upgrade. Plan for that possibility from the start, rather than discovering it in April.

A Decision Matrix

Our recommendations, by situation:

How McKenna Consultants Can Help

McKenna Consultants is a UK Elastic Path consultancy delivering composable B2B commerce. We built a new global composable store on Elastic Path for Norgren, and a composable B2B reseller platform on Elastic Path for Astrak.

If Adobe’s policy has forced the platform question, we can run an independent options assessment covering the upgrade, Adobe’s SaaS offering and a move to Elastic Path. We can also plan a phased replatform that keeps your current storefront compliant while the new one is built. Contact us or read more about our B2B eCommerce services.

Sources

All sources checked on 9 October 2026.

• Adobe Experience League — Required actions and deadlines to secure Commerce environments (last updated 18 September 2026): scope; traffic suspension and decommissioning; dependency and version deadline tables; support-ticket process; extensions.
• Adobe Experience League — Adobe Commerce lifecycle policy (last updated 18 September 2026): release support dates; security-only period; PHP end-of-life dates; Adobe Commerce as a Cloud Service as the recommended destination.
• Adobe Experience League — System requirements (last updated 18 September 2026): tested PHP versions for each Adobe Commerce on Cloud release; only listed combinations supported.
• Adobe Experience League — Get started with Adobe Commerce as a Cloud Service: fully managed, versionless platform.
• Adobe Experience League — Adobe Commerce as a Cloud Service overview: 30-day evaluation; backward compatibility; no Luma storefronts.
• Adobe Experience League — Migration overview: App Builder customisations; Edge Delivery Services storefronts; migration tools; first-party data only.
• Elastic Path — Account management introduction and Create an account: B2B accounts with multiple members; parent accounts; account tags.
• Elastic Path — Catalog rules: business versus retail catalogues and prices; preferred accounts; schedules.
• Elastic Path — Changelog, 21 November 2025: catalog rules targeting account tags.
• Elastic Path — Price segmentation guide: reseller-specific price books via catalog rules.
• Elastic Path — Changelog, 10 February 2026: Catalog Search.
• Elastic Path — Changelog, 16 July 2026: search profiles on catalog rules.
• Elastic Path — Changelog, 23 September 2026: custom user roles in Commerce Manager.