Optimizely Configured Commerce vs. CWS Platform: what is the total cost over three years?

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

A distributor's CFO rarely loses sleep over the entry price of a commerce platform. What keeps the CFO up is year three: the software line that grew without anyone deciding it should, the upgrade that turned into a project, the partner billing hours again to keep the portal on a supported version. The number that matters is not the first contract's subscription, it is three years of license, upgrades, and ongoing maintenance added together.

Two variables drive much of that total. The first is how the software price is put together: a public price list, a known billing rule, or a plan negotiated deal by deal. The second is how the platform evolves: whether each customer lives on its own version, with support windows that expire, or whether every customer runs the same version.

This comparison looks at Optimizely Configured Commerce and CWS Platform through those two variables only. The commercial rules question is covered in the comparison on changing pricing rules without opening a ticket, and the context of platform models is in the three B2B commerce platform models. The subject here is the budget.

57s

What Optimizely Configured Commerce does well

Optimizely Configured Commerce ships with ready-made B2B features, which reduces what has to be built in year one. For distributors running ERPs common in the industry, there are prebuilt connectors for SX.e, Prophet 21, Infor A+, Acumatica, and FACTS, which generate jobs automatically when activated in the Admin Console. Data exchange with the ERP goes through the Windows Integration Service, an agent installed in the customer's environment that runs the integration jobs in batch or on demand.

For buyers, Quick Order and order upload by file shorten reordering, and PunchOut over cXML opens the catalog with negotiated prices from the customer's own procurement system. For a distributor that wants a complete B2B portal out of the box, with existing connectors for the ERP it runs, the package covers a lot of ground and avoids part of the build cost.

Where the architecture diverges

The divergence that weighs on the budget sits in two things the vendor's own documentation records: how the plan is put together, and how long a version receives fixes.

• limitation recorded in the vendor's documentation, accessed on October 16, 2026: every Optimizely plan is individually packaged ("Every Optimizely plan is individually packaged.", https://www.optimizely.com/plans).
• limitation recorded in the vendor's documentation, accessed on October 16, 2026: LTS branches receive hotfixes during their four-month life, and hotfixes end the week before the next LTS branch release ("LTS branches do receive hotfixes for their four-month life, and the hotfixes end the week before a new LTS branch release.", https://docs.optimizely.com/configured-commerce/docs/long-term-support-and-short-term-support-branches).

For the CFO, the first point means the software price does not come from a public price list: it is the outcome of a negotiation, and the three-year projection depends on what was packaged and how that package behaves when the business grows or changes scope. The second point puts a clock on maintenance. If fixes for a long-term support version end the week before the next version, staying covered by fixes means keeping pace with that cycle, and every version move carries testing cost and work from the internal team or the partner.

Neither point is a hidden flaw. They are choices of commercial model and product cycle, and finance's job is to put them in the spreadsheet before signing, not after.

On CWS Platform, billing is a platform license plus an integration license, with no percentage of sales or GMV. And every customer runs the same version: there is no customer-specific version to keep up with.

The financial decision is to ask for both answers in writing, for three years, before comparing proposals.

What changes in operations, through the CFO lens

The difference shows up in two budget lines that usually sit outside the initial proposal: the cost of moving between versions, and the cost of renegotiating the package when scope changes.

The first line is a calendar. With hotfixes during the four months of each LTS branch, a business that wants to stay covered by fixes plans version moves on a short cycle across the three years, each one with regression testing of integrations, customizations, and ERP jobs. That work does not show up as license, it shows up as partner or internal hours, and it grows with the amount of custom code the project has accumulated.

The second line is contractual. When the plan is packaged deal by deal, the useful question is not only what it costs today, it is what changes in price if a new business unit, a new site, or a new feature comes in. A CFO who has that answer in writing can project; one who does not finds out in the amendment.

Three questions help bring this point into any evaluation:

1. How many version moves the business needs over three years to stay covered by fixes, and who pays for each one.
2. Which items in the package change price as the channel grows, and by what criterion.
3. How much of ongoing maintenance is license and how much is partner services, year by year.

On CWS Platform, commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace), on the principle of configuration over code, and CDL Workspace is a single system for the whole ecosystem. Price tables, rules, and contracts are configured on the platform or arrive from the ERP and CRM through an API.

When to choose Optimizely Configured Commerce

Optimizely Configured Commerce fits scenarios with these characteristics:

An ERP that already has a connector. Choose this architecture when the distributor runs one of the ERPs with a prebuilt connector and wants to reuse that starting point, with integration through the Windows Integration Service.

A team or partner with an upgrade routine. Choose this architecture when the company already has a team or partner used to planning and testing version moves on a short cycle, and that cost is already in the IT budget.

Buying through the customer's system. Choose this architecture when a large share of accounts buys through its own procurement system, and PunchOut over cXML is a requirement.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when finance wants the license decoupled from sales volume and a single version for every customer.

A license with no percentage of sales. Choose this architecture when finance does not want the software line tied to a percentage of sales or GMV. Billing is a platform license plus an integration license, with no percentage of sales or GMV. In a marketplace, the split percentage is the marketplace owner's commission.

One version for everyone. Choose this architecture when the company would rather not manage its own version of the software. Every customer runs the same version.

Commercial policy without a project for every change. Choose this architecture when price tables, rules, and contracts change often. They are configured on the platform, with customizable decimal places, thousands of promotions can run at the same time, and the sales rep's discount goes through multi-level approvals.

Net terms with credit kept on the platform. Choose this architecture when selling on net terms is the norm. The customer's credit limit is maintained on the platform, and net terms work with split shipments, scheduled deliveries, multiple ship-to addresses, and multiple ship-from locations.

Where to go from here

If your question is still which platform model fits your operation, the starting point is the three B2B commerce platform models, and, for the architecture side, the seven questions that separate B2B commerce architectures. The commercial side of the same vendor is in our comparison on changing pricing rules in Optimizely Configured Commerce and CWS Platform.

If the decision depends on building the three-year model with your own assumptions, it is worth talking to a CWS Platform specialist to put license, version, and maintenance in the same spreadsheet before you choose. The page When Selling More Doesn't Mean Earning More covers the pain behind this scenario in depth, without talking about any vendor.