Adobe Commerce Deep Dive: Between Magento Flexibility, SaaS and New Commerce Architectures

1. Executive Snapshot: One Brand, Several Architectural Decisions

Adobe Commerce can no longer be described adequately as a single e-commerce platform offered through different hosting arrangements.

The name now covers several architectural models that differ fundamentally in how they operate, where customisation is possible and which components are responsible for core commercial processes.

The traditional Adobe Commerce architecture, inherited from Magento, allows extensive modification of the commerce core. Businesses can shape their own business logic, data structures and integrations. This freedom can be particularly valuable when commercial processes do not fit comfortably into standardised workflows. It also brings substantial responsibility for development, operations, security and ongoing maintenance.

Adobe Commerce as a Cloud Service takes a different approach. Adobe operates and continuously updates the commerce core, while individual functionality is implemented through supported APIs, events and external applications. Technical responsibility does not disappear. Some of it moves from the platform itself into integrations and supporting services.

Adobe Commerce Optimizer introduces a third approach. Retailers can modernise product presentation, search and merchandising while retaining an existing Adobe Commerce installation or another platform to handle transactions.

These options differ in more than infrastructure. They determine where business logic runs, how data models can be extended and which dependencies arise when requirements change.

For commerce businesses, the decision has therefore become more nuanced.

An assessment of Adobe Commerce must begin by establishing which parts of the architecture require direct technical control, which can be standardised and what these choices mean for operations, integration and future change.

The Decision Profile at a Glance

Traditional Adobe Commerce models merit consideration where extensive custom business processes, existing PHP extensions or complex integrations require substantial technical control.

Adobe Commerce as a Cloud Service offers a distinct option for organisations seeking to reduce responsibility for the platform core, provided their requirements can be implemented economically through supported interfaces and external extension models.

Adobe Commerce Optimizer is relevant where product discovery, catalogue presentation and merchandising need to evolve without necessarily replacing the existing transactional commerce core.

All three approaches may be relevant to international B2C and B2B operations. Their suitability depends on different functional, technical and economic conditions.

The central distinction: Adobe Commerce offers different ways of balancing deep customisation with standardised platform operations. The question is not which model provides the greatest number of capabilities, but which distributes technical control, operational responsibility and adaptability most appropriately.

2. What Adobe Commerce Actually Means Today

Adobe Commerce has its roots in Magento, whose modular architecture became an influential technology for businesses with demanding e-commerce requirements.

Adobe acquired Magento in 2018. The commercial product subsequently became Adobe Commerce, while Magento Open Source continues as a separate open-source platform.

That history explains why many businesses still associate Adobe Commerce primarily with PHP, custom modules and extensive changes to the underlying application.

It is no longer a sufficient basis for architectural decisions.

Magento Open Source

Magento Open Source provides a self-managed commerce core with extensive extension capabilities.

Businesses are responsible for hosting, infrastructure, updates, security and the extensions they deploy.

The platform shares important technical foundations with traditional commercial Adobe Commerce implementations. The products are not, however, identical in functionality or licensing.

In particular, the advanced commercial B2B capabilities available with Adobe Commerce are not automatically included in Magento Open Source.

Adobe Commerce On-Premises and on Cloud Infrastructure

The traditional commercial deployment models are based on Commerce Foundation.

With Adobe Commerce on-premises, infrastructure is operated by the merchant or its hosting provider.

Adobe Commerce on Cloud Infrastructure provides an Adobe-hosted platform environment. It is a Platform-as-a-Service model rather than a fully managed SaaS offering.

Adobe is responsible for substantial parts of the hosting platform. Application code, custom extensions, configuration and application-level updates remain subject to a shared responsibility model involving the merchant and its implementation partners.

Both models support PHP-based extensions within the commerce core as well as external integrations.

Adobe Commerce as a Cloud Service

Adobe Commerce as a Cloud Service is a separate SaaS offering with an Adobe-managed transactional commerce core.

The platform is continuously updated. Merchants cannot alter its core through custom PHP modules.

Extensions are implemented through supported APIs, events, Adobe Developer App Builder and additional external services.

Adobe also uses the term Commerce Foundation in this context. That does not establish that the SaaS service has an identical internal implementation to the traditional deployment models.

The transactional Adobe Commerce variants fulfil comparable core commerce responsibilities, although their technical implementation and extension models differ.

Adobe Commerce Optimizer

Adobe Commerce Optimizer is not another hosting model for Commerce Foundation.

It is a SaaS offering for catalogue processing, product discovery and merchandising.

It can be combined with traditional Adobe Commerce installations or a transactional commerce platform from another vendor.

Shopping carts, checkout, customer accounts, orders and associated transactions remain the responsibility of that backend.

Optimizer can therefore complement an existing commerce architecture, but it does not independently replace the transactional core.

Architectural Models at a Glance

Adobe's current architectural guidance explicitly recommends starting with the question of which system should manage shopping carts, checkout, orders and other transactions.

Only then should businesses determine which storefront and merchandising services to introduce.

This sequence makes sense beyond Adobe's own product positioning.

The transactional core carries responsibility for essential parts of the customer promise, including binding prices, actual availability, order placement and connections to payment processing.

The meaningful distinction is therefore not simply between cloud and on-premises deployment. It concerns transactional ownership, the extension model and the role of complementary commerce services.

3. Traditional Magento Architecture: Freedom and Responsibility

The flexibility of traditional Magento and Adobe Commerce is more than a legacy selling point.

