Optimizely Configured Commerce vs. CWS Platform: who maintains the ERP integration?

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

For a distributor's CIO, the ERP integration is where a digital commerce program earns or loses credibility. If orders do not reach the ERP, if portal inventory drifts from the warehouse, if a framework upgrade breaks the connector, the problem stops being the portal's and becomes all of IT's. And the cost of that piece is not in the first release: it is in who keeps the connector alive as the ERP, the framework, and the platform change, each at its own pace.

Three questions separate integration designs: where the connector code runs, which framework version it depends on to stay supported, and who hosts and pays for the environments where that code is developed and tested. They are architecture questions, but their answers turn into budget and risk lines.

This comparison looks at Optimizely Configured Commerce and CWS Platform from that angle only. The commercial rules comparison is in our comparison on changing pricing rules in Optimizely Configured Commerce and CWS Platform, and the framing of platform models is in the three B2B commerce platform models.

75s

What Optimizely Configured Commerce does well

Optimizely Configured Commerce has an explicit, documented integration design. The Windows Integration Service runs as an agent installed inside the customer's corporate firewall, which polls the commerce site to run integration jobs and returns the results. In each job, pre- and post-processors run on the Configured Commerce web server and the integration processors run on the agent's server. The flow splits into Refresh tasks, which pull products, inventory, and customers from the ERP, and Submit tasks, which push orders and customers created on the storefront to the ERP.

For teams that would rather not expose the ERP database to the outside, the model is coherent: the agent sits on the inside, and direct database access is used for large volumes while web services handle business logic such as order submission, according to the integration technology overview. For cloud ERPs and connections to PIM or cloud storage, there is an internal WIS option that runs directly in Configured Commerce and loads customizations through Extensions.dll.

There are also prebuilt connectors for SX.e, Prophet 21, Infor A+, Acumatica, and FACTS, and the feature the documentation calls Real time pricing and inventory, which looks up price and inventory in the ERP through a direct API call or through the agent, with a default 10-second timeout, a 60-minute cache for pricing, and batches of 20 items. For an IT team that runs one of those ERPs and knows the .NET ecosystem well, it is a concrete starting point.

Where the architecture diverges

The divergence that matters to the CIO is who maintains the integration code over time. The vendor's own documentation records two points:

• limitation recorded in the vendor's documentation, accessed on October 16, 2026: Optimizely ERP connectors do not support .NET 8; Optimizely offers its existing ERP connectors in their current state ("Optimizely's ERP connectors do not support .NET 8.", "Optimizely offers existing ERP connectors in their current state", https://docs.optimizely.com/configured-commerce/docs/erp-connector-implementation).
• limitation recorded in the vendor's documentation, accessed on October 16, 2026: the partner or implementation team hosts all development and test environments ("Your partner/implementation team is responsible for hosting all development and test environments.", https://docs.optimizely.com/configured-commerce/docs/optimizely-configured-commerce-sandbox-vs-production-environment-management-and-performance).

Both points meet in the same place: the connector is offered as it is, the adaptation falls on the customer's side, and whoever adapts it also has to maintain the environments where that adaptation is developed and tested. The same connector implementation page describes that, without .NET 8 support, adapting the open code provided to partners is manual work. For IT, that turns the integration into an owned asset with its own technical debt, and the pace of that debt follows the pace of the framework.

On CWS Platform, the design is API-first and headless, with REST APIs and webhooks. Price tables, rules, and contracts can arrive from the ERP or CRM through an API, and commercial rules sit in parameters of the Commerce Rules Engine (CDL Workspace), not in connector code. Tax calculation can be delegated to the tax engine the customer already uses: tax comes from the ERP.

The technical decision is to map who owns each line of code between the ERP and the portal, and for how long.

What changes in operations, through the CIO/CTO lens

The difference shows up on IT's calendar. When the connector depends on a framework the vendor does not carry forward, every runtime version change becomes a small migration project: rewrite or recompile, test against the ERP, validate in an owned environment, deploy. When development and test environments are the partner's responsibility, that project also carries infrastructure and contract cost outside the platform license.

The second consequence is risk. Looking up the ERP at the moment of the order depends, by definition, on the ERP responding, and the Windows Integration Service documentation itself asks for a fallback behavior to be defined if the ERP fails. That is not a problem in itself, it is a design requirement that needs an owner, testing, and monitoring.

Four questions help bring this point into any evaluation:

1. Which framework version your ERP connector runs on today, and what the plan is when it leaves support.
2. Who hosts and pays for development and test environments over the three years of the contract.
3. How much of the commercial logic will live inside integration code, and how much in configuration.
4. What the portal does when the ERP does not respond.

On CWS Platform, commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace); tables, rules, and contracts can be configured on the platform or arrive from the ERP and CRM through an API, and CDL Workspace is a single system for the whole ecosystem. Every customer runs the same version, and billing is a platform license plus an integration license, with no percentage of sales or GMV.

When to choose Optimizely Configured Commerce

Optimizely Configured Commerce fits scenarios with these characteristics:

An IT team with .NET skills and an ERP with an existing connector. Choose this architecture when the ERP is on the list of prebuilt connectors and the team or partner can adapt and maintain that code on the framework the business requires.

Integration that has to stay behind the firewall. Choose this architecture when security policy requires ERP access to originate inside the network, with the Windows Integration Service installed in the customer's environment.

An implementation partner already hired for the environments. Choose this architecture when the company already has a partner hosting development and test, and that cost is already in the budget.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when IT wants the integration to carry data and the commercial rules to stay out of the code.

Integration through APIs, rules in parameters. Choose this architecture when the goal is to reduce business logic inside the connector. The platform is API-first and headless, with REST APIs and webhooks; price tables, rules, and contracts are configured on the platform, on the principle of configuration over code, or received from the ERP and CRM through an API, with customizable decimal places.

Tax where it is already calculated. Choose this architecture when the company's ERP or tax engine is the source of tax. Tax calculation can be delegated to the tax engine the customer already uses.

One version and one system. Choose this architecture when IT would rather not manage its own version. Every customer runs the same version, and CDL Workspace is a single system for the whole ecosystem.

Credit and orders under the same rules. Choose this architecture when selling on net terms is the norm. The customer's credit limit is maintained on the platform, granted in CDL Workspace or through an API, and the same order accepts more than one payment method.

Where to go from here

If your question is still which architecture fits your operation, the path is the seven questions that separate B2B commerce architectures, and the comparison between models is in the three B2B commerce platform models.

If the decision depends on understanding how much of your current integration is data and how much is logic, it is worth talking to a CWS Platform specialist to map that boundary before you choose. The page When Integration Breaks Everything covers the pain behind this scenario in depth, without talking about any vendor.