Adobe Commerce as a Cloud Service, Explained for Australian Stores

Adobe Commerce now comes in three deployment models: on-premises, on Adobe’s Cloud infrastructure, and Adobe Commerce as a Cloud Service. The third is the new one. It is software as a service, and Adobe’s lifecycle policy calls it “Adobe’s recommended long-term destination for all Adobe Commerce on Cloud customers.”

If you run Adobe Commerce in Australia, your Adobe account team will raise it sooner or later. Here is what the product is, what changes and what does not carry over, checked against Adobe’s own pages on 4 October 2026. Our developers hold Adobe Commerce and Shopify certifications, so we have no platform to protect in the answer.

What Adobe Commerce as a Cloud Service is

Adobe announced it at Adobe Summit 2025, and on 25 June 2025 Adobe’s blog announced “the launch of Adobe Commerce as a Cloud Service”. Adobe’s documentation does not give a separate general availability date, so we treat June 2025 as the launch.

Adobe’s getting started guide describes it like this: “This SaaS offering is a fully managed, versionless platform that provides a seamless upgrade experience without manual intervention.” Its pricing page calls it “a complete commerce solution delivered as a multi-tenant cloud service with automatic feature and security updates.”

The Commerce Admin is still there for products, orders, customers and configuration, and core B2B features come pre-installed. Around it, Adobe’s overview lists:

• Commerce Storefront, a headless storefront powered by Edge Delivery Services.
• Merchandising services: Live Search, Product Recommendations and Catalog Service, with Payment Services alongside.
• Product Visuals, asset management powered by AEM Assets.
• A developer platform: App Builder, API Mesh, events, webhooks, the Admin UI SDK and an integration starter kit.

Instances are created in the Commerce Cloud Manager, which Adobe says provisions sandbox and production instances in minutes with those services already connected. Adobe Commerce Optimizer is a different product: a SaaS storefront and merchandising layer for other commerce engines.

On-premises, Cloud and Cloud Service compared

Adobe’s feature comparison sets the SaaS model against the PaaS model, and notes that on-premises “shares similar capabilities with the PaaS model”. Here is how the three line up.

	On-premises	Adobe Commerce on Cloud (PaaS)	Adobe Commerce as a Cloud Service (SaaS)
Who hosts it	You or your hosting provider	Adobe, on single-tenant infrastructure	Adobe, on multi-tenant infrastructure
Core patches and upgrades	You apply them	You apply them	Adobe applies them
Release model	Versioned: six patch releases and one minor release a year	Versioned, as on-premises	Versionless
PHP, database, search and other services	You run and update them	You keep them on supported versions	Adobe runs them
Custom code	In-process PHP and out-of-process apps	In-process PHP and out-of-process apps	Out-of-process only: APIs, events, App Builder
Changing core code	Possible	Possible	Not possible
Storefront	Luma theme or headless	Luma theme or headless	Commerce Storefront on Edge Delivery Services, no Luma
Version deadlines	Adobe’s lifecycle dates	Lifecycle dates, plus Cloud enforcement dates	Not applicable, as there are no versions

Versionless updates and who patches what

On Cloud and on-premises, every patch and upgrade is a project you schedule. Adobe’s comparison describes the PaaS model as “Requires manual upgrade and patching.” That is why the dates in our Magento 2.4 end of life dates post matter, and why Magento upgrades are a recurring cost.

On Cloud Service there is no version to fall behind on. Adobe sends in-app notices when updates are released, and its overview says: “You have a 30-day period to evaluate the new capabilities in your sandbox instances before the updates are automatically applied to your production environments.” The release notes show it working: the first October 2026 release went to sandboxes first, with production set for 6 October 2026.

Adobe also says it “guarantees backward compatibility for all updates”. The guarantee covers customisations “that adhere to the API-first extensibility model”, which is the only model the platform accepts. Your apps still deserve a test in that 30-day window.

The shared responsibility model

In Adobe’s shared responsibility table for Cloud Service, Adobe is responsible and accountable for fixing core bugs, publishing and installing core updates and patches, infrastructure patches, scaling and firewall (WAF) rules. The customer is responsible and accountable for installing, deploying and maintaining App Builder apps, integrating external applications, and “Testing performance of all App Builder apps”. Debugging and issue isolation are shared.

Compare Adobe’s description of Cloud (PaaS), where “The merchant manages application-level patches, custom code, configuration, and updates extensions and platform services to supported versions”.

The move takes patching and upgrades off your list, but not your apps, integrations or testing.

Extending it without changing the core

Adobe’s migration guide is direct: “Merchants cannot modify core application code.” Everything custom runs outside the application and talks to it through APIs and events. The tools for that are:

• App Builder, for applications that “extend Commerce functionality and integrate with third-party solutions”, written in JavaScript on Node, not PHP.
• API Mesh, which combines several APIs, such as Commerce, an ERP and a PIM, into one GraphQL endpoint.
• Events, which send Commerce activity to your apps.
• Webhooks, which let Commerce call an app and act on its answer. The October 2026 release notes give an example: a shipping rates webhook that App Builder shipping integrations use to decide eligibility, such as free shipping.
• The Admin UI SDK, which adds pages and features to the Commerce Admin.