The architecture allows extensive changes to business logic and the underlying data model.

Developers can create modules, extend existing behaviour through plugins and observers, and connect individual services to the platform.

Dependency injection, service contracts, REST and GraphQL provide different mechanisms for extension and integration.

The underlying data model includes Entity-Attribute-Value structures. Indexing, search, caching and asynchronous processing support catalogue operations and transactional workloads.

The multi-website and multi-store architecture allows businesses to manage different brands, countries, websites and store views within a single installation.

These capabilities matter when commercial requirements cannot readily be accommodated within standardised processes.

When Customisation Has Commercial Value

A business with complex B2B pricing, unusual product configuration requirements or processes closely integrated with its ERP may benefit from the control offered by traditional Adobe Commerce.

The same applies to established commerce environments containing custom functionality developed over many years to support critical business processes.

Such customisations are not inherently technical debt.

They may represent deliberate investments that enable a differentiated commercial proposition or support requirements specific to the business.

Their value depends on reliability, documentation and the cost of maintaining and adapting them.

The question is whether the commercial benefit of this flexibility justifies the responsibility it creates.

The Cost of Deep Customisation

Difficulties arise when extensions depend heavily on internal implementation details.

A modification that reaches deep into order processing, pricing or catalogue logic may require considerably more work during an upgrade than a function integrated through supported APIs.

Dependencies between modules, third-party extensions and infrastructure components can add further complexity.

In long-running implementations, relatively modest business changes may eventually require disproportionate technical effort.

That does not necessarily indicate an inherent weakness in Magento. It may reflect the architecture of the particular implementation.

Maintainability depends heavily on engineering quality.

Disciplined extension development, automated testing and continuous technical improvement therefore matter as much as the platform's original feature set.

An Architecture That Continues to Evolve

Adobe continues to develop the traditional Commerce product line.

Adobe Commerce 2.4.9 was released on 12 May 2026. It supports PHP 8.5 and updated database, search and messaging technologies.

Documented changes include support for newer MariaDB versions, OpenSearch 3 and Apache ActiveMQ Artemis.

Regular support for the 2.4.9 release line is scheduled to continue until 31 May 2029.

Support arrangements for other release lines vary by version and support programme. Existing installations should therefore be assessed against their exact release and patch level.

This continuing development matters when considering the future of existing investments.

It does not support the assumption that Adobe has already abandoned its traditional architecture in favour of SaaS.

Nevertheless, improvements to the underlying platform do not remove the merchant's responsibility for custom extensions and their compatibility.

What Existing Merchants Should Examine First

For businesses already operating Adobe Commerce, the sensible starting point is an inventory of their customisations.

Which modifications still create commercial value? Which duplicate capabilities now available in the standard product? Which depend on internal implementation details? Which could be replaced or simplified through supported APIs and external services?

Operational performance deserves the same scrutiny.

How reliably are security updates and upgrades applied? Which failures recur? How dependent is the business on particular developers or implementation partners?

Only when those questions have been answered can an organisation judge whether an upgrade, targeted modernisation or more fundamental architectural change makes economic sense.

4. Adobe Commerce as a Cloud Service: A Different Extension Model

Adobe Commerce as a Cloud Service changes the technical relationship between the merchant and its commerce platform.

In traditional Adobe Commerce, an organisation can extend the application core using PHP components.

In the SaaS model, Adobe controls that core.

Individual requirements must be addressed through documented and supported extension mechanisms.

Adobe explicitly distinguishes between in-process and out-of-process extensibility.

That distinction matters more to the architecture than the location of the hosting infrastructure.

From Internal Modules to External Services

In-process extensions execute within the commerce application. They can interact with internal processes and data structures and directly influence business logic.

Out-of-process extensions operate outside the commerce core.

They communicate through defined APIs, events and integration mechanisms.

Adobe Developer App Builder provides a central development environment for this model. Adobe I/O Events, webhooks and other event mechanisms enable individual applications to be connected.

API Mesh supports the aggregation and extension of API access. Supported UI extension mechanisms also allow certain administrative interfaces to be adapted.

This approach establishes a clearer separation between platform functionality and custom development.

It also changes the conditions under which business logic operates.

A function previously implemented as a PHP module may become an independently deployed service with its own execution environment, data storage and monitoring requirements.

Not Every Customisation Transfers on Equal Terms

Adobe's current documentation identifies specific differences between traditional deployments and Cloud Service.

The PaaS model supports extensive changes to data structures, search indexes and administrative interfaces.

Cloud Service instead provides supported attribute extensions and external integration mechanisms.

Custom search index requirements may call for third-party solutions. Custom email types also face tighter restrictions than under the traditional architecture.

API extensibility follows a different model.

Traditional deployments allow native REST and GraphQL extensions, whereas Cloud Service relies on external services and mechanisms such as API Mesh for additional capabilities.

These differences do not mean that every requirement previously implemented within the core becomes impossible under SaaS.

They do mean that some capabilities must be redesigned, integrated differently or supported by additional services.

Feasibility and commercial consequences need to be assessed individually.

Data Storage and Persistent Business Objects

Traditional Adobe Commerce allows businesses to introduce their own database structures, file storage, caches and queues within the application environment.

Cloud Service takes a different approach.

Additional attributes can be created within the supported extension model. More extensive custom data structures may require external persistence.

As of October 2026, Adobe still describes Database Storage for App Builder as Early Access.

Long-term persistent storage may therefore require additional infrastructure and a separate operational responsibility.

