Should I migrate from Demandware

A shopper sees one price. The price book that merchandising trusts holds another. Around the table everyone already agrees that Demandware has to be migrated into Salesforce, and someone has pasted a spreadsheet of products into Sales Cloud and called the paste the cutover. The shop has not changed. The file has no catalogue, no commerce price book, and no storefront. The agreement is the problem. It is easy to reach, and it fits a tidy core org, which is not the shop the shopper is looking at.

A wrong price is compatible with a shop that already runs on B2C Commerce, a core product that only prices a seller's deal, a sandbox that was refreshed and does not contain the storefront, and a date borrowed from a keyword. Only a change you can describe as catalogue, price book, and storefront is a commerce cutover. The others arrive with you, under a new file name, with the shopper still seeing yesterday's price.

What follows are the questions that separate those explanations. Each has a good answer and a bad answer, and the difference is whether the answer names something specific: a product in the catalogue, a price, a storefront, a person in merchandising. A general answer at this stage is what turns into an import.

#1. Which product is actually in the room?

The question is not whether Demandware should be migrated to Salesforce. It is which product the shopper can find today, what the catalogue calls it, what the commerce price book charges, and what the storefront shows.

A good answer sounds like one product, opened by merchandising, with the catalogue name, the commerce price book price, and the price the storefront shows, written down together.

A bad answer sounds like we loaded the products into Sales Cloud. The load may have happened. It does not name a storefront, so nobody will be able to tell afterwards whether the shopper's price changed. A programme with no checkable product cannot be judged to have succeeded.

Then ask where the software actually is. People still say Demandware because the word is on old contracts, old diagrams, and old export names. The rebrand record says what happened to the product, and the sentence is quoted once: "In 2016, the company acquired Demandware, which later became B2C Commerce Cloud."

The sentence says Demandware later became B2C Commerce Cloud. The name used here for that same product is B2C Commerce. It does not run on the core platform. A core org and a commerce instance can both sit under the Salesforce name. They are not one system. A seller looking at an opportunity is not looking at the shop. You are not moving a shop onto the core platform by loading rows.

#2. Does the product still belong on this shop?

If merchandising will keep selling the product on B2C Commerce, on purpose, with no change of system, the decision is to leave it. Leaving it is a finished answer. A rename that already happened is not a weekend of imports. A stay is allowed to be the majority of the list.

A good answer sounds like a named merchandiser who will keep that catalogue product on this storefront for another season, and who can open the price the shopper sees.

A bad answer sounds like the brand changed, so the shop should move. The brand change is the sentence already quoted. It is not a destination. Count the products whose price, catalogue place, and storefront presentation should stay where they are. Those rows are not a migration.

The price the shopper sees today is evidence the shop is live. Use that evidence. There is no end date for B2C Commerce in the material this decision is allowed to use. A date on the sheet, borrowed from a keyword, is not a reason to move the shop. Take the date off before you mark a product. Until a notice that is not in the cited record arrives, the date stays off the sheet.

#3. What has to change together if anything changes home?

A cutover, when you truly have one, is three things changing together: the catalogue entry, the price book price, and what the storefront shows. Miss one and you have not cut over. You have edited a list. The home, if it changes, is still described as those three. A home described only as Salesforce is the core platform in disguise.

A good answer sounds like a written cutover for one product in which catalogue, commerce price book, and storefront are each named, and a person who will check all three after the change.

A bad answer sounds like the destination is Salesforce. B2C Commerce does not run on the core platform, so a tab in Sales Cloud is not the destination. Reject that home. If nothing changes home, say so. An empty move list is a decision to keep the shop on B2C Commerce.

Keep three lines apart. Core product and price book: a deal on the core platform. B2C Commerce: catalogue, price book, and storefront, off that platform. Sandbox: not a clone of the shop. A plan that cannot keep the three lines apart is not ready. There is no score, and there is no order of commerce tools.

#4. What does a core product already do?

On the core platform, a product is an item you can sell. A price book is a list of prices for products. An opportunity line item takes a product from a price book and puts that product and that price on an opportunity. An opportunity is a deal. It has a stage and an amount. Those objects already do that work for a seller in the core org. They do it with no dependence on the Demandware name.

They do not publish a storefront. They do not hold the commerce catalogue. They do not hold the commerce price book the shop reads. A core price is a number on a deal. A storefront price is what the shopper is shown. If the comparison starts from the core product, write that limit before anyone compares anything.

A good answer sounds like an administrator who has opened the opportunity, named the price book on the line item, and said plainly that the shopper cannot see that screen.

A bad answer sounds like the core product is the shop. A plan that starts from a full export into core objects has assumed a move this comparison does not support. Ask which product, after the load, is no longer served by the storefront, and what the shopper uses instead. If the answer is silence, the load is a copy. A copy is not a decision. The core list can still help a seller build a deal. It is not the price the shopper sees.

Native, here, means the commerce product the record names, which does not run on the core platform. It does not mean the product object an administrator can create after a sandbox refresh. That object can price a deal. It is not the shop.

#5. What is the plan using instead of the storefront?

A Salesforce sandbox does not clone B2C Commerce. A refresh copies the core org in one of the shapes a core sandbox has. It does not copy the catalogue. It does not copy the commerce price book. It does not publish the storefront. Anyone who says the sandbox already contains the shop should open it and show the storefront. The absence is the finding. If the test of the migration is a sandbox refresh, reject that test. The shop is observed on the storefront, or it is not observed. A tidy core org has not shown you the price the shopper pays.

A good answer sounds like a refusal, written by a named person, of three things: an end date for B2C Commerce, a sandbox as a copy of the shop, and an AppExchange listing as the storefront.

A bad answer sounds like the listing, the sandbox, or the date will publish the shop. No listing is invented here. An app, a publisher, a review count, and a price are not in the record being cited. A listing found independently is still not the decision. The decision remains the catalogue, the price book, and the storefront. An app does not know which price the shopper saw. B2C Commerce was not given an end date, so do not treat the shop as a retired product that a listing must replace. An AppExchange search will not bring a retired product back, and the shop is not that case.

Other commerce tools exist. They are not ranked here, and they are not named in an order. A destination that is only a score is not a destination. Choose a tool only when the product is named and the storefront you mean can be opened. If a slide arrives with ranks, replace the ranks with one catalogue product and the price the storefront shows.

#What staying actually looks like

All five answers are measured against an alternative, and the alternative is usually left unstated, which flatters the import.

State it. Staying means the shopper keeps seeing the price on the B2C Commerce storefront, and merchandising keeps the catalogue and the commerce price book where they already are. The word Demandware remains on an old diagram. That is a glossary problem, not a blank shop. The cost of a false move is a file in Sales Cloud that prices a deal and leaves the storefront untouched, tested in a sandbox that never contained the shop.

There is a version of staying that is simply the correct decision. If the product still belongs on this shop, the catalogue, the price book, and the storefront are the work, and they are cheaper to keep aligned where they stand than to recreate as opportunities. An organisation that marks the stays first reaches any real cutover with a shorter catalogue.

A good answer sounds like a list of products that stay, with the storefront price written beside each, and a separate list of cutovers that may be empty, produced by merchandising rather than by the owner of the spreadsheet.

A bad answer sounds like we cannot keep the old name on the diagram. The diagram can be relabelled. The shop does not move because a label did.

#Where the neighbouring questions live

What it costs to change a catalogue you have actually named sits on the Demandware implementation page. The purchase, and the question of an end date as history, sits on what happened to Demandware. The system, the objects, and what you do when the storefront does not match, sit on integrating Demandware with Salesforce.