Adobe Commerce vs CWS Platform: Who Upgrades When Versions Hit EOL?

Editorial note: an architecture comparison between Adobe Commerce and CWS Platform, written for those who answer as CTO. Every fact about Adobe Commerce comes from its public documentation, with the address next to it.

Every commerce platform has a version calendar, and the CTO is the one who answers for it. The question of this comparison is not which platform has more features, but what happens to the operation when the version in production reaches the end of support: who updates, what needs to be redone, and by when.

Adobe Commerce and CWS Platform treat this point in different ways. In one, the customer follows a published lifecycle, with versions that enter and leave support. In the other, all customers run the same version. Each design calls for a type of team and of budget.

What Adobe Commerce solves well

The Adobe Commerce architecture structures corporate commerce on a consolidated model of company accounts. Under this modeling, multiple buyers are organized under the same company account, allowing administrators to create divisions and subdivisions and to define roles with specific controls for orders, quotes, and purchases, as documented by Adobe Experience League. This separation provides native organizational governance for portals that mirror complex hierarchical structures of corporate customers.

Extensibility for decoupled scenarios relies on standardized layers. In the cloud services model, the storefront connects to the back-end services through GraphQL, while integrations with external software and legacy systems use REST APIs, as detailed in Adobe's development documentation. In addition, composable modular solutions have API Mesh to aggregate endpoints into a common graph and App Builder to create microservices in a serverless environment, according to Adobe's composable view.

In the context of multiple sales channels in the same technical installation, the platform organizes the infrastructure in the sequence of scopes global, website, store, and store view. This model enables the separation of domains, currencies, and languages, allowing catalogs and checkouts to be shared or segregated according to the specifications of Adobe's multi-site architecture.

Where the architecture diverges

The divergence that weighs on maintenance is the version lifecycle and what it asks of the customer's team.

Adobe's own documentation records two points of this cycle:

• limitation recorded in the vendor's documentation on September 18, 2026: the security-only transitional period for versions 2.4.4, 2.4.5, and 2.4.6 is a one-time exception and will not be extended beyond the published dates ("The security-only transitional period is a one-time exception.", https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy).
• limitation declared by the vendor, recorded in its release notes on August 12, 2026: starting with version 2.4.9, PHP 8.2 and 8.3 are no longer supported ("PHP 8.2 and PHP 8.3 are no longer supported.", https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9).

On CWS Platform, all customers run the same version of the platform, and there is no framework change or upgrade project on the customer side. Commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace), on the principle of configuration over code, and the portal is assembled without code, on a single parameterized template.

The technical decision is how much of the engineering calendar the company accepts dedicating to following the platform's version cycle.

What changes in the operation, through the CTO lens

Through the CTO lens, a lifecycle with dates becomes a fixed item in the planning. Each version that goes out of support opens a project: evaluating the target version, checking the compatibility of extensions and dependencies, testing, and publishing. The more customization the operation carries, the larger this project.

Three questions help size the work with any vendor: until when the version in production receives fixes; which dependencies change in the next version; and who carries out the update, the customer's team or the vendor's.

On CWS Platform, what the customer's team maintains are integrations and parameters. The platform integrates with the ERP and the other systems through REST APIs and webhooks. Price tables, rules, and contracts are configured on the platform or received from the ERP, the CRM, or another system through an API, and tax per item comes from the customer's ERP tax API. Moving from the v1 pricing model to v2 requires only validation by the customer, with no project on the customer's side.

Where the pains of this scenario come from, and how the architecture resolves them:

When to choose Adobe Commerce

Choosing Adobe Commerce is technically recommended in corporate scenarios whose infrastructure and customer governance requirements demand the following native capabilities:

Complex corporate hierarchy managed by the customer itself. Choose this architecture when the B2B operation requires the buyer company to manage its own structure of users, organizational subdivisions, and purchasing permission matrices autonomously. Adobe Commerce delivers this control natively in the B2B module through configurable company accounts, as documented by Adobe Experience League.

Composable ecosystem with API Mesh and serverless microservices. Choose this architecture when engineering governance has as a premise orchestrating multiple headless services from various vendors under a single unified GraphQL graph. Adobe Commerce enables this composition with the integrated API Mesh and the execution of serverless extensions in App Builder, as presented in the Composable Commerce documentation.

Global multi-domain operation under the same technical instance. Choose this architecture when the business demands multiple sites with independent currencies, languages, and storefronts governed in a technical hierarchy of websites, stores, and store views. This model is consolidated in the structure of Adobe Commerce and allows regional consumption experiences to be segregated while keeping a centralized panel, according to Adobe's multi-site guide.

When CWS Platform is the right choice in this scenario

CWS Platform is the suitable choice when engineering wants to take version tracking off the calendar and concentrate effort on integration and business rules.

One version for all customers. Choose this architecture when the team does not want to plan an upgrade project at each end of support. All customers run the same version of the platform, and there is no framework change on the customer side.

Commercial policy in parameters. Choose this architecture when price, approval levels, and credit change frequently. The rules sit in the Commerce Rules Engine (CDL Workspace), and the seller's discount goes through approval levels.

A portal with no code of your own to maintain. Choose this architecture when the B2B portal needs to be assembled and changed without front-end development. The portal is parameterized on a single template, and customer and seller use the same interface.

Integration by API with the ERP. Choose this architecture when the ERP remains the system of record. The platform integrates through REST APIs and webhooks, and the tax calculation per item is done by the customer's ERP tax API.

Where to go from here

If your question is still which architecture fits your operation, and not which vendor to choose, the path is the seven questions that separate B2B commerce architectures.

If what is blocking you today is the pain behind this scenario, the pages When the Catalog Becomes Chaos and When Integration Blocks Everything cover it in depth, without talking about any vendor.