This matters particularly for custom business objects, process histories, industry-specific data models and complex integration states.

Where information must be retained over long periods or processed under audit requirements, these needs should be reflected explicitly in the architecture.

Operational Relief and New Dependencies

Adobe operates and continuously updates essential Cloud Service platform components.

Merchants consequently have fewer infrastructure and core update responsibilities than under traditional deployments.

They do not, however, cease to be responsible for technical operations altogether.

External applications, custom integrations and additional data services still require monitoring, maintenance and security controls.

Continuous updates to the platform core also make the compatibility of custom applications with supported interfaces important.

Asynchronous processes deserve particular attention.

Events may be delayed or delivered more than once. Integration services may become temporarily unavailable. Critical business processes therefore require traceable states, appropriate retry mechanisms and controlled error handling.

Observability also differs between the models.

Traditional PaaS installations provide more direct access to application-level operational information, including facilities such as New Relic.

With Cloud Service, Adobe is responsible for more of the underlying platform monitoring. Other mechanisms, including OpenTelemetry and Real User Monitoring, support custom App Builder applications and storefronts.

The merchant no longer needs to control every technical detail of the commerce core.

It must still be able to explain why a critical process succeeded or failed across the complete commerce architecture.

Regional Availability and Compliance

Adobe describes Cloud Service as a globally available offering.

The availability of a particular production region must nevertheless be confirmed with Adobe.

A general statement of global availability does not establish unrestricted hosting choices or guaranteed EU data residency.

Compliance also requires a model-specific assessment.

Adobe identifies SOC 2, PCI, ISO and GDPR-related compliance information for Cloud Service. Its current comparison does not list HIPAA support as available.

For European retailers, the contractual arrangements, data processing responsibilities, actual data flows and any residency requirements remain decisive.

Migration Is Not Rehosting

Moving from traditional Adobe Commerce to Adobe Commerce as a Cloud Service is not equivalent to transferring an existing application to new hosting infrastructure.

Adobe's migration documentation explicitly distinguishes between applications, data, storefronts and integrations.

Existing PHP modules cannot simply be carried across unchanged.

Their purpose must be examined and their functionality, where necessary, reimplemented through standard features, supported APIs or external applications.

Adobe provides AI-assisted development tools, including Commerce Developer Agent and Commerce Developer MCP, which may support development and migration work.

Their capabilities and availability must be distinguished from commerce functions intended for end customers.

Development automation cannot replace decisions about business requirements, architectural validation, integration testing or acceptance.

Cloud Service reduces responsibility for the platform core. Responsibility for the accuracy and reliable operation of the complete commerce solution remains with the business.

For organisations with relatively standardised processes, this may offer commercial advantages.

For heavily customised environments, the cost of redesigning existing capabilities and the dependencies introduced by external services require careful examination.

5. Commerce Optimizer: Modernisation Without Replacing the Commerce Core

Modernising an e-commerce operation does not necessarily require replacing its transactional platform.

In established retail businesses, shopping carts, checkout, order processing and ERP integrations may work reliably while search, catalogue presentation or merchandising no longer meet commercial expectations.

Adobe Commerce Optimizer addresses precisely this separation.

The SaaS offering provides services for ingesting and processing product data, alongside search, recommendations and merchandising.

It can be connected to existing Adobe Commerce installations or a transactional commerce platform from another vendor.

An Additional Service, Not a New Transactional Core

When Optimizer is used, the existing backend remains responsible for transactions.

Product and pricing information is transferred to Optimizer, where it is prepared for discovery and merchandising.

The storefront can consume these services while shopping carts, checkout, customer accounts and orders remain connected to the transactional backend.

Adobe documents a dedicated Optimizer Connector for traditional Adobe Commerce installations.

It transfers catalogue, category and pricing information into Optimizer's data structures.

Adobe Commerce remains the source of record for the corresponding product and price information.

The connector maps existing websites, store views and customer groups to catalog sources, price books and other Optimizer structures.

This enables businesses to modernise product discovery while retaining their existing transactional architecture.

Connector Support and B2B Require Separate Consideration

The base connector is primarily designed to synchronise B2C catalogues from Adobe Commerce on Cloud Infrastructure or on-premises.

Adobe also documents a separate B2B connector capable of mapping shared catalogues and company associations to protected catalogue views.

This distinction matters for B2B merchants because product visibility and access permissions often depend on the customer organisation.

It does not mean that Optimizer takes responsibility for all B2B processes.

Quotations, purchasing approvals, shopping carts and checkout remain with their respective transactional systems.

Permissions must also be enforced consistently across the architecture.

Controlling which products a business customer can see is not the same as authorising that customer to place an order. Both controls must remain consistent across the integrated systems.

Integration with Third-Party Platforms

Commerce Optimizer can also work with a commerce core from another provider.

This requires the transfer of catalogue and pricing information, together with integrations for shopping carts and checkout.

Adobe documents, for example, an App Builder-based connector for Salesforce Commerce Cloud B2C.

This demonstrates that third-party integration does not always have to be developed entirely from scratch.

Such connectors are nevertheless designed for specific product variants and technical conditions.

A connector for Salesforce Commerce B2C does not establish automatic compatibility with other Salesforce Commerce products.

For other backends, available integration components, necessary custom development and ongoing maintenance must be assessed separately.

Data Consistency Remains an Operational Challenge

Adding a catalogue and merchandising service introduces another layer of data processing.

