Adobe Commerce as a Cloud Service
What this article About?
On March 14th, Adobe sent out a newsletter announcing plans to launch a new Adobe Commerce product in June: Adobe Commerce as a Cloud Service (also referred to as Adobe Commerce SaaS or sometimes mistakenly as Adobe Commerce Could).
Wait—What Are the Differences Between All These Adobe Commerce Products?
Let’s break them down:
Adobe Commerce (a.k.a. on-premises): This is an enhanced version of Magento 2 Open Source. It includes enterprise-level functionality, access to the codebase, Adobe services (like Adobe Sensei), and Adobe Support—but does not include hosting.
Adobe Commerce Cloud:
A hosted version of Adobe Commerce, where Adobe provides both the eCommerce solution and infrastructure. You get the same functionality, but hosting is managed by Adobe.
Adobe Commerce as a Cloud Service (SaaS):
A new, fully managed SaaS variant of Adobe Commerce. It runs in an isolated environment, with restricted access to the codebase. You consume it more like a black-box service, interacting only via APIs.
Is Adobe Trying to Compete with Shopify?
Not exactly. While they’re both cloud-based, Adobe Commerce SaaS and Shopify serve very different segments.
Think of it this way:
Shopify is like a plane: you buy a seat, and it takes you to your destination. You pay for the luggage and any extras.
Adobe Commerce SaaS is like a zeppelin: you own it, fund its construction, and have your own private space in the cloud. It can take you wherever you want to go - but you’re also responsible for the fuel, maintenance, and overall complexity of managing it.
Why Choose Adobe Commerce SaaS?
According to Adobe, the key benefits are:
-
Reduced upgrade complexity
-
Lower total cost of ownership
-
Improved security
-
Enhanced performance
Does Adobe Commerce SaaS Solve the Upgrade Problem?
Yes and no.
The challenge with upgrades wasn’t Adobe Commerce itself, but the customizations built around and within it. Magento 2 and Adobe Commerce are highly flexible—but that flexibility often leads to technical debt.
“Let’s do it fast” × 100 = Nightmare during upgrades
Upgrades become costly not because Adobe Commerce is hard to upgrade, but because of fragile, short-sighted customizations.
That said, potential upgrade issues will shift toward API-level integrations between components. While this approach is generally more resilient, some releases may introduce backward-incompatible changes, requiring careful coordination across teams during version rollouts.
How Does Adobe Commerce SaaS Reduce the Cost of Ownership?
Restricted codebase access: Customizations must go through APIs (REST or GraphQL), reducing the risk of breaking internal logic.
Component isolation: Services are separated into external apps (via App Builder or others), reducing interdependencies.
Simplified tech stack: Instead of requiring deep knowledge of Adobe Commerce internals, new developers only need JavaScript (Node.js + Cosmos DB/React) skills and basic familiarity with Adobe Services. Over time, this lowers the onboarding curve and reduces overall development and support costs.
Why Is Adobe Commerce SaaS More Secure?
No zero-day vulnerabilities: SaaS instances are patched as soon as security updates are released.
Centralized security: Adobe handles security for infrastructure, Adobe Commerce, and related services. The only remaining attack surface is third-party integrations and custom external services.
How Will Adobe SaaS Offer Better Performance?
Like Adobe Commerce Cloud, it provides the benefits of a cloud-native environment.
Additionally, by restricting direct access to the codebase, developers are prevented from introducing performance bottlenecks within the Adobe Commerce application.
However, performance concerns still exist, such as:
-
Increased network latency from microservices communicating via APIs
-
Application bottlenecks (within the ecosystem)
-
Potential performance issues in the Storefront application (e.g., React-based)
What Are the Drawbacks?
More expensive development: Without access to the codebase, you'll need to build external services, increasing the time and cost.
Limited extension options: Adobe Exchange supports fewer applications for Adobe Commerce (for now) than Adobe Commerce Marketplace.
App Builder limitations: Currently lacks support for complex data models. For instance, Cosmo DB may work for attaching metadata, but complex features (like a blog) require third-party apps or custom services.
Customization complexity: If the default behavior (e.g., inventory, cart or order flow) doesn’t fit your needs, modifying or extending it via API can be complex and fragile.
Limited talent pool: Successfully delivering an Adobe Commerce SaaS project requires developers with a rare combination of skills: Adobe Commerce, the Adobe Commerce Cloud environment, Adobe Services (including App Builder), as well as advanced knowledge of Node.js, React.js, and Cosmos DB. Currently, finding candidates with this complete skill set is a significant challenge.
Challenging troubleshooting: A distributed architecture increases the time and effort needed to debug and resolve issues across the ecosystem, as problems may span multiple services and applications.
Complicated data migrations: Unlike traditional Adobe Commerce, where data updates can often be handled with a simple PHP script, a distributed environment requires each migration to be carefully planned and orchestrated. Ensuring data consistency across multiple applications adds a layer of complexity and risk.
When Does Adobe Commerce SaaS Make Sense?
Large developer teams: It’s much easier to coordinate development when working outside of a monolithic codebase.
B2C merchants with business requirements that do not require changes of processes within the commerce engine .
B2B merchants whose models align well with Adobe’s existing B2B feature set.
To Conclude
Adobe Commerce SaaS seems like an effort to wrap Adobe Commerce in a black box and deliver it as a service. While the benefits - especially automated updates - are compelling, the trade-offs in flexibility, cost, and complexity raise important questions.
In essence, it is the first “Adobe Commerce” product where the “Cloud Services” matters more than the commerce engine itself.
From my perspective, Adobe Commerce Cloud already offers the right balance: the flexibility to customize the platform where needed (codebase access) and the ability to extend it externally via App Builder. Therefore, Adobe Commerce SaaS appears to be a product designed to serve a narrower segment of merchants.
At first glance, Adobe Commerce SaaS may seem like an unconventional solution to the long-standing challenge of upgradability. That said, the strategy may become more compelling when seen as part of a broader architectural transformation. If Adobe Commerce is now hidden behind the veil of Adobe Commerce SaaS, how can we be sure that the original Adobe Commerce engine still exists beneath it - rather than a completely reimagined architecture built on a collection of microservices?