The storefront is the demo. The integration is the project.

01What Commerce Cloud covers, and what it does not

Commerce Cloud is not one product. As Salesforce sets it out, it is two storefront products with a shared supporting cast, and the supporting cast is where the work is.

• B2C Commerce, the direct-to-consumer storefront: anonymous browsing, catalogue, promotions, and a one-off checkout.
• B2B Commerce, which assumes a known buyer on an account, with contracted pricing, approval rules, and bulk or repeat ordering.
• Order Management, and Order Management for B2B, covering order capture through to fulfilment, amendments, and returns. Salesforce lists these separately from the storefront, and that separation is accurate: it is a second implementation, not a storefront setting.
• Modern Point of Sale and Unified Commerce, the in-store side, where online stock and shop-floor stock have to agree.
• Composable Commerce, the headless route, where the front end is yours and the commerce APIs are Salesforce’s.
• Payments, the payment surface.
• Agentforce Guided Shopping, the agent layer over the storefront.

What it does not cover is the part most briefs assume it does. Commerce Cloud does not replace your ERP, your pricing engine, your tax engine, or your warehouse system. It integrates with them, and every one of those integrations is a line item with an owner, a test plan, and a failure mode.

One scoping error is common enough to name. Where the real problem is quoting, contracting, amendments, and subscription billing rather than a storefront, this is the wrong product line. That work sits in Revenue Lifecycle Management, and the article you want is choosing a Salesforce Revenue Cloud implementation partner.

02The four integration boundaries that decide the timeline

For each boundary: what breaks, who is assumed to own it, and what it costs to repair after launch.

• ERP, for stock and fulfilment. What breaks: the storefront sells stock the warehouse does not have, because availability is cached and the refresh interval was never agreed. Assumed owner: the ERP team, who were not in the design workshops. Repair after launch: oversells cancelled by hand, which is a customer-service cost and a refund cost before it is an engineering one.
• The pricing and promotions engine, when it is not Salesforce. What breaks: the price in the basket disagrees with the price on the invoice, usually on a promotion that stacks. Assumed owner: nobody, because each side believes the other holds the rule. Repair after launch: a reconciliation process that runs for the life of the platform.
• Order management and the returns path. What breaks: the order is captured and then stalls, because nothing downstream was built to accept a partial shipment or a partial return. Assumed owner: the storefront team, who scoped to checkout. Repair after launch: the most expensive of the four, because it means implementing a second product after go-live under pressure.
• Payment and tax providers. What breaks: tax calculated at a different point in the flow from where it is charged, or a payment method that works in test and not in the live market. Assumed owner: finance, who were consulted rather than engaged. Repair after launch: usually bounded, occasionally a compliance question.

Commercial decision: the four boundaries are either scoped and owned before design sign-off, or they are discovered in system testing. The work is the same either way. The difference is whether it is estimated or whether it arrives as a change request on a fixed date.

03The catalogue model mismatch

This is the single most common finding, and it is almost always inherited rather than created. A catalogue built for the previous platform’s data model is carried across unexamined, because it is the one asset everybody agrees already works.

It does not work. Variants, bundles, and category rules on the old platform encode how the business used to sell, including the workarounds for things the old platform could not do. Carried into a new model, those workarounds become permanent structure. The symptom is a catalogue that merchandising teams cannot change without a developer, which is the opposite of the reason the replatform was funded.

The test is simple and it belongs in discovery, not in build. Take the ten products that are hardest to describe, the bundles, the configurable items, the ones with regional pricing, and model those first. If they do not fit cleanly, the catalogue is being redesigned, and that is a workstream with its own estimate rather than a data load.

04The data you must migrate, and the data you must not

Four categories, four different answers. Treating them as one data load is how cutover weekends overrun.

• Migrate: customer accounts, addresses, and the catalogue in its new model. These are the records the storefront cannot open without.
• Migrate, and reconcile before cutover: open orders. Every order in flight has to agree with the order management system on the morning of go-live, line by line. This is the one item with no acceptable margin of error, because the customer already has an email saying what they bought.
• Do not migrate: historical order history beyond the window the business actually serves, and anything the old platform computed rather than stored. Both are better served by a read-only archive than by a migration that has to be maintained.
• Decide explicitly: saved payment tokens. Whether they can move is a question for the payment provider, not for Salesforce, and the answer changes the returning-customer experience on day one. Get it in writing early.

The reconciliation point is the same one we set out in the Salesforce data migration checklist, and the method applies whatever the source platform. Where the extraction and reconciliation are the bulk of the programme, that is Salesforce data migration services rather than a storefront build.

05The questions to ask a partner

Five questions. The first is the one that separates the field, and it is worth asking verbatim.

1. Which order management and pricing systems have you integrated, and what did you do when the catalogue model did not match?
2. Walk me through a partial shipment and a partial return, in our fulfilment model, from the customer’s email to the refund.
3. Who reconciles open orders at cutover, what does the reconciliation report look like, and what is the rollback if it does not balance?
4. Is order management in this scope or a later phase? If later, what does the storefront do in the interim, and who pays for the interim?
5. Name the people who will do this work and tell me their availability. Not the account team, and not the tier.

Note what is absent. There is no question about partner tier, because a tier describes a commercial relationship with Salesforce and says nothing about whether a replatform lands. We make the same point, with the current programme detail, in our guide to Salesforce implementation partners in the USA.

06What it costs, and why the range is wide

We do not publish a figure for this, because any figure that does not name its assumptions is a sales number. The range on a Commerce Cloud programme is wide for a reason that is specific and checkable: the cost is driven by the count of integration boundaries that are not Salesforce, whether the catalogue is redesigned or carried across, whether order management is in scope, and how many markets go live at once.

Those are the variables to price, and they are the ones a partner should be able to put a number against individually rather than as a single blended estimate. The method we use, and the drivers in full, are set out in what drives the cost of a Salesforce implementation. Apply it to a quote before you compare two quotes, because two proposals with the same total can carry very different assumptions about who owns the ERP work.