Prices, availability and product information change throughout daily trading.

If the storefront uses information supplied by Optimizer while checkout relies on the existing backend, responsibility for data freshness and binding transactional decisions must be clearly defined.

Customer-specific prices, time-limited promotions and constrained inventory can expose differences between displayed information and the conditions that apply when an order is placed.

The integration architecture must establish which data is synchronised, when values are checked again and how discrepancies are handled.

For some merchants, this will require the transactional system to reconfirm the final price immediately before an order is accepted.

Data-feed monitoring is equally important.

The Optimizer Connector provides facilities for reviewing synchronisation status. Organisations still need procedures for detecting and resolving failed or delayed transfers.

Capacity and Licensing Boundaries

Adobe distinguishes between licence-dependent Optimizer capacity allocations and fixed technical system limits.

Some capacities can be extended through additional packages or specific commercial arrangements.

Fixed system limits cannot simply be removed by purchasing a larger licence.

The documented base allocation includes, for example, 250,000 SKUs per catalog source. Additional limits apply to product updates, catalog variations, API requests and other dimensions.

These are not general performance limits for the Adobe Commerce portfolio.

They concern particular Optimizer configurations and must be assessed against the current product and commercial terms.

Catalogue depth, number of markets, price-book structures and frequency of data changes are particularly relevant to architectural planning.

Additional catalogue sources and storefronts may also affect the required capacity.

A substantial Optimizer implementation therefore calls for sizing that considers technical limits and licensing together.

A Distinct Modernisation Route

Commerce Optimizer creates an option between maintaining the existing solution unchanged and replacing the whole platform.

Its suitability depends on whether the main weaknesses genuinely concern discovery, catalogue presentation and merchandising.

Where the underlying problems involve inadequate order logic, unsustainable ERP integration or structural checkout limitations, an additional discovery layer will not resolve them.

There is also a product-level distinction within Adobe's own portfolio.

As of October 2026, Adobe still describes direct integration between Adobe Commerce as a Cloud Service and Commerce Optimizer as a roadmap item.

The two products should therefore not be assumed to form an already integrated SaaS architecture.

6. Commerce Capabilities and B2B: What Each Core Actually Provides

The transactional Adobe Commerce products offer a broad foundation for conventional e-commerce processes.

These include product catalogues, variants, configurable products, bundles, customer groups, pricing rules, promotions, shopping carts, checkout, payment integration and order management.

For international businesses, the ability to model multiple websites, stores and store views can be particularly relevant.

Implementation and extensibility nevertheless differ between the traditional and newer architectures.

A capability implemented through a PHP module in a traditional installation may require a different technical solution in Cloud Service.

B2B as an Important Adobe Commerce Capability

The commercial Adobe Commerce products provide numerous functions for B2B trading.

These include company accounts, user roles and permissions, customer-specific catalogues, quotations, purchase orders, approval rules and requisition lists.

They can provide a foundation for business customer portals and digital procurement processes.

In traditional Adobe Commerce installations, Adobe Commerce B2B is a separately licensed extension.

Adobe Commerce as a Cloud Service includes core B2B capabilities in its standard offering.

Adobe explicitly identifies company management and quoting among those capabilities.

Additional B2B storefront components were documented during 2026.

This does not establish that every specialised B2B function is equally available across traditional and SaaS architectures.

The precise support for purchase orders, multi-stage approvals, customer-specific pricing and unusual procurement workflows must be verified for the selected model.

The Difference Between a B2B Feature and a Procurement Process

A commerce platform may support purchase orders or quotations without covering every procurement rule used by a customer's organisation.

In complex businesses, budgets, purchasing permissions, cost centres, framework agreements and approval workflows are often managed outside the commerce platform.

The architecture must then ensure that orders and approvals remain consistent with the systems responsible for those rules.

Customer-specific pricing can also be considerably more complex than assigning a price list.

Prices may depend on contracts, volume tiers, delivery locations, currencies or individual commercial agreements.

Where the ERP determines the binding price, Adobe Commerce must integrate reliably with that source of authority.

B2B in Traditional and SaaS Architectures

Traditional Magento-based architecture allows extensive customisation of these processes.

Cloud Service uses a more standardised core with external extension mechanisms.

For merchants whose B2B requirements closely match documented standard functions, this may simplify the operating model.

Where procurement processes are heavily customised, the available data structures, APIs and events need to be examined against each essential business rule.

Particular attention should be paid to where binding decisions are enforced.

An external approval service must do more than influence the user interface if it is intended to prevent unauthorised orders.

Protected B2B catalogues, customer-specific prices and purchasing permissions must also operate consistently.

Magento Open Source does not automatically include Adobe's commercial B2B functionality. Equivalent requirements may need third-party extensions or custom development.

Adobe Commerce therefore has a well-documented B2B capability base. Suitability for a particular procurement model emerges only after examining functionality, permissions and integration together.

7. Unified Commerce: The Limits of Adobe Experience Cloud

Adobe Commerce can be combined with a broad range of products within the Adobe ecosystem.

Adobe Experience Manager supports content and experience management. Adobe Experience Manager Assets addresses digital asset management.

Adobe Analytics provides analytical capabilities. Adobe Experience Platform, Real-Time CDP, Journey Optimizer and Adobe Target may be relevant to customer data, audiences, personalisation and cross-channel communications.

This breadth matters to organisations viewing commerce as part of a wider digital customer architecture.

It says less about how reliably operational trading processes function across channels.

