Adobe Commerce as a Cloud Service Migration

Adobe's fully managed, multi-tenant SaaS edition of Adobe Commerce. Adobe runs the application, the infrastructure and the updates. Catalog Service, Live Search and Product Recommendations are installed and configured automatically, core B2B features such as company management and quoting are included by default, and the storefront is Commerce Storefront on Edge Delivery Services. Customisation happens outside the core, through App Builder, API Mesh, events and webhooks.

Adobe Commerce on cloud infrastructure is a single-tenant platform as a service: Adobe hosts it, but your team maintains the application code, applies the upgrades and the patches, and customises it in process with PHP. The cloud service is multi-tenant, versionless and upgraded by Adobe, and it accepts out-of-process customisation only. Same product family, a different platform.

No. An upgrade moves the same code to a newer version. This move changes the platform: the core is closed, so every in-process customisation is rebuilt as an App Builder application or retired, the data is migrated by Adobe's migration service, and the storefront is rebuilt. Adobe's own guide treats it as a four-phase migration, and so do we.

They are not carried over as they are. Each one is assessed and then rebuilt as an out-of-process App Builder application on events, webhooks and API Mesh, kept as a native feature if the cloud service now covers it, or retired with the reason written down. Marketplace PHP extensions belong to the current editions; on the cloud service the equivalent is an App Builder app.

No. Adobe states that the cloud service does not support Luma storefronts. The storefront is rebuilt on Commerce Storefront, powered by Edge Delivery Services, with Storefront Builder for visual editing. For a PWA Studio or other headless storefront we read Adobe's current transition guidance for your setup at the assessment, and the plan says what carries over and what is rebuilt.

First-party core commerce data: catalogs, orders, customers and configuration, moved by the Commerce Data Migration Service, which extracts, loads, verifies and reports. Data in custom or third-party tables is not migrated automatically and needs a solution of its own, which the assessment identifies before the project is scoped.

Most of the work happens while the store trades: the assessment, the rebuild of customisations, the storefront and the sandbox loads. Adobe's guide is plain that the data-moving stages of the cutover need a maintenance window, so we plan one, verify against the baseline taken beforehand and keep the old environment ready as the rollback.

It depends on what the assessment finds. A lightly customised store with a standard storefront is a matter of weeks; a store with years of custom PHP, several integrations and a bespoke theme runs to months, because each customisation is rebuilt rather than copied. The roadmap from the assessment gives you the timeline for your store rather than an average.

Individually, after the assessment, once we know how many customisations rebuild, how many retire, which integrations move and what the storefront needs. There is no price list on this site because no two implementations arrive in the same state. Adobe's licence for the cloud service is agreed between you and Adobe.

Yes. Adobe includes core B2B features such as company management and quoting by default, where the current editions need a separately licensed B2B extension. Industry-specific B2B behaviour may still need work in App Builder, and the assessment says where.

Adobe's own comparison is candid. The data model takes custom attributes rather than full customisation, search customisation needs a third-party solution, emails use the standard templates, custom data storage is limited to the App Builder state library, admin customisation runs through App Builder only, and HIPAA is not currently available. Adobe updates that list as the product grows, and we check it against your requirements at the assessment.

No. Adobe Commerce Optimizer is a separate SaaS solution for storefront, catalog and product discovery that works over an existing Adobe Commerce or third-party backend, and Adobe lists it among the companion solutions beside a full migration. Adobe also states that the two do not currently integrate with each other, so the assessment treats them as separate options.

Not if the storefront rebuild is planned for it. Every URL is mapped before cutover, redirects and structured data are checked on the new storefront, and rankings and revenue are watched for the weeks after. A rebuilt storefront is the largest SEO event in this project, so it gets its own checklist.

Yes. We re-run the assessment against what exists, read the apps and the storefront that were built, and give you a plan from where the project actually stands. If the store is live and in trouble meanwhile, the Magento project rescue page describes how we stabilise it first.