Adobe Commerce is now sold in two cloud forms with confusingly similar names. Adobe Commerce on Cloud is the platform-as-a-service most enterprise Magento merchants know: Adobe hosts the infrastructure, and you own the application, the upgrades and the code. Adobe Commerce as a Cloud Service is Adobe's SaaS edition: Adobe runs the core application too, applies updates continuously, and you extend it from the outside through APIs and App Builder. As an Adobe Commerce agency, we get asked weekly which one a merchant should be on, and the honest answer depends on how much custom code your store carries.
This guide explains what actually differs between the two, what moving from one to the other involves, and how to decide on timing. Everything here is based on Adobe's own Experience League documentation as of October 2026, linked at the end.
The short version
| Adobe Commerce on Cloud | Adobe Commerce as a Cloud Service | |
|---|---|---|
| Model | PaaS, Adobe-managed hosting | SaaS, Adobe-hosted application |
| Who upgrades the core | You (with your agency) | Adobe, continuously |
| Version numbers | 2.4.x release lines with end-of-support dates | Versionless |
| Custom code | PHP modules, plugins and observers inside the application | Out-of-process App Builder apps, events, webhooks and APIs |
| Core code changes | Possible | Not possible |
| Storefront | Luma, Hyva, PWA Studio or headless | Headless, with Commerce Storefront on Edge Delivery Services as Adobe's default |
| Platform services (database, search, cache, PHP) | Your responsibility to keep on supported versions | Managed by Adobe |
What Adobe Commerce on Cloud is
Adobe Commerce on Cloud infrastructure is a platform-as-a-service. Adobe's migration guide describes it as a shared responsibility model: Adobe manages the hosted platform, and the merchant manages application-level patches, custom code, configuration, and keeping extensions and platform services such as the database, cache, search, PHP runtime, web server and message queue on supported versions.
In practice, this is the familiar Magento 2 application with Adobe-managed hosting. You can install extensions, write PHP modules, override core behavior with plugins, and run any storefront the platform supports. The cost of that freedom is the upgrade cycle. Each 2.4.x release line has a fixed support window, and Adobe's lifecycle policy now adds an enforcement date for Cloud: from June 1, 2027, Adobe says it will no longer maintain Cloud environments running unsupported versions and may suspend traffic to them. Our guide to Magento 2.4 versions and end-of-support dates lists every deadline.
What Adobe Commerce as a Cloud Service is
Adobe Commerce as a Cloud Service is the SaaS edition, and the one people mean when they search for "Adobe Commerce SaaS." Adobe's documentation describes it as a versionless platform: Adobe manages the core Commerce application, the infrastructure and the updates. When new feature or security updates are released, Adobe sends in-app notifications and gives you a 30-day window to evaluate them in sandbox instances before they are applied to production automatically. Adobe states that it guarantees backward compatibility for customizations that follow its API-first extensibility model.
Adobe describes the product as several pieces working together:
- Commerce Foundation, the hosted application, provisioned self-service through Commerce Cloud Manager.
- Commerce Storefront, powered by Edge Delivery Services, with document-based authoring or a visual Storefront Builder.
- Merchandising services, including Live Search, Product Recommendations, Catalog Service and Payment Services.
- Product Visuals, digital asset management built on AEM Assets.
- The developer platform: App Builder, API Mesh, events, webhooks, the Admin UI SDK and an Integration Starter Kit for back-office connections.
Adobe positions it as the recommended long-term destination for Adobe Commerce on Cloud customers. Its lifecycle policy lists migrating to it as the recommended path for stores approaching end of support, because the version upgrade cycle does not recur.
The differences that decide the project
Customization moves out of the application
This is the biggest change. On Adobe Commerce on Cloud, customizations are usually PHP modules, plugins and event observers that run inside Magento. Adobe's migration guide is direct that this model no longer applies on the SaaS edition: customizations run as out-of-process App Builder applications that talk to Commerce through events and APIs, and merchants cannot modify core application code. Adobe also calls modernizing customizations typically the most significant engineering effort in a migration.
If your store has a handful of extensions, that is manageable. If it has years of custom checkout logic, pricing rules and ERP-specific modules, each one has to be redesigned, rebuilt as an app, replaced by a native service, or retired.
The storefront is rebuilt
Adobe states that Adobe Commerce as a Cloud Service does not support Luma storefronts. The default path is Commerce Storefront on Edge Delivery Services, which is fully headless and reads data through a GraphQL layer. Any theme that renders inside the PHP application, including Luma-based themes, has to be rebuilt as part of the move. Plan design and front-end budget accordingly, and treat it as a chance to fix the storefront rather than copy it.
Upgrades stop being projects
On Cloud, staying supported means a planned upgrade every few years plus regular patching. On the SaaS edition, Adobe applies updates for you after the 30-day evaluation window. Your team's job shifts to testing your apps and integrations against each update, not running the upgrade itself.
Infrastructure and services are Adobe's job
On Cloud, Adobe's lifecycle policy holds you responsible for keeping PHP, MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and other services on supported versions. On the SaaS edition, Adobe runs that stack. Adobe cites auto-scaling and 99.9% availability for the service.
Data and integrations are migrated, not lifted
Catalog, customer and order data moves through Adobe's Commerce Data Migration Service. Adobe notes that data held in custom tables by third-party extensions is not migrated automatically and may need an App Builder customization. Integrations with ERP, PIM and OMS systems have to be re-established using SaaS patterns such as App Builder, API Mesh and Adobe I/O Events.
What a migration looks like
Adobe's migration guide describes four phases:
- Assess. Adobe's Migration Assessment Tool scans the existing implementation and inventories custom modules, extensions, integrations, storefront characteristics, database schema and custom tables, then produces a roadmap with complexity scoring and effort estimates.
- Modernize the application and migrate data. Customizations are rebuilt as App Builder applications, with AI-assisted help from Adobe's Commerce Developer Agent or Commerce Developer MCP, while business data moves through the data migration service.
- Modernize the storefront. The storefront is rebuilt on Edge Delivery Services.
- Cut over and operate. Traffic switches to the new tenant and legacy systems are decommissioned.
Adobe stresses that its AI tooling produces recommendations that engineering teams still need to review and validate, and that migration is usually iterative rather than one big bang. That matches what we see on any Adobe Commerce migration: the assessment and the integration rebuild decide the timeline, not the data move.
Adobe also sells Adobe Commerce Optimizer, which uses the same storefront and merchandising services without the Commerce application. Adobe positions it for merchants who want to keep their existing commerce backend, or a third-party cart and checkout, and only transform the storefront. It is a separate decision from the Cloud Service move.
Who should move, and when
Move sooner if you are on Adobe Commerce on Cloud with a release line nearing its Cloud enforcement date (June 1, 2027 for 2.4.4 and 2.4.5), your storefront is due for a rebuild anyway, your customizations are modest or already API-based, and your team would rather spend its budget on features than upgrades.
Upgrade on Cloud first if your store carries heavy in-application customization that would take longer to rebuild than your support window allows, you depend on extensions with no App Builder equivalent yet, or you need specific B2B behavior that you have not yet confirmed on the SaaS edition. Adobe says the service supports B2B and B2C from a single instance, but check each B2B feature you rely on during the assessment. Upgrading to a supported 2.4.x line buys time to plan the SaaS move properly.
Stay on Magento Open Source or self-hosted Adobe Commerce if you need full control of the codebase and hosting. The SaaS edition trades that control for not having to maintain the platform. Our Magento Open Source vs Adobe Commerce comparison covers that decision.
For most of the Cloud merchants we talk to, the right sequence is an assessment now, a supported upgrade if the deadline is close, and a planned SaaS migration once the custom code has been mapped.
Sources
- Adobe Commerce as a Cloud Service overview, Adobe Experience League, last updated October 8, 2026
- Migrate to Adobe Commerce as a Cloud Service, Adobe Experience League, last updated October 8, 2026
- Adobe Commerce lifecycle policy, Adobe Experience League, last updated September 18, 2026
- What is Adobe Commerce Optimizer?, Adobe Experience League
Deciding between an upgrade and a SaaS move?
We will review your customizations, integrations and support dates and tell you which path fits, with a firm, itemized quote for the work.
Book a 30-minute assessmentFrequently asked questions
Is Adobe Commerce SaaS the same as Adobe Commerce Cloud?
No. Adobe Commerce on Cloud is a platform-as-a-service where Adobe hosts the infrastructure and you manage the application, patches and upgrades. Adobe Commerce as a Cloud Service is the SaaS edition, where Adobe also manages the core application and applies updates continuously.
Does Adobe Commerce as a Cloud Service have version upgrades?
Not in the traditional sense. Adobe describes it as versionless. New feature and security updates are announced in the app, you get 30 days to test them in sandbox instances, and Adobe then applies them to production automatically.
Can I keep my Magento extensions on Adobe Commerce as a Cloud Service?
Not as installed PHP modules. Customizations run as out-of-process App Builder applications that connect through events, webhooks and APIs, and core code cannot be modified. Each extension has to be replaced by a native service, an App Builder app from Adobe Exchange, a custom app, or retired.
Can I keep my Luma or Hyva theme?
Adobe states that Luma storefronts are not supported on Adobe Commerce as a Cloud Service. Themes that render inside the PHP application have to be rebuilt, usually on Commerce Storefront powered by Edge Delivery Services.
Do I have to move to Adobe Commerce as a Cloud Service?
No. Adobe recommends it as the long-term destination for Cloud customers, but you can stay on Adobe Commerce on Cloud as long as you keep upgrading to supported release lines before their enforcement dates. On-premises Adobe Commerce and Magento Open Source remain options too.
How long does a migration to Adobe Commerce as a Cloud Service take?
It depends mostly on how much custom code and how many integrations you have, since those must be rebuilt as App Builder applications. Adobe recommends starting with its Migration Assessment Tool, which produces complexity scoring and effort estimates for your specific implementation.