Customer Experience and Commerce Operations

A customer may interact with the same retailer through a website, mobile app, marketplace or physical shop.

A consistent experience requires more than aligned content and customer profiles.

Customers need reliable information about prices, availability, delivery options and order status.

They may expect to place an order online and collect it in a store, or return an online purchase through a physical location.

These processes depend on shared operational rules.

Adobe Commerce may be responsible for digital transactions. Point-of-sale systems, inventory management, enterprise resource planning and order orchestration frequently sit elsewhere.

Inventory and Reservations

A product may appear available online even though the remaining sellable quantity has already been reserved for other orders.

Such discrepancies do not necessarily indicate a weakness in the commerce platform itself.

They often arise from different inventory definitions, delayed synchronisation or insufficient coordination between ERP, POS, OMS and commerce systems.

Adobe Commerce includes inventory management capabilities and can incorporate inventory from different sources into its selling processes.

These functions should be distinguished from full cross-channel inventory and order orchestration.

For click and collect, a business must determine which system can reserve stock, when the reservation expires and where collection is confirmed.

Ship-from-store introduces further requirements.

Which store may fulfil an order? How is fulfilment capacity considered? How are inaccurate inventory records handled? What happens when the intended store cannot fulfil an already confirmed order?

These decisions require dependable coordination across operational systems.

Order Management Is Not the Same as Order Orchestration

Adobe Commerce provides functionality for managing orders and their status.

That does not establish the presence of complete cross-channel order orchestration.

An order management system may be responsible for routing, fulfilment decisions and processes spanning multiple channels.

The functions required depend on the retailer's operating model.

The former Adobe Commerce Order Management product has reached end of life and is no longer supported.

It should not therefore be included as a currently supported standard component in a new Adobe Commerce architecture.

Required capabilities must be provided through existing systems, other supported products or suitable integrations.

Experience Cloud Complements Rather Than Replaces Operational Ownership

Adobe Experience Cloud can connect content, customer information and interactions across digital touchpoints.

It does not automatically create a single operational authority for inventory, orders, returns and service.

An organisation must determine, for example, which system owns the authoritative customer identity and how that identity connects to commerce accounts, loyalty programmes and customer service.

It must also decide which source takes precedence when information conflicts.

Introducing a Customer Data Platform does not resolve these questions by itself.

Unified Commerce Is Also a Governance Responsibility

If commerce, ERP, stores and customer service use different definitions of availability, order status or customer identity, inconsistencies may persist even when their technical interfaces are functioning.

A dependable unified commerce architecture therefore requires clear ownership of master data, operational decisions and error handling.

Organisational accountability matters as well.

Who corrects inaccurate inventory? Who decides how failed reservations are handled? Which team owns a return involving more than one channel?

Adobe Commerce can form an important part of this architecture.

Responsibility for the complete trading model remains with the business.

8. Agentic Commerce: From Product Discovery to Delegated Purchasing

AI is changing how customers discover products, compare alternatives and prepare purchasing decisions.

Rather than navigating categories and filters alone, customers can describe their requirements in natural language.

AI assistants can use that information to suggest products, compare variants and support further interactions.

Commerce platforms consequently face an additional requirement.

Product information and commercial processes must be accessible not only to people, but increasingly to machine-based systems acting on their behalf.

Adobe is developing several technologies for this purpose.

Their roles, product associations and actual availability must be considered separately.

Current Product Discovery Capabilities

Adobe Brand Concierge supports AI-assisted product guidance and discovery.

Connections to commerce data can use documented Commerce MCP capabilities.

Adobe describes catalogue-related use cases, including product search, product details and comparisons.

These are relevant capabilities for a conversational product experience.

Adobe's current documentation also distinguishes their available scope from more extensive commerce actions.

Shopping-cart and checkout functionality is described as future development in the Brand Concierge context.

Product discovery should therefore not be mistaken for a complete executable purchasing process.

Commerce MCP and Conversational Checkout

Adobe presents a more extensive sequence in a separate Commerce MCP demonstration.

This includes product guidance, cart management and checkout within a conversation.

As of 28 October 2026, the relevant documentation page remains marked Coming Soon.

A demonstration can show how a technical workflow might operate.

It does not establish general product availability or prove support for every required integration, permission or payment process.

Four categories therefore need to remain distinct.

Documented current capabilities are functions Adobe describes as available for a defined product and use case.

Demonstrations and previews show possible or partially implemented workflows without establishing general production readiness.

Announcements and roadmaps describe intended development.

Custom implementations may extend the available possibilities, but their capabilities and operating responsibilities must not be presented as native standard features.

This distinction is particularly important because several Adobe products and developer tools use MCP-related terminology.

Commerce Developer Agent and Developer MCP

Commerce Developer Agent and Commerce Developer MCP address developers and technical architects.

They support work involving the development, analysis and potential migration of commerce extensions.

In the context of Adobe Commerce as a Cloud Service, such tools may help translate existing PHP customisations into external App Builder applications.

Adobe also demonstrates agent-assisted development workflows, whose complete maturity and availability require separate verification.

These are development capabilities.

An agent analysing source code or creating an integration service performs a fundamentally different role from a buying agent selecting products and placing orders.

Related AI technology or shared protocols do not make those applications equivalent.

MCP, UCP, ACP and AP2

Model Context Protocol, or MCP, enables AI applications to use structured tools and data sources.

An MCP server can provide controlled access to particular commerce capabilities.

