Since I published my introduction to ACCS, the question I get most is a simple one: “Should we move?” Usually it comes from a merchant already on Adobe Commerce on Cloud, sometimes from a team starting fresh. My honest answer is “it depends”. Since that isn’t much help on its own, this post goes through what it actually depends on.
Everything below comes from Adobe’s own Experience League docs, mainly the SaaS vs PaaS feature comparison and the ACCS overview, plus my own experience running PaaS projects. Where I couldn’t confirm something, I say so.
A quick refresher on the two models
Adobe Commerce on Cloud (PaaS) is the setup most of us know. Adobe runs the infrastructure and you own the application: composer, PHP modules, themes, deployments, upgrades. It’s single-tenant, and you get Fastly and New Relic in the box.
Adobe Commerce as a Cloud Service (ACCS) is the SaaS model. Adobe runs both the infrastructure and the application. It’s multi-tenant and versionless, and you extend it only from the outside.
Cost and licensing
I’ll be careful here. Adobe doesn’t publish list prices for either model. Both are licensed through Adobe sales on custom contracts, so any number you see in a blog post (including some I have seen floating around LinkedIn) is a guess. I won’t add another one.
What I can compare is where the money goes. On PaaS, a big part of the total cost is labour you pay for outside the licence: upgrade projects, quarterly patching, regression testing and monitoring. The docs list six patch releases and one minor release per year, and each needs someone’s time. ACCS moves that work to Adobe. You still pay for development, but the effort shifts toward App Builder apps and the storefront instead of maintenance. One thing to note: on ACCS, a New Relic licence isn’t included, so if your ops team lives in New Relic, budget for your own account.
Upgrades
This is where ACCS is clearly ahead. On PaaS, upgrades and patches are manual. On ACCS, Adobe pushes updates and sends an in-app notice. You then get 30 days to try them on your sandbox before they reach production automatically. Adobe also says updates are backward compatible for customisations that follow the API-first model.
The catch is the phrase “that follow the API-first model”. You can’t freeze a version. If something does break, you fix your side within that window.
Customisation limits
Teams underestimate this part. On PaaS, you can change the data model completely: new tables, EAV attributes, custom entities, whatever. On ACCS, the docs describe data model extensibility as custom attributes for core and B2B entities. That covers a lot of real needs, but not a custom “warranty registration” entity with its own tables.
A few other limits I’d flag in any discovery workshop:
- Search: native search customisation exists on PaaS. On ACCS, the docs say custom search index changes need third-party solutions. Live Search covers the standard cases.
- Emails: PaaS gives full email customisation. ACCS supports standard email templates only.
- Storage: PaaS gives you database, file, cache and queue. ACCS gives the App Builder state library (file only), with database storage for App Builder in early access. If you need long-term custom data, you may have to run your own store somewhere.
- Admin: no PHP theming of the Admin. Changes go through App Builder and the Admin UI SDK.
Extensibility
PaaS supports both in-process (PHP modules, plugins, observers) and out-of-process (APIs, events, App Builder). Adobe now recommends the out-of-process route even on PaaS. ACCS is out-of-process only. On the API side, PaaS lets you extend REST and GraphQL natively and use API Mesh. ACCS gives you API Mesh with custom resolvers.
The technology lists in the docs sum it up nicely. PaaS: CSS, CLI, HTML, JS, PHP, XML. ACCS: CSS, CLI, HTML, JS, Node. No PHP. If your team is all PHP backend developers, that’s a hiring and training question, not just a technical one.
Storefront options
PaaS is flexible here: Luma, Hyvä, PWA Studio, a custom headless frontend or the Edge Delivery Services storefront. ACCS doesn’t support Luma. The intended storefront is Commerce Storefront on Edge Delivery Services, with document-based authoring or the visual Storefront Builder. On the content side, PaaS has Page Builder and the CMS, and ACCS replaces them with Storefront Builder.
If you just spent a year building a Hyvä theme, keep that in mind. It won’t come with you.
Hosting and ops responsibility
On PaaS, Adobe handles the infrastructure, but your team still owns deployments, the .magento.app.yaml files, cron issues, indexers and a lot of 2 a.m. incidents. Observability means New Relic, and Fastly is your CDN.
On ACCS, Adobe manages the application too. You get OpenTelemetry for App Builder apps and RUM dashboards for the storefront. The CDN is a managed edge CDN tied to the storefront, and bring-your-own CDN is supported. Your ops scope shrinks to your own apps and integrations. I’m happy about that, but it also means you have less low-level visibility when something odd happens in the core.
Performance and scaling
PaaS has horizontal auto-scaling on the scaled architecture, and vertical auto-scaling for the web tier is rolling out in early access. ACCS is described as a multi-tenant cloud-native app with full auto-scaling across the stack. Anyone who has raised a ticket to get extra capacity before Black Friday will see why that matters.
One detail goes the other way. The SLA numbers in the comparison are 99.99% infrastructure and 99.9% application (with Managed Services) for PaaS, and 99.9% for infrastructure and application on ACCS, with faster RPO/RTO. Read your contract, not a blog, for the final figures.
Compliance and regions
Both cover SOC 2, PCI and ISO. ACCS also lists GDPR. The big difference: HIPAA is not currently available on ACCS, while PaaS lists it. For a health or pharma store, that alone can decide it. PaaS also has documented regions across Azure, AWS and GCP. For ACCS, Adobe describes it as globally available but tells you to check with your rep for production regions, so data residency needs a conversation early on.
Side-by-side comparison
| Area | ACCS (SaaS) | Commerce on Cloud (PaaS) |
|---|---|---|
| Pricing | Custom contract, no public list price | Custom contract, no public list price |
| Tenancy | Multi-tenant | Single-tenant |
| Updates | Automatic, versionless, 30-day sandbox preview | Manual: 6 patches + 1 minor release a year |
| Extensibility | Out-of-process only | In-process (PHP) and out-of-process |
| Languages | JS/Node, HTML, CSS | PHP, XML, JS, HTML, CSS |
| Data model | Custom attributes on core and B2B entities | Full customisation |
| Custom storage | App Builder state (file); DB in early access | DB, file, cache, queue |
| Storefront | EDS Commerce Storefront; no Luma | Luma, Hyvä, PWA, headless, EDS |
| Content tools | Storefront Builder | CMS, Page Builder |
| CDN | Managed edge CDN, BYO supported | Fastly included |
| Observability | Adobe-managed; OpenTelemetry, RUM; no New Relic licence | New Relic included |
| Scaling | Full-stack auto-scaling | Horizontal (scaled arch.), vertical in early access |
| SLA | 99.9% infra and app | 99.99% infra, 99.9% app (Managed Services) |
| Compliance | SOC 2, PCI, ISO, GDPR; no HIPAA yet | SOC 2, PCI, ISO, HIPAA |
| B2B | Core B2B pre-installed | Full B2B after installation |
So which one fits your store?
Pick ACCS if…
- You’re starting fresh. A D2C fashion brand launching a new store has no legacy modules to port, and the EDS storefront is fast from day one.
- Your logic already lives elsewhere. A distributor whose pricing, stock and orders sit in an ERP mostly needs integrations, and App Builder handles those well.
- Upgrades are hurting you. If you’re two minor versions behind and dreading the next project, versionless is a real relief.
- You need standard B2B quickly. Company accounts and quoting come pre-installed.
- Your team is JavaScript-heavy. Node and frontend developers will feel at home.
Pick Cloud (PaaS) if…
- You need HIPAA. A pharmacy or medical supplies store can’t use ACCS for that today.
- Your data model is unusual. An automotive parts store with custom fitment tables and dealer-specific entities will hit the attribute-only limit fast.
- You rely on deep checkout or search customisation written in PHP, and rewriting it isn’t worth it yet.
- You just invested in Luma or Hyvä and need that frontend to keep paying off for a few years.
- You need custom email types or heavy custom storage beyond what App Builder offers today.
My take
For new projects, I’d now start the conversation at ACCS and move to PaaS only if a specific blocker comes up: HIPAA, data model, or a frontend you can’t give up. For existing PaaS stores, I wouldn’t rush. Instead, start moving custom code out-of-process now, since Adobe recommends that even on PaaS. Every observer you turn into an event-driven App Builder action is one less thing to rewrite later, whichever way you go.
A practical first step: export your module list, mark each one “in-process only”, “can go out-of-process” or “replaced by a native ACCS feature”, and see which pile is biggest. That spreadsheet will tell you more than any comparison table, including mine.