Adobe’s comparison also lists limits to check before you commit. Custom data storage is the “App Builder state library (file only)”, with database storage in early access. Search index customisation “Requires third-party solutions”. Email is “Standard email templates only”. Data model changes are custom attributes on core and B2B entities, not complete customisation.

The storefront: Edge Delivery Services

The storefront is the other big change. Adobe’s Commerce Storefront runs on Edge Delivery Services and, in Adobe’s words, “is fully headless with a decoupled architecture that provides all Adobe Merchandising Services and data through a GraphQL API layer.” The code lives in a GitHub repository, and content is edited as documents or in the visual Storefront Builder, which Adobe lists as the replacement for Page Builder and the CMS.

Adobe also says: “Adobe Commerce as a Cloud Service does not support Luma storefronts.” The storefront is a rebuild, and like any rebuild it needs its URLs and redirects planned well before launch.

How existing stores migrate

Adobe’s migration guide covers four areas, the application, data, storefront and integrations, and says “none of these areas can be migrated without adapting them.” It sets out four phases: assess, modernise the application and migrate data, modernise the storefront, then cut over.

Adobe provides a tool for each workflow:

• Migration Assessment Tool. An AI-driven scan that inventories custom modules, extensions, integrations and custom tables, and maps each to a Cloud Service equivalent with effort estimates.
• Commerce Developer Agent and Commerce Developer MCP. AI-assisted tools that turn PHP customisations into App Builder applications and help rebuild the storefront on Edge Delivery Services.
• Commerce Data Migration Service. Moves catalogue, customer and order data and verifies it. Most of the work runs while the store is live, with a maintenance window for the final cutover.

Adobe adds that AI-generated recommendations and implementations “should be carefully reviewed and validated by your team”. Its lifecycle policy tells Cloud customers to contact their Adobe account team to begin a migration assessment.

What does not carry over

• Custom modules. Plugins, observers and other in-process PHP stop working as they are. Adobe says customisations “run as out-of-process Adobe Developer App Builder applications”, and calls that work “typically the most significant engineering effort” in a migration.
• Marketplace extensions. Cloud Service takes App Builder apps from Adobe’s marketplace, not PHP extensions. Each extension you run needs a native feature, an app or a rebuild.
• Extension data. Data held in custom tables by third-party extensions is not part of the standard data migration. Adobe says it “requires an App Builder customization”.
• The theme. Luma themes do not carry over.
• Deep platform changes. Custom search indexing, custom email types and data model changes beyond custom attributes need a different design.

Your catalogue, customers and orders do carry over, through Adobe’s data migration service. The work is in everything that made your store different.

Licensing: no published price

Adobe publishes no pricing for Adobe Commerce as a Cloud Service. Its pricing page, including the Australian version, lists Cloud Service, Cloud and Commerce Optimizer with a “Get pricing” button each, and offers “customized pricing for Adobe Commerce”. We can’t give you a figure, and we won’t guess one. If you are weighing it against Magento Open Source, our Magento Open Source vs Adobe Commerce post covers that licensing question.

Who it suits, against staying or moving to Shopify

Staying on Cloud (PaaS). Adobe is not forcing anyone off it. In March 2026 it wrote: “There are no end-of-support or end-of-life plans for Adobe Commerce on Cloud (PaaS).” Its lifecycle policy is equally clear that staying “does not eliminate future upgrade obligations”. Staying suits stores whose value sits in deep in-process customisation, such as custom data models, search or checkout logic, where rebuilding it as apps would cost more than the upgrades it saves.

Moving to Cloud Service. It suits businesses staying with Adobe, often for other Experience Cloud products or its B2B features, that want to stop running upgrade projects. It fits better when their customisations are few or due for a clean-up anyway.

Moving to Shopify. Shopify is SaaS too, so it removes the upgrade cycle in the same way, and the migration has a similar shape: custom code rebuilt as apps, the storefront rebuilt, data moved. The choice between the two turns on how much of your commerce logic needs Adobe’s depth, and on total cost over three years. Our Adobe Commerce vs Shopify Plus comparison sets out that test.

We look at all three paths from the store’s side. Two of our developers hold Adobe Commerce certifications and three hold Shopify certifications, and we have run Aelia Duty Free’s Adobe Commerce platform since 2021. On a platform like that, the duty and tax logic, real-time inventory and SAP exports decide the platform question, not the hosting model.

Until any move, the store still needs Magento support, and a Magento security review if it may be exposed. For the decision itself, our free stay-or-move assessment gives you a written recommendation, the main risks and the items that decide it. More on our Adobe Commerce work.

---

Sources: Adobe Commerce as a Cloud Service overview, Getting started, Adobe Commerce SaaS vs PaaS comparison, Shared responsibility security and operational model, Migrate to Adobe Commerce as a Cloud Service, Set up your storefront, Adobe Commerce as a Cloud Service release notes, Adobe Commerce lifecycle policy, Adobe Commerce packages and pricing, Drive conversions, accelerate time to market, and lower costs with Adobe Commerce as a Cloud Service and Continued investment and support for Adobe Commerce on Cloud (Adobe).