Other protocols address additional aspects of agent-mediated commerce.

Universal Commerce Protocol and Agentic Commerce Protocol concern standardised interactions between commerce participants.

Agent Payments Protocol addresses authorisation and accountability in agent-mediated payments.

On 18 February 2026, Adobe publicly committed to supporting UCP and ACP, referring also to its previously announced support for AP2.

This is a relevant indication of strategic direction.

It does not demonstrate complete production implementation across every Adobe Commerce architecture.

A platform assessment would need to establish which protocol versions, actions, authentication mechanisms and payment workflows are actually supported.

It must also distinguish between technical access to a tool and authority to conduct a binding transaction.

The Full Purchasing Journey

An agent-assisted purchase will typically begin with product discovery, guidance and variant selection.

Cart preparation, binding price and stock checks, and delivery selection may follow.

Checkout introduces further requirements for customer confirmation and payment authorisation.

After the order, confirmation, amendments, cancellations, returns and potentially refunds become relevant.

These stages differ in both technical and legal significance.

An AI application authorised to research products is not necessarily authorised to enter into a contract on behalf of a customer.

Likewise, the ability to modify a shopping cart does not establish authority to approve payment.

A complete agentic purchasing process requires these capabilities to work together across several systems.

Identity, Authorisation and Governance

Several participants must be distinguished in an agentic commerce architecture.

They include the human customer, the customer's organisation where relevant, the external agent, its provider, the merchant, the commerce platform, and the payment and integration services involved.

An agent requires technical authentication.

Beyond that, the system must establish on whose behalf it acts and which authority has been delegated to it.

A customer might allow an agent to prepare a shopping cart while retaining final approval of the order.

A broader mandate might permit an agent to purchase independently within a defined budget.

That requires additional rules.

These may cover permitted product categories, maximum total prices, delivery locations, substitutions and recurring commitments.

Mandate revocation and the traceability of decisions already executed must also be considered.

B2B transactions introduce organisational budgets, roles, cost centres and approval workflows.

Such controls should be technically verifiable and enforceable.

Natural-language instructions to an AI model are not, by themselves, a sufficient foundation for binding authorisation limits.

API access does not constitute delegated authority to act on a customer's behalf.

The ability of a commerce platform to expose data or actions through interfaces does not demonstrate the existence of a complete delegation architecture.

What Adobe Can Demonstrably Support Today

At the research cut-off, Adobe documents several capabilities covering product discovery, AI-assisted development and the integration of commerce information into agent-based applications.

More extensive transactional workflows are partly demonstrated or announced as future developments.

The sources reviewed do not establish a generally available native architecture covering autonomous purchases under delegated customer mandates, including the full range of authorisation, payment and subsequent service processes.

That is not a statement of technical impossibility.

Custom implementations may provide additional capabilities.

They require their own assessment of identity, permissions, integration, operations, data protection and transactional security.

Implications for Existing Adobe Commerce Environments

For agentic commerce, the decisive issue is not simply whether Adobe offers a particular AI feature.

It is equally important whether product data, pricing, inventory, customer permissions and transactions can be exposed reliably through controlled interfaces.

An existing Adobe Commerce installation may provide a suitable foundation if its APIs and integrations support the required workflows.

External services may also extend capabilities without replacing the commerce core.

The emergence of agent-mediated purchasing is therefore not, in itself, sufficient justification for a platform migration.

It increases the importance of clearly defined system ownership, enforceable transaction rules and maintainable interfaces.

9. Commercial Viability: Total Cost of Ownership and Total Cost of Change

Adobe Commerce cannot be assessed economically through general statements about licence fees or implementation budgets.

The available architectures, existing systems and commercial requirements vary too widely.

A traditional Adobe Commerce installation with extensive PHP modifications has a different cost structure from a SaaS system supported by external integration services.

Likewise, the economics of a complete Cloud Service migration differ from those of adding Optimizer to an existing commerce backend.

The Cost of Traditional Architecture

Traditional installations incur expenditure on infrastructure, operations, security updates, upgrades and the maintenance of custom functionality.

Testing and modifications may also be required when third-party extensions or underlying technical components change.

The condition of the implementation is decisive.

A well-structured system with clearly separated extensions and automated tests can be less demanding to operate than an otherwise comparable installation with poorly coordinated customisation.

Architectural quality therefore matters more to the economic assessment than the platform's age alone.

The Cost of SaaS Architecture

Cloud Service transfers responsibility for operating the commerce core to Adobe.

Certain infrastructure and upgrade tasks may consequently be eliminated or substantially reduced for the merchant.

Additional expenditure may nevertheless arise from App Builder, API Mesh, external storage, monitoring and custom integration services.

Migrating existing functionality may also require substantial development effort.

Where a merchant currently relies on numerous PHP modifications, each needs to be assessed to determine whether it can be replaced by a standard capability or requires redevelopment.

The economic analysis must extend beyond the cost of the platform core.

It must include the complete commerce solution and every external component essential to trading operations.

The Cost of an Additional Optimizer Layer

Commerce Optimizer may enable targeted modernisation without a full platform replacement.

It introduces additional licensing, integration and potentially usage-related costs.

The existing commerce backend must still be operated and maintained.

At the same time, existing search, indexing and merchandising components may be simplified, relieved of certain tasks or replaced.

The relevant question is what additional commercial value Optimizer creates and which existing or future costs it can reduce.

Answering that requires a concrete target architecture and defensible assumptions.

Total Cost of Change

