The three destinations, as Adobe describes them
Adobe's feature comparison, updated 11 September 2026, sets Adobe Commerce as a Cloud Service, which is multi-tenant, beside Adobe Commerce on Cloud, which is single-tenant: the PaaS edition supports in-process PHP customization and Marketplace extensions and requires manual upgrades at six patch releases and one minor release a year; the SaaS edition is out-of-process only, through APIs, events, and App Builder, and is upgraded automatically through a versionless model. The self-managed license is the third destination: the same application as the PaaS edition, with the merchant or a host supplying everything Adobe's cloud would.
Self-hosted to Adobe Commerce on cloud infrastructure
What the store gains, per Adobe's Fastly and Pro architecture pages: a Varnish-based CDN with WAF on Production, DDoS protection, image optimization, and TLS certificates at no additional cost; a three-node Galera cluster behind an Elastic Load Balancer; GlusterFS shared storage; and the ece-tools pipeline for build and deploy. What changes in the code: hooks move into .magento.app.yaml, and the IDs in a fresh Pro database advance in threes. What the merchant gives up is the infrastructure decision itself, which is the point of the move for most.
On this site, scandiweb's BUFF case is the one published move in this direction with a number, from Magento Open Source to Adobe Commerce on cloud infrastructure at 44 stores in 59 countries with more than 120K redirects. Williams Commerce names a checkout project on Adobe Commerce Cloud for Haigh's Chocolates without a figure. The other five publish nothing on this direction.
Adobe Commerce on cloud infrastructure to self-hosted
What the store gives up is the four Adobe-supplied parts, and each has to be rebuilt before cutover. Fastly, with its custom VCL that Adobe documents as Varnish 2.1 compliant, becomes a self-run Varnish, a replacement WAF, a replacement image pipeline, and new TLS termination. The ece-tools pipeline becomes whatever the new host or the merchant's team builds. The Galera cluster becomes a single-writer database, and IDs stop advancing in threes. GlusterFS becomes local disk or Amazon S3 through the Remote Storage module, which Adobe documents for 2.4.2 and later, with the warning that its sync command moves pub/media and not var.
What the store gains is a hosting bill and a license as separate lines, and a host it chooses. Sonassi and MGT Commerce each publish a free managed migration onto hosting they run, Sonassi as a Magento-only host that states it stopped building stores in 2015 and no longer offers proactive development services, and MGT Commerce on AWS with printed monthly prices. Neither publishes a named store that made this move, and neither page says which of the four parts its migration covers. scandiweb publishes no exit case, and this site, which scandiweb publishes, says so plainly.
Either edition to Adobe Commerce as a Cloud Service
What the store gains, per Adobe's overview: automatic updates with a 30-day sandbox window before they reach production, a storefront powered by Edge Delivery Services, and App Builder extensibility. What it gives up, per the same pages: the Luma storefront, which Adobe states is not supported; in-process PHP customization and Marketplace extensions, which the feature comparison lists for the PaaS edition only; and any custom or third-party data entity, which Adobe's migration page states its data migration service does not handle and which needs an App Builder customization instead.
For a store with a Luma theme and a shelf of PHP extensions, that is a rebuild with a data migration attached, and the size of the rebuild is what Adobe's assessment exists to estimate. No agency on this site publishes a completed move in this direction. scandiweb and Snowdog publish the Hyvä practice that a storefront rebuild draws on, and scandiweb's Läderach and Gear-Up cases carry Hyvä outcomes, though on the PaaS and self-hosted editions rather than the SaaS one.
The version table applies to two of the three
Adobe's lifecycle page, updated 18 September 2026, gives regular support ends of 31 May 2027 for 2.4.7, 31 May 2028 for 2.4.8, and 31 May 2029 for 2.4.9, with 2.4.6 past regular support since 11 August 2026 and 2.4.4 and 2.4.5 past extended support and inside a security-only period that ends 31 May 2027. Those dates govern the self-hosted and PaaS editions, where the merchant upgrades. They do not govern the SaaS edition, which Adobe upgrades. A merchant choosing a destination is also choosing whether the version table is their problem.
One table
| Direction | Gains, per Adobe | Gives up, per Adobe | Evidenced on this site by |
|---|---|---|---|
| Self-hosted to cloud infrastructure | Fastly, WAF, Galera, GlusterFS, ece-tools, platform operations | The infrastructure decision; IDs in threes; hooks in .magento.app.yaml | scandiweb (BUFF) |
| Cloud infrastructure to self-hosted | Separate hosting and license lines, a chosen host | The four Adobe-supplied parts, each rebuilt before cutover | Sonassi and MGT Commerce publish the hosting leg; no named exit case |
| Either to Adobe Commerce as a Cloud Service | Automatic updates, Edge Delivery Services storefront, App Builder | Luma, in-process PHP, Marketplace extensions, custom and third-party data entities | Nobody publishes a completed move; scandiweb and Snowdog publish the Hyvä practice |