ChatGPT
Claude
Google AI
Copilot
A merchandiser asks for the catalogue in the sandbox to match production before a pricing test. The team refreshes a Salesforce org sandbox and opens it the next morning. Accounts and opportunities look newer. The storefront still shows Friday's prices. Weekend orders are on the commerce instance, which nobody refreshed, because the refresh they bought cannot see it. The quote had said Demandware data migration into Salesforce. The store was never a pile of objects in that org.
Someone then asks for a second refresh, as if the first had been a partial. It was not partial. It was the wrong system. The people who run the site are still waiting, and the quote is already being treated as a plan.
The refresh could not see the store
Demandware was acquired in 2016. The rebrand note says what it became, in one sentence: "In 2016, the company acquired Demandware, which later became B2C Commerce Cloud." Later became is a change of name and of product line. It is not a statement that the storefront was rebuilt as records in a sales org. If your contract, your wiki, or your folder structure still says Demandware, you are talking about B2C Commerce Cloud. Say that name in the quote. A partner who keeps writing Demandware as if it were a legacy database sitting outside Salesforce, waiting to be imported, has started from the old folder.
The failure is ordinary. Core Salesforce sandboxes are how teams copy a core org. They are a familiar button. Commerce is not behind that button. A plan that depends on the button will look busy, will send the usual emails about a refresh, and will leave the store where it was. The busy part is what gets reported upward. The store is what the merchandiser checks.
It does not run on the core platform
B2C Commerce Cloud does not run on the core Salesforce platform. That is the fact that makes the sandbox story collapse. The core org has its own data model, its own metadata, and its own sandbox copies. The commerce instance has sites, a catalogue, prices, customers, and orders of its own. Code that shapes the storefront lives with the commerce instance. A copy of the core org does not bring that code with it, and it does not bring the catalogue with it.
You may also hold a customer, an order summary, or a product in the core org because an integration put it there. That copy is not the store. A quote has to say, for each fact that matters, which system is allowed to be right. If the price on the store and the price on an opportunity can disagree, the quote says which one wins, and when. If you have no such link, the quote must not describe one. Inventing a sync so the diagram looks joined is how a second project hides inside the first.
A sandbox of a Salesforce org does not clone B2C Commerce. Write that on the brief in plain words, because it is the line partners skip when they reuse a core-org estimate. Full copy, partial copy, developer copy: those are core sandbox shapes. None of them is a second store. If a proposal's method section is only a sandbox type, send it back. Ask where the commerce instance will be copied, if it will be copied at all, and what tool does that copy. If they cannot name it, they are still talking about the org.
What the number is made of
This page will not print a price. Commerce work is easy to decorate with a large figure and a phase called migration. The figure is meaningless until four lines are specific to the store you have.
Scope is which site, which catalogue, which price set, and which orders are in the work. A company can run more than one site on one commerce estate. A quote that says "the Demandware data" has not chosen. Scope also says what will not move. Historical orders you will archive as files are not the same scope as live baskets. A rename from Demandware to B2C Commerce Cloud moves nothing by itself. If the site already runs there, the migration may be a correction of language. Price the language correction as a reading of the contract and the wiki. Do not price it as a rebuild of the storefront.
Licences are the commerce contract you already pay, plus any core-org licences you already pay for the other system. They are not a new platform fee invented so the old name can be retired on a slide. If someone proposes an extra product, the licence line names that product and the reason. "Because Demandware is old" is not a reason. The product has a current name. You are either changing behaviour on B2C Commerce Cloud, or you are not.
People are the merchandiser who knows which category is live, the person who can open the commerce administration and find a price, the developer who knows where the storefront code sits, and the owner of the commerce contract. Internal days count. A quote that staffs only an integration developer will miss the person who can say a product is discontinued. That person is the difference between a file that is complete and a file that is merely long.
Cutover is the window when shoppers, or a feed, start reading a different place. A rename does not need that window. A real change does. Name what the shopper hits during the window, and what happens to a basket that was open. If the plan says "we will cut over by refreshing the sandbox", the plan has reused the failed method. There is no cutover until the commerce instance is the thing that changes.
What you ask them to point at
A partner who can do this work can point at the commerce instance without opening the core org first. They can name the site. They can name the catalogue they mean, not "products" as a vague noun. They can say whether orders in scope are open orders, historical orders, or both. They can say whether customers on the store are the same records as contacts in the core org, or a different set that sometimes shares an email address.
They can also say what they will not take on. They will not clone the store with a core sandbox. They will not remodel the catalogue as a set of core custom objects and call that the migration, unless you have written a decision to leave the storefront. They will not invent a daily API cap to justify a timeline. Caps, where a contract has them, are read off your contract on a dated line. They are not a round number from a previous client.
Code on the storefront is its own line. If the work includes cartridges or other storefront customisation, say so. If it does not, say that the customisation stays, and that the quote is data and configuration only. Mixing a code rewrite into a data quote is how a four-week file job becomes a year. Ask for the split in writing before you compare proposals.
The same confusion shows up with other acquired names. ExactTarget's tools sit in Marketing Cloud Engagement, not in a core-org import. That is a different product and a different mistake, written up in the ExactTarget guide. Do not let one partner sell you a single "old Salesforce brands into the org" programme. The store and the email platform do not share a sandbox, and they should not share a careless quote.
Who decides, and what they decide
The commerce owner decides which site is in scope. The merchandiser decides which categories are live. The core-org administrator does not decide either of those by default, even if they book the sandbox refresh, because the refresh is not the store. Put the decision with the person who would notice a wrong price on the site tonight.
Write the exclusions in the same meeting. A second brand. A closed locale. A feed from a warehouse system that is out of contract. If it is not written, it will be assumed in, because "all the Demandware data" sounds tidy. Tidy is how the price loses its meaning. A later change request will put the excluded brand back, at a worse moment, and someone will call that a surprise. It was an omission.
Contractors who have only worked in a core org need the limit said aloud. Their skills may be real. Their map may still be wrong. The test is whether they ask to be shown the commerce instance, or whether they ask for a system administrator login on the sales org and start drawing objects. The second path is the sandbox mistake in slow motion.
What a passing quote refuses
People ask for the best Demandware integration agency. This page will not rank one, and it will not rank SynconAI. Rankings do not know which site is yours. The test is the current product, the objects, and the refusal.
The current product is B2C Commerce Cloud. The objects are the site, the catalogue, the prices, the customers, and the orders you listed, plus storefront code only if you listed that too. The refusal is that they will not treat a core sandbox as a clone of the store, and they will not quote a move onto the core platform as if the storefront were already a custom-object project. They will not add a shutdown of the commerce instance unless you have decided to close the store, in a sentence that says what replaces the shopfront for a customer that night. This page does not choose that replacement for you.
A case study about another retailer's go-live is not the test. Your catalogue is the test. If they cannot describe it without asking you what Demandware means in 2026, they are early. Tell them the current name, and see whether the method section changes. If it stays a sandbox plan, stop.
How to mark up the proposal
| Line they wrote | What it actually is | What you send back |
|---|---|---|
| Migrate Demandware into Salesforce | A store that is already B2C Commerce Cloud, off the core platform | Ask which site and which catalogue, and what will change home |
| Full copy sandbox | A copy of the core org, not of the store | Delete it as the method. Ask how the commerce instance is handled |
| All products, all orders, all customers | An unbounded scope | Split live catalogue, open orders, and history you will only archive |
| One figure, ready for procurement | Scope, licences, people, and cutover collapsed | Split the four lines. Refuse the single number until then |
| We will turn Demandware off | A rename treated as a closure | Ask what the shopper uses the next morning. If they cannot say, it is not a plan |
Before you ask again for a number, write five nouns: the instance, the site, the catalogue, the order set, and the one thing that will not be copied. Hand those to each partner with the same sentence: Demandware became B2C Commerce Cloud, it does not run on the core platform, and you will not accept a sandbox as a clone. The reply you want names those five nouns in the first page and prices four lines under them. The reply you send away talks about Demandware as a database they will import over a weekend. You can see the difference without a scoring sheet.
Keep a dated note of which system is source for price, for stock status if you show it, and for the customer email. Where you do not know, write unknown, and leave it unknown until someone opens the instance. Unknown is a cheaper word than a migration phase built to hide it. The quote gets a number after the unknowns that block scope are either answered or moved out of scope. Not before.
The other searches
The project quote is on demandware implementation cost. That page does not print a figure. Who bought the company is on what happened to demandware. The connector is on integrating demandware with Salesforce. Whether to move is on should I migrate from demandware. The customer fee is on demandware licence cost. Who to hire is on hiring for demandware. This page does not rank an agency.