Alongside Total Cost of Ownership, businesses should consider another dimension.

Total Cost of Change describes the economic consequences of adapting a commerce architecture to changing business requirements, including the cost, complexity and risk of those changes.

Consider a change to customer-specific pricing.

In a traditional Adobe Commerce installation, the function might be implemented as a PHP extension closely connected to the commerce core.

Modifying it may require module changes, regression testing and an assessment of its effects on other extensions.

If the same business logic operates as an external service, the dependencies change.

The service may be developed independently, but it must communicate reliably with the relevant commerce APIs. Response times, availability, data consistency and error handling become more significant.

Neither approach can be declared cheaper over time simply by examining its extension model.

A second example is the introduction of a new B2B approval process.

If the requirements are largely covered by standard platform functionality, implementation effort may remain limited.

Where additional rules must be coordinated across ERP, procurement and organisational approval systems, substantial integration work may arise regardless of the platform model.

A third example is the addition of a new sales channel.

A well-separated commerce architecture may allow existing business logic to be reused through APIs.

Where essential processes are closely tied to one storefront, reuse becomes more difficult.

These examples show why ongoing operating costs are insufficient as the sole basis for architectural decisions.

The economic quality of an architecture is also revealed by how it accommodates change.

Different Modernisation Routes

Existing Adobe Commerce environments have several broad options.

Continuing with targeted improvements may be appropriate where the current architecture is stable and its customisations retain commercial value.

An upgrade within the traditional product line may reduce technical risk and maintain a supported release without changing the overall extension model.

A new storefront may improve the customer experience while leaving the existing commerce core in place.

Commerce Optimizer may provide additional product discovery and merchandising capabilities.

Migration to Adobe Commerce as a Cloud Service represents a more extensive architectural change, redistributing responsibility for operations and extensibility.

A complete move to another commerce platform remains another possibility.

These approaches are not interchangeable stages in a predetermined migration journey.

Each has different prerequisites, costs and technical risks.

The choice should follow an assessment of concrete business requirements and the existing system.

10. Structural Limits and Criteria for Platform Replacement

The question of replacing a commerce platform is often raised before the underlying problems have been properly identified.

A slow storefront, rising development costs or difficult integrations may indicate structural architectural limitations.

They may also result from implementation quality, insufficient technical governance or organisational problems.

These causes require separate consideration.

Missing Standard Feature or Genuine Platform Limitation

The absence of a standard feature initially means that a requirement cannot be met directly through the existing platform configuration.

It may still be addressed through a supported extension, API or external service.

An inadequate storefront does not automatically justify replacing the commerce core.

Where catalogue, pricing, checkout and order processing operate reliably, targeted storefront modernisation may offer a more proportionate response.

The same applies to discovery and merchandising requirements that can be addressed through an additional service layer.

Some architectural restrictions, however, cannot be removed through further development alone.

Limits of the Individual Adobe Architectures

In Adobe Commerce as a Cloud Service, the inability to modify the PHP core directly is a documented architectural restriction.

Whether this becomes a business problem depends on whether the required functionality can be delivered reliably through supported APIs, events and external services.

Restrictions on custom search index modifications and requirements for external data storage may also become relevant in specialised cases.

For Commerce Optimizer, the absence of a transactional commerce core is a clear product boundary.

It requires a suitable backend for shopping carts, checkout and orders.

It can address product discovery needs, but it cannot resolve every deficiency in an existing transactional architecture.

Traditional Adobe Commerce presents a different kind of boundary.

Its extensive customisation capabilities allow many requirements to be implemented.

A practical limit may emerge when the accumulated cost, dependencies or risks of necessary changes are no longer commercially sustainable.

Even then, replacing the entire platform is not the only option.

Separating selected functionality from the core may be more appropriate.

When Migration to Cloud Service Makes Sense

Migration to Cloud Service merits consideration where reducing responsibility for the commerce core offers commercial value and essential business processes can be supported through the available SaaS capabilities.

Existing customisations, integrations, data models and storefront requirements must be assessed individually.

The implications for data quality, security, monitoring and organisational accountability also matter.

An organisation must examine not only the target architecture but the transition towards it.

Existing customer and order processes must continue operating throughout the migration.

Data movement, integrations and custom functionality therefore need a controlled transition architecture and clear acceptance criteria.

When Full Platform Replacement Is Justified

A move to another commerce platform may be warranted when essential business requirements can no longer be met adequately within the existing architecture.

It is not sufficient to observe that another platform includes a particular feature as standard.

The assessment must establish whether the current environment remains viable through economically reasonable extensions or modernisation.

Replacement may also make sense where the long-term costs and risks of the existing architecture have become disproportionate to its commercial value.

Relevant factors include technical dependencies, maintainability, integration risk and the availability of internal expertise.

The cost and risk of migration itself must form part of the decision.

Establish Requirements Before Choosing the Architecture

A sound decision begins with the business requirements that genuinely matter.

The next step is to examine the existing system and identify the causes of its problems.

Only when technical, organisational and economic constraints are understood can suitable modernisation routes be compared.

This discipline is particularly important for Adobe Commerce because several different architectural choices exist within Adobe's own portfolio.

A merchant does not have to choose simply between preserving everything as it stands and replacing the whole platform.

Individual components can be modernised, custom functionality separated from the core, or the operating model changed.

The appropriate decision follows from business requirements and commercial sustainability, not a general verdict on a particular generation of technology.

11. Management Conclusion: Choosing the Right Form of Technical Control

