Adobe Commerce as a Cloud Service (ACCS) is Adobe’s fully managed, multi-tenant SaaS version of Adobe Commerce, launched in 2025. It removes hosting, patching, and version upgrades in exchange for less low-level customization, using out-of-process extensibility through App Builder instead of core code edits. It suits merchants who want the enterprise B2B feature set without owning infrastructure.
If you have run Adobe Commerce or Magento for any length of time, ACCS is the most significant change to the platform’s operating model in years. It moves Adobe Commerce toward the same managed SaaS shape as Shopify, and it changes how you extend, integrate, and think about upgrades. This guide explains what ACCS is, how it differs from self-hosted and PaaS Adobe Commerce, the real tradeoff at its center, and how to decide whether it fits your store.
We build and support Adobe Commerce across all three deployment models at Bemeir, a Brooklyn Magento and Adobe Commerce agency, so the goal here is a practitioner’s read, not a product brochure.
What ACCS actually is
ACCS is Adobe Commerce delivered as software as a service. Instead of you (or your agency) provisioning servers, applying patches, and running version upgrades, Adobe operates the platform for you on a multi-tenant, versionless architecture that updates automatically. You configure and extend it; you do not host or maintain it.
Three ideas define it:
- Versionless and auto-updated. There is no annual 2.4.x upgrade project. Adobe ships updates continuously, which removes the patch and upgrade cycle that dominates self-hosted Magento operations.
- Composable and API-first. ACCS is built around SaaS services (catalog, Live Search, product recommendations), API Mesh for stitching data sources, and Edge Delivery Services for the storefront.
- Extended out of process. You customize behavior with App Builder apps and out-of-process modules rather than editing core code. This is the single most important difference from self-hosted Adobe Commerce, and it is covered in its own section below.
Critically, ACCS keeps the enterprise B2B feature set that makes Adobe Commerce worth choosing in the first place: company accounts, shared catalogs, negotiable quotes, requisition lists, and approval workflows. You are not trading down on commerce capability; you are trading down on infrastructure control.
ACCS vs PaaS vs self-hosted Adobe Commerce
Adobe Commerce now exists in three shapes, and the names get confused constantly. Here is the honest breakdown.
| Dimension | Self-hosted (on-prem) | Adobe Commerce on Cloud (PaaS) | Adobe Commerce as a Cloud Service (ACCS) |
|---|---|---|---|
| Who runs the servers | You or your host | Adobe-managed cloud infrastructure | Adobe, fully managed SaaS |
| Upgrades and patches | You own them | You own them (Adobe hosts) | Adobe handles them, versionless |
| Customization model | Full core access, custom modules | Full core access, custom modules | Out-of-process via App Builder only |
| Tenancy | Single tenant | Single tenant | Multi-tenant |
| Best for | Maximum control, heavy custom code | Enterprise wanting managed infra, still deep custom | Merchants wanting SaaS simplicity with enterprise B2B |
| Operational burden | Highest | Medium | Lowest |
The pattern: as you move from self-hosted to PaaS to ACCS, you give up low-level control and get back time, predictability, and a smaller operations bill. The question is whether your store needs the control you would be giving up.
The tradeoff at the center: out-of-process extensibility
This is where merchants and developers need to pay attention, because it changes how customization works.
On self-hosted Adobe Commerce and Magento, you extend the platform in process: you write custom modules that run inside the core application, override classes, and touch the database directly. That power is also the reason upgrades are painful, because your custom code is entangled with the core you are trying to upgrade.
ACCS uses out-of-process extensibility (OOPE) instead. Your customizations live in App Builder, a serverless Node runtime on Adobe’s infrastructure, and they extend Commerce through webhooks, events, and APIs without modifying core code. Adobe ships a set of out-of-process extensibility modules for the common integration points: payment methods, shipping methods, tax, totals, custom attributes, and API integration.
The benefit is real: because your code no longer lives inside the core, Adobe can update the core continuously without breaking your customizations. That is what makes versionless possible. The cost is equally real: things you used to do with an in-process module, like deep database manipulation or overriding core behavior line by line, are either not possible or must be re-architected as an external service. Some existing extensions and customizations will not port directly and have to be rebuilt the OOPE way.
If your store depends on a pile of heavily customized in-process modules, that re-architecture is the main cost of moving to ACCS, and it should be scoped honestly before you commit.
Who ACCS is for, and who should stay on PaaS
ACCS is a strong fit if you want enterprise B2B commerce without running infrastructure, you are tired of the upgrade and patch treadmill, your customization needs are moderate and can be expressed as integrations and apps rather than core edits, and you value predictable operations over maximum control. It is also attractive to merchants comparing Adobe Commerce with Shopify who want a managed model but need deeper native B2B than Shopify provides.
You should probably stay on PaaS or self-hosted if you run extensive in-process customization that would be expensive to re-architect, you need direct database access or low-level control, or you have compliance or data-residency requirements that a multi-tenant SaaS does not yet satisfy. For stores like these, the mature managed-infrastructure model of Adobe Commerce on Cloud is still the right home, and our Adobe Commerce security and PCI runbook covers the compliance questions worth asking before any move.
This is also the natural landing platform for some teams leaving other systems. In our guide to Adobe Commerce versus SAP Commerce Cloud, the managed SaaS option is one of the reasons Adobe now competes directly with other enterprise SaaS commerce platforms.
What about the frontend?
ACCS pairs with Edge Delivery Services, Adobe’s edge-rendered storefront approach that targets very fast page loads and strong Core Web Vitals out of the box. It is document-and-component driven and different from the traditional Luma or Hyva frontends that most Magento merchants run today.
This matters for planning. If your store already runs a fast Hyva frontend on self-hosted or PaaS Adobe Commerce, a move to ACCS with Edge Delivery is a frontend rebuild, not a lift and shift. If your store is on a slow Luma theme, the performance argument for a modern frontend applies either way, and the choice becomes Hyva on PaaS versus Edge Delivery on ACCS. Both can deliver strong performance; the deciding factor is usually your operating-model preference and how much custom frontend logic you carry.
Migration considerations
Moving to ACCS is a project, not a switch. The three things to scope honestly are:
- Customization audit. Catalog every in-process module and custom override, and decide for each whether it becomes an App Builder app, a native ACCS feature, or gets retired. This is the work that determines the timeline.
- Integration re-architecture. ERP, CRM, POS, PIM, and payment integrations move to the out-of-process model. The good news is that clean, API-based integrations often port more easily than tangled in-process ones. Our technology partners ecosystem, with 60+ integrations, is where a lot of this connective work happens.
- Frontend decision. Decide between Edge Delivery on ACCS and keeping a Hyva frontend on PaaS, and price both paths.
Rushing any of these is how a SaaS migration that promised simplicity turns into an expensive surprise. A discovery phase that maps your customizations to the OOPE model is the cheapest insurance you can buy.
What ACCS costs
Adobe does not publish list pricing for ACCS, and every deal is negotiated, so treat any figure you see online as a planning band rather than a quote. The license follows the same logic as Adobe Commerce generally: it scales with your gross sales and order volume, and it is quoted through a sales conversation. What changes with ACCS is the shape of the total cost of ownership, not just the license line. Because Adobe runs the infrastructure and owns upgrades and patching, you remove the hosting bill, the recurring upgrade projects, and much of the security-patching retainer that self-hosted stores carry. For merchants whose operations budget is dominated by those items, the all-in cost can land lower even if the license itself is comparable. For merchants whose spend is dominated by deep customization, the re-architecture work can offset the operational savings, at least in year one. Model both sides before you assume ACCS is cheaper.
How Bemeir helps
We work as an extension of your team across self-hosted, PaaS, and ACCS. Our value on an ACCS decision is honesty about the tradeoff: we will tell you when your customization footprint makes ACCS a poor fit and when it makes ACCS the obvious upgrade. We also build on Shopware and BigCommerce when a different platform genuinely fits better, and you can read more about how we operate on our about page. The goal is the right operating model for your business, not the newest one.
FAQ
What is Adobe Commerce as a Cloud Service (ACCS)?
ACCS is Adobe’s fully managed, multi-tenant SaaS version of Adobe Commerce, launched in 2025. Adobe runs the infrastructure, applies updates continuously, and keeps the platform versionless, so there are no self-managed upgrades or patches. You configure and extend it through App Builder rather than editing core code, and it retains the enterprise B2B feature set of Adobe Commerce.
How is ACCS different from Adobe Commerce on Cloud?
Adobe Commerce on Cloud (PaaS) gives you Adobe-managed hosting but you still own upgrades, patches, and full in-process customization on a single-tenant environment. ACCS is multi-tenant SaaS where Adobe also owns upgrades and patches, and customization happens out of process through App Builder. PaaS offers more control; ACCS offers less operational burden.
Can I customize ACCS the way I customize self-hosted Magento?
Not in the same way. Self-hosted Magento lets you write in-process modules that run inside the core and access the database directly. ACCS uses out-of-process extensibility, where your code runs in App Builder and extends Commerce through webhooks, events, and APIs. Deep core overrides and direct database manipulation are replaced by external apps and integrations, and some existing customizations must be rebuilt.
Does ACCS support B2B?
Yes. ACCS retains the Adobe Commerce enterprise B2B feature set, including company accounts, shared catalogs, negotiable quotes, requisition lists, and approval workflows. Moving to ACCS is a change in operating model and customization approach, not a downgrade in commerce capability.
Should I move from self-hosted Adobe Commerce to ACCS?
It depends on your customization footprint. If your store relies on many heavily customized in-process modules, moving to ACCS means re-architecting them as out-of-process apps, which can be significant work. If your customization is moderate and expressible as integrations, ACCS removes the upgrade and patch burden and is often worth it. Scope a customization audit before deciding.
What frontend does ACCS use?
ACCS pairs with Edge Delivery Services, Adobe’s edge-rendered storefront designed for fast page loads and strong Core Web Vitals. It differs from the Luma and Hyva frontends most Magento merchants run today, so moving to ACCS from an existing Hyva storefront is a frontend rebuild rather than a straight migration.
