There is no challenge for which they can't find a solution.
Will Aubuchon
CEO
Adobe Commerce as a Cloud Service
Adobe's versionless SaaS edition. No more upgrades, and no more PHP inside the application. Most merchants asking about it don't need to move yet.
Adobe Commerce gold partner
#1 Adobe Commerce partner worldwide
Hyvä Platinum Partner
40+ projects delivered
ISO certification
9001 & 27001
Most certified Hyvä agency worldwide
200+ Adobe Commerce Certifications
Adobe Subject
Matter Expert
Trusted by brands globally
Three paths, not two, and which one fits you
The debate is usually framed as stay on PaaS or move to SaaS. There's a middle option that suits more merchants than either, and it gets mentioned least.
Stay on Adobe Commerce on Cloud
Adobe has restated its commitment to PaaS. Six patch releases and one minor release a year, on your schedule.
- Cost
- Recurring upgrade projects
- Benefit
- In-application PHP, your own timing
Add Adobe Commerce Optimizer in front
A SaaS catalog, search and Edge Delivery layer in front of your backend. No replatform, no data migration.
- Cost
- A storefront build
- Benefit
- SaaS speed without touching the engine
Move to Adobe Commerce as a Cloud Service
The full SaaS edition. Adobe owns and updates the application, and customisation moves out of process.
- Cost
- A rebuild of storefront and integrations
- Benefit
- The upgrade cycle ends permanently
One caveat on the middle path
The Optimizer connector is B2C-oriented today. On Adobe Commerce B2B, check that route against your setup first.
What changes about how your team works
Feature lists describe what's available. These are the five operational changes people are unprepared for.
- 1
Adobe decides when you upgrade
Multi-tenant and versionless, so the release schedule isn't yours. What you no longer have is the option to defer.
- 2
Your customisation lives outside the store
An App Builder app reacting to events and calling back over APIs, instead of a PHP module. Different skills, debugging and deployment.
- 3
The extension surface is a published list
Events and webhooks come from a list Adobe maintains and extends release by release. If the hook you need isn't on it, it isn't there yet.
- 4
Your storefront is a separate build
Headless, with merchandising data behind GraphQL. Content teams gain independence, developers lose the theme.
- 5
Configuration is retyped, not migrated
Recreated by hand in the new admin. For one store view that's an afternoon. For thirty across six countries it's a workstream.
Versionless SaaS needs automated testing
The question almost nobody asks: can your team verify the store every time Adobe ships?
Which means you need a regression suite
Automated coverage across checkout, payments, B2B flows, integrations and your App Builder apps, runnable in days.
Most merchants don't have one
Coverage is thin, and manual QA sufficed because releases were rare and scheduled.
Otherwise it becomes a QA tax
A monthly evaluation cadence with manual testing is how a no-more-upgrades promise turns into permanent overhead.
30 days
to evaluate each release in a sandbox. Only worth something if you can actually verify your store in it.
Application monitoring stops being yours
A quieter change with real operational consequences. Adobe's own SaaS-versus-PaaS comparison spells it out.
On PaaS, you profile the application
Transaction traces, slow queries and background jobs. The profiling that tells you which plugin costs 340ms on every category render.
On ACCS, Adobe manages the platform
A New Relic licence is not included. Observability shifts to OpenTelemetry for your App Builder apps and real-user dashboards for the storefront.
Gained
No infrastructure problems
Sizing, scaling and platform incidents stop being yours to diagnose at all.
Lost
Visibility into application internals
The engine isn't yours to profile. You debug with what Adobe exposes.
Changed
Where the data goes
Your New Relic sees API Mesh and App Builder, not the application.
If your team diagnoses performance by reading traces, that muscle needs rebuilding around a different toolset. A planning item rather than a surprise.
Hyvä, Hyvä Edge and Edge Delivery Services, untangled
Three things get conflated, and the difference decides whether your storefront survives.
Hyvä on Adobe Commerce, in production
Lichtkoning's Hyvä storefront passes Core Web Vitals on mobile. That's the path that survives on PaaS, not the one that moves to ACCS.
Hyvä on Adobe Commerce
Renders server-side inside the Magento application. Fast, mature, with 1,000+ compatible extensions.
Survives on PaaS
Hyvä Edge
EDS publishes content through AEM, Hyvä renders commerce pages. Shared styling and a shared cart.
Requires AEM
Commerce Storefront, on ACCS
Adobe's own headless EDS storefront, built from Adobe-maintained components over GraphQL.
No theme, no application
So "Hyvä works with Edge Delivery Services" is true, and "Hyvä works on ACCS" is not. If someone tells you your Hyvä storefront carries across, ask which of the three they mean.
What isn't a reason to move
Four arguments we hear regularly that don't survive checking.
The claim
What we hear
- Adobe is forcing us
- We need to be ready for agentic commerce
- It'll be cheaper
- Our catalog is big, so SaaS will scale better
What's actually true
Once you check
- No. What has a deadline is your version, not Cloud.
- Agentic support is coming to Cloud and ACCS alike.
- Rarely. Moving can cost more than years of upgrades.
- Check the ingestion limit before the performance one.
Each row is the claim → what's actually true
The claimAdobe is forcing us
What's actually trueNo. What has a deadline is your version, not Cloud.
The claimWe need to be ready for agentic commerce
What's actually trueAgentic support is coming to Cloud and ACCS alike.
The claimIt'll be cheaper
What's actually trueRarely. Moving can cost more than years of upgrades.
The claimOur catalog is big, so SaaS will scale better
What's actually trueCheck the ingestion limit before the performance one.
The one that holds up
You want engineering time going into merchandising, content and integrations rather than into the platform
That's an argument about how your team spends its week, and it survives checking.
Your version has a deadline. The platform doesn't
Adobe has published no end date for Adobe Commerce on Cloud. Individual versions do have one, and from 1 June 2027 Adobe stops maintaining Cloud environments running unsupported versions.
Version
Cloud enforcement
Standard support ends
Extended support ends
2.4.4
1 Jun 2027
Apr 2025
Apr 2026
2.4.5
1 Jun 2027
Aug 2025
Aug 2026
2.4.6
1 Jun 2028
Aug 2026
Aug 2027
2.4.7
1 Jun 2028
May 2027
May 2028
2.4.8
TBD
May 2028
TBD
2.4.9
TBD
May 2029
TBD
On 2.4.4 or 2.4.5
Your question is an upgrade, not a replatform. Get supported, then decide about SaaS.
On 2.4.6 or later
You have until 2028 before enforcement. Enough runway to prepare, not choose under pressure.
Get SaaS-ready without committing to SaaS
Almost everything expensive about an ACCS migration is expensive because customisation lives inside the application. That's fixable gradually, on your current platform.
Each of these is worth doing on Adobe Commerce on Cloud on its own merits. Together they turn a future migration from a rebuild into a move.
Build new customisation out of process
New work goes into App Builder, not PHP. It runs on PaaS today and survives a move.
Move integrations behind APIs
ERP, PIM and 3PL as event-driven integrations. Better isolation now, portable later.
Retire modules you don't need
Every extension removed is one fewer verdict to make later, and most stacks carry several nobody would miss.
Build the regression suite now
It cuts release risk on your current platform now, and SaaS needs it later.
Consider Optimizer for the storefront
If speed and merchandising agility are the real drivers, the storefront can modernise without touching the backend.
Rebuilding modules with Adobe's own AI tooling
The expensive part of an ACCS migration is rebuilding in-application PHP as out-of-process App Builder applications. Adobe shipped tooling for exactly that.
Rebuild work can start during the decision phase, on the modules you already know you're keeping, rather than waiting for a signed migration plan.
Adobe's App Builder MCP server
Connects AI coding assistants to Commerce docs, APIs and App Builder patterns, right in the IDE.
Adobe's agent skills
Pre-built skills for REST APIs, checkout extensions, storefront components and events on ACCS.
The assessment feeds it directly
Each module carries a description written to be used as a prompt, so scaffolding starts early.
Which is how we work already
Agentic development under review, our own open-source Magento MCP module, four quality gates.
When ACCS does fit, here's what we build
We build App Builder applications today, including for extension vendors, so the platform is not new to us.
Edge Delivery storefrontBuilt for speed and for content teams to publish without a developer, with Baymard-grounded UX.
Custom logic on App BuilderOut-of-process applications reacting to commerce events and calling back over APIs.
Integrations through API MeshCommerce, ERP and PIM combined into a single graph the storefront queries once.
Data and reconciliationFirst-party data through Adobe's tooling, configuration rebuilt deliberately, with reconciliation reports.
SEO protected from the startACCS has no URL rewrite tooling and a rebuild means new URLs, so redirect mapping is planned before the build.- Reviewed against Adobe's modelAPI-first extensibility, so backward compatibility holds through Adobe's continuous releases.
What partners say about us
Their strategic approach helps us massively save on operational costs.
Kevin Hughes
European Technical Director
The team has been behind every one of our successes, and I recommend them without hesitation.
Bob Toeppner
E-commerce Manager
Within just two to three months, they resolved issues that previously seemed unresolvable.
Tim Johnson
CTO
Why ambitious brands choose Magebit
#1 Adobe Commerce partner worldwide
The top-ranked Adobe Commerce agency on the planet by Adobe themselves.
55+ Hyvä Certificates
The most certified Hyvä agency in the world. Confirmed by Hyvä themselves, twice.
Award-winning solutions
Innovator, World Traveler, and eCommerce Excellence awards across Meet Magento NYC and HIVE London, and more.
Hyvä Platinum Partner
The most-certified Hyvä agency worldwide and the first Hyvä Platinum Partner in the USA. 55+ certified developers and 40+ projects delivered.
ISO certified
ISO 9001 & 27001 for quality and security.
Scrum Alliance certified team
Truly agile team that moves and adapts faster than your typical agency.
Baymard certified design team
UX grounded in large-scale ecommerce research.
Magebit team at Meet Magento, #1 Adobe Commerce agency worldwide.
The world’s leading Magento agency
By certified developers, Magebit holds the number-one spot among Adobe Commerce agencies worldwide, and we’re the most certified Hyvä agency on the planet. Proof that the depth is real, not a logo on a page.
#1 Adobe agency worldwide
200+ Adobe certifications
Most certified Hyvä agency
Adobe Subject Matter Expert
Learn more
The honest answer is usually not yet
Most merchants asking about ACCS are really asking whether they're behind. Almost none of them are. Tell me your version, your SKU count and what your storefront cost, and I'll tell you which of the three paths fits, and what to do first either way.
Reviewed by Kristaps Rjabovs
Co-founder of Magebit, Forbes 30 Under 30
Frequently asked questions
If you can't find the answer you're looking for, feel free to reach out to us. We're here to help.
Adobe's multi-tenant, versionless SaaS edition of Adobe Commerce, generally available since June 2025. Adobe owns and hosts the application and updates it continuously, so nobody plans a version upgrade again. In exchange, PHP doesn't run inside the application, customisation happens out of process through App Builder, and the storefront is a separate build on Edge Delivery Services.
No. Adobe has publicly restated its commitment to the PaaS edition, with continued security and quality updates and new features on the published schedule. What carries a deadline is your version: from 1 June 2027 Adobe stops maintaining Cloud environments running unsupported versions.
A SaaS catalog, search, merchandising and Edge Delivery storefront layer that sits in front of your existing backend, with no replatform and no data migration. For merchants whose real drivers are storefront speed and merchandising agility, it's frequently the better-value answer. Worth checking against your setup if you run B2B, since the connector is currently oriented to B2C.
Not directly. No PHP runs inside the application, so in-application modules have no home. Some vendors have rebuilt extensions as App Builder applications, but that catalog is still small, so most stacks need individual verdicts and some capabilities get rebuilt or dropped.
Not on ACCS. Hyvä Edge does integrate Hyvä with Edge Delivery Services, but per Hyvä's documentation it requires Adobe Commerce and AEM, with EDS handling content pages while Hyvä renders commerce pages inside the application. ACCS has no application for that theme. If your Hyvä build is recent, weigh the write-off against the current support window.
In practice, yes. Updates arrive on Adobe's schedule with a 30-day sandbox window, and that window only helps if you can verify your store inside it repeatedly. Most Adobe Commerce merchants have thin coverage because releases used to be scheduled and rare. Building that suite belongs in the migration scope.
It changes hands. Adobe manages the platform and a New Relic licence isn't included, so observability moves to OpenTelemetry for your App Builder apps and real-user dashboards for the storefront. You can send API Mesh and App Builder data to your own account, but the application isn't yours to profile.
Yes, before anything else. It's an automated scan of your codebase that Adobe runs, needing no production access beyond sharing the code, and it returns a complexity score, a separate storefront score, and a rebuild-refactor-replace-remove verdict on every custom module. Request it through your solution account manager. It sizes the work; we then price it and run the module retirement pass that makes it smaller.
Not reliably, and cost is the weakest reason to move. The subscription consolidates platform, hosting and upgrade spend, but for a customised build the one-time cost of getting there commonly exceeds several years of upgrade spend.
Adobe Commerce (Magento 2) services
Explore the Magento services Magebit has to offer.
Find out which of the three paths fits
Your version, your SKU count, your extension stack and what your storefront cost. The assessment compares staying, adding Optimizer and moving to ACCS over three years, in numbers.
- 1
A certified specialist replies
Not a sales script.
- 2
Three paths, costed
With the assumptions visible.
- 3
No obligation
The assessment is yours to keep.