Adobe Commerce now represents different approaches to flexibility.

Traditional Magento architecture permits extensive changes to business logic, data structures and technical processes.

That freedom can be valuable in complex trading models. It also requires sustained expertise in development, security, operations and modernisation.

Adobe Commerce as a Cloud Service takes a more standardised approach.

Adobe assumes responsibility for the platform core while individual functions are implemented through defined interfaces and external services.

Some operational tasks may be reduced or removed. The nature of technical dependencies changes at the same time.

Adobe Commerce Optimizer provides another modernisation route, allowing product discovery and merchandising to evolve without necessarily replacing the transactional commerce core.

For unified commerce, the central question remains how reliably Adobe Commerce works with ERP, OMS, POS, inventory management and customer service.

An extensive Experience Cloud portfolio is no substitute for clear operational accountability.

Agentic commerce raises expectations concerning data access, interfaces, identity and authorisation.

Adobe's currently documented capabilities provide different technical foundations, but do not yet establish a generally available architecture for autonomous purchasing under fully delegated customer mandates.

None of these developments establishes that traditional Adobe Commerce installations are obsolete or that SaaS will necessarily prove more economical.

The decisive question is where a commerce business requires technical control, where standardisation makes sense and which architecture can sustain that balance economically over time.

An assessment of Adobe Commerce should therefore go beyond features and licensing models.

It must establish which systems own the business processes, how existing customisations can evolve and what future changes are likely to cost.

Only then is there a sound basis for deciding whether to continue, modernise, migrate or replace the platform.

---

Sources and Methodology

Research cut-off: 28 October 2026

This analysis draws on publicly available technical documentation, product information and release notes published by Adobe, together with an independent professional assessment of the architectural and operational consequences.

Vendor-documented product availability is distinguished from suitability within a particular implementation.

Conclusions regarding operating costs, integration complexity and future change requirements are derived from the documented architectural models. They are not independently measured comparative benchmarks.

No general implementation budgets, project durations or performance comparisons are presented where sufficiently reliable and comparable independent evidence is unavailable.

The principal primary sources are as follows.

Product Identity and Architecture

1. Adobe Experience League. Choose a Commerce Option. Product variants, transactional ownership and integration boundaries. Updated October 2026.
https://experienceleague.adobe.com/en/docs/commerce/information-center/explore-platforms-and-services/choose-commerce-option

2. Adobe Experience League. Adobe Commerce Platforms and Services. Traditional, SaaS and Optimizer product distinctions.
https://experienceleague.adobe.com/en/docs/commerce/information-center/explore-platforms-and-services/platform-and-services

3. Adobe Experience League. Adobe Commerce SaaS vs. PaaS Feature Comparison. Extension models, data storage, operating responsibilities and functional differences. Updated 20 October 2026.
https://experienceleague.adobe.com/en/docs/commerce/cloud-service/feature-comparison

Releases and Support

4. Adobe Experience League. Released Versions. Product releases and support periods.
https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions

5. Adobe Experience League. Adobe Commerce 2.4.9 Release Notes. Development of the traditional Adobe Commerce architecture.
https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9

Migration and Extensibility

6. Adobe Experience League. Migrate to Adobe Commerce as a Cloud Service. Applications, data, storefronts and integrations.
https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview

Commerce Optimizer

7. Adobe Experience League. Adobe Commerce Optimizer Connector. Synchronisation, system ownership and supported use cases.
https://experienceleague.adobe.com/en/docs/commerce/aco-optimizer-connector/overview

8. Adobe Experience League. Adobe Commerce Optimizer Limits and Boundaries. Licence-dependent capacities and technical limits. Updated 21 October 2026.
https://experienceleague.adobe.com/en/docs/commerce/optimizer/boundaries-limits

9. Adobe Experience League. Salesforce Commerce Connector for Adobe Commerce Optimizer. Third-party integration and limitations.
https://experienceleague.adobe.com/en/docs/commerce/optimizer/developer/salesforce-connector

Unified Commerce

10. Adobe Experience League. Implementation Playbook Glossary. End-of-life status of the former Adobe Commerce Order Management product.
https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/glossary

Agentic Commerce

11. Adobe Experience League. Commerce MCP Overview. Conversational commerce capabilities and documented development status. Updated 8 October 2026.
https://experienceleague.adobe.com/en/docs/commerce-learn/ai-and-agentic-commerce/commerce-mcp/commerce-mcp-overview

12. Adobe Experience League. Brand Concierge Documentation. Product discovery, commerce integration and documented functional scope.
https://experienceleague.adobe.com/en/docs/brand-concierge/content/documentation/concierge-management/concierge-management

13. Adobe Business Blog. Adobe Commerce Commits to Agentic Commerce Standards. Official positioning on UCP, ACP and AP2, published 18 February 2026.
https://business.adobe.com/blog/adobe-commerce-commits-to-agentic-commerce-standards

These sources reflect the product status publicly documented at the research cut-off.

Product capabilities, roadmaps, licensing conditions and regional availability may change.

Any specific architectural or platform decision therefore requires confirmation of the current technical, organisational and contractual conditions.

---

About the Author

Andreas Rieger is an independent e-commerce advisor with more than 20 years of experience in digital commerce models, platform architecture and the development of complex commerce organisations.

He advises businesses independently of vendors on evaluating existing system environments and selecting suitable e-commerce platforms through a structured decision process.

Further information about independent platform selection and architecture advisory.