I have spent most of my Magento and Adobe Commerce career doing the same three things on repeat: writing plugins, fixing what those plugins broke after an upgrade, and planning the next upgrade. So when Adobe announced Adobe Commerce as a Cloud Service at Summit in 2025, my first reaction was not excitement. It was suspicion. A SaaS Adobe Commerce? The platform whose whole identity is “you can override anything”?
After reading through the docs, spinning up a sandbox and poking at the extension points, I have a clearer picture. This post is my attempt to explain what ACCS actually is, how it differs from the Commerce we already know, and where I think it fits. No marketing gloss, just what a developer needs to know before a client asks about it.
What is ACCS, in plain terms?
ACCS (Adobe Commerce as a Cloud Service) is a fully managed, versionless SaaS edition of Adobe Commerce. Adobe owns the core application, the infrastructure and the updates. You get a Commerce Admin, the usual catalog, order and customer management, and a set of APIs. What you don’t get is the codebase.
That last sentence is the whole story. There is no app/code folder for you to drop a module into. No di.xml preferences, no around plugins on Magento\Quote\Model\Quote, no composer require vendor/some-extension. If you need custom behaviour, you build it outside the core and connect it through APIs, events and webhooks.
Adobe groups the product into a few pieces:
- Commerce Foundation – the managed, headless Commerce backend you provision from Commerce Cloud Manager.
- Merchandising Services – catalog, pricing and search services (Catalog Service, Live Search, Product Recommendations).
- Commerce Storefront – a headless storefront powered by Edge Delivery Services.
- Developer Platform – App Builder, API Mesh, events, webhooks, the Admin UI SDK and the integration starter kit.
Versionless means no more upgrade projects
On PaaS or on-prem, an upgrade from 2.4.6 to 2.4.7 is a project. You bump composer constraints, run the Upgrade Compatibility Tool, fix deprecated calls, retest every third-party module and hope the payment extension vendor has shipped a compatible release. I have seen these drag on for two months on mid-size stores.
ACCS removes that. Adobe pushes updates and security patches continuously, and there is no version number for you to track. Your instance just keeps moving forward. The trade-off is obvious: you can’t hold back an update because your custom code depends on internal behaviour. Which is exactly why ACCS doesn’t let your code touch internal behaviour in the first place. The two decisions only make sense together.
Out-of-process extensibility: the real shift
This is the part most developers will need time to adjust to. Customisation in ACCS is “out-of-process”. Your code runs somewhere else and talks to Commerce over well-defined contracts. Here is how the tools map to things we used to do in PHP.
App Builder
Adobe Developer App Builder is a serverless platform built on Adobe I/O Runtime. You write actions (usually Node.js), deploy them with the aio CLI, and they scale independently of the store. Think of it as the new home for the code that used to live in custom modules: ERP sync, custom pricing logic, order export jobs.
Events and webhooks
Events replace a lot of our observers. When an order is placed, Commerce emits an event like observer.sales_order_save_after, and an App Builder action picks it up asynchronously. Good for things that don’t need to block the shopper, such as pushing the order to an OMS.
Webhooks cover the synchronous cases. Say a client needs to validate a B2B customer’s credit limit before checkout completes. On PaaS I’d write a plugin on the place-order flow. On ACCS you register a webhook on that operation, your external service answers, and Commerce can stop the process or modify data based on the response. Same outcome, different wiring.
API Mesh
API Mesh lets you merge several sources (Commerce GraphQL, a REST PIM, a stock service) into one GraphQL endpoint. I found this genuinely useful. Instead of writing a custom resolver that calls a third-party API from inside Commerce, you stitch it in at the mesh level and the storefront makes a single query.
Admin UI SDK
Need a custom grid column, a mass action or a new Admin page? The Admin UI SDK lets you add those from an App Builder app, without UI components XML in a module.
The storefront: Edge Delivery Services, not Luma
ACCS does not support Luma. Full stop. The storefront is headless, built on Edge Delivery Services (EDS), the same delivery layer behind AEM’s document-based authoring.
The model is different from what most Magento frontend developers are used to. Merchants author pages as documents (or in a visual editor). EDS turns them into HTML and serves them from the edge. Your Git repo, based on Adobe’s Commerce boilerplate, contains blocks written in plain JavaScript and CSS. Commerce features like the product page, cart, checkout and account come as drop-in components, which are npm packages that call Commerce GraphQL APIs from the browser. Push to GitHub and EDS publishes automatically.
Honestly, I like this. No more Knockout templates, no RequireJS mixins and no static content deploy. Lighthouse scores on the boilerplate are excellent out of the box. But if your client has a heavily customised Luma or Hyvä theme, that work does not carry over. It’s a rebuild.
ACCS vs Adobe Commerce on cloud vs on-prem
| Aspect | ACCS (SaaS) | Commerce on Cloud (PaaS) | On-premises |
|---|---|---|---|
| Who runs infrastructure | Adobe | Adobe (you manage the app) | You |
| Upgrades | Automatic, versionless | Your project | Your project |
| Core code customisation | Not allowed | Full PHP modules | Full PHP modules |
| Extensibility | App Builder, API Mesh, events, webhooks | Modules plus the same tools | Modules plus most tools |
| Storefront | Edge Delivery Services (headless) | Luma, Hyvä, PWA or EDS | Luma, Hyvä, PWA or EDS |
| Provisioning | Minutes, via Cloud Manager | Days to weeks | Up to you |
Migration: what to plan for
If you are moving an existing PaaS or on-prem store, this is not a lift-and-shift. From what I have seen, the work splits into three tracks:
- Audit your modules. List every custom and third-party module and sort them: replaced by native features, rebuilt as an App Builder app, available on Adobe Exchange, or dropped. On a typical store I’d expect a good chunk to fall into “do we even need this?”
- Move the data. Catalog, customers and orders have to come across. Adobe provides migration tooling and guidance for this, and it’s worth doing a test run early to find the messy attributes.
- Rebuild the storefront. Plan this as a frontend project in its own right. Adobe does allow transition approaches for existing storefronts, but the end state is EDS.
My advice: start with the integrations. They are usually the riskiest part and the easiest to prototype in App Builder while the old store is still live.
Who should consider ACCS?
ACCS makes a lot of sense for new builds, for brands tired of paying for upgrade cycles, and for teams that already lean on external services for ERP, PIM and OMS. If your business logic already lives outside Commerce, you lose very little.
It’s a harder sell for stores with deep checkout customisations, unusual product types built in PHP, or a long list of marketplace extensions with no SaaS equivalent. For them, PaaS still gives the control they rely on, and that’s fine. Adobe is not dropping PaaS.
My take
ACCS asks Adobe Commerce developers to give up something we have always had: the ability to change anything. In return, we stop spending weeks on upgrades and patching. I think that’s a fair trade for many projects, though not all.
If you want to get ready, here’s what I’d do this month. Learn the basics of App Builder and the aio CLI. Clone the Commerce boilerplate and build one custom block. Take one observer from a real project and rewrite it as an event-driven action. You’ll learn more from that than from any slide deck.
I’ll be writing more hands-on ACCS posts here, starting with webhooks. If there’s a specific part you want covered, let me know in the comments.
