What happened to Demandware

A ticket asks for Demandware to be moved into a Salesforce sandbox before a trading peak, and the room has already agreed the ticket is reasonable. The refresh finishes overnight. Accounts look newer in the morning. The shop still shows Friday's price, because the shop was never inside that sandbox. Everyone treats the miss as a failed copy. The agreement is easy, and it is the problem. It fits a store that was bought and renamed, a store that was poured into the core org, and a store that is about to be switched off. Only the first of those is in the record.

The distinction that matters is where the shop lives. Salesforce bought Demandware in 2016. It became B2C Commerce Cloud. It does not run on the core Salesforce platform, and a Salesforce sandbox does not clone it. The ticket used an old company name for a store that already has a current product name. A catalogue, a price book, and a cutover, if anyone still wants them, are a later decision on the commerce instance. They are not a sandbox type.

What follows are the questions that separate a 2016 purchase from a migration into Sales Cloud. Each has a good answer and a bad answer. The difference is whether the answer names a year, a product, a sandbox shape, or a contract. A general answer here is how a correct purchase becomes a false move of the shop.

A DVD, a Reddit thread, a YouTube clip, a TikTok, a course, a book, or a certification is not a source for the date, the price, or a shutdown.

#The five, and what a bad answer signals

#1. Was Demandware bought, and what is the store called now?

The question is not whether the ticket used a familiar word. It is whether Salesforce bought the company, and which product the shop became.

Yes. Salesforce bought Demandware in 2016. The rebrand record says what the company became, and the sentence is quoted once: "In 2016, the company acquired Demandware, which later became B2C Commerce Cloud."

Later became is a change of product line. It is not a statement that the storefront was rebuilt as records in a sales org. If a contract, a wiki, or a folder still says Demandware, the product you mean is B2C Commerce Cloud. Say that name when you mean the store. Say Demandware when you mean the company that was bought in 2016, or the word still printed on old paper.

The acquisition, as the record can tell it, is that 2016 purchase and the later name B2C Commerce Cloud. There is no chapter in which the store was switched off, and no chapter in which it was poured into a core org. People keep the old name because implementations, invoices, and runbooks age more slowly than product titles. A search for the old name is not evidence of a second platform sitting beside the store. Open the commerce instance. If the shop is there, you are already on the product the record names.

A partner who answers what happened with a sandbox plan has changed the subject. The purchase already happened. The store's home is B2C Commerce Cloud.

A good answer sounds like the person who opened the commerce instance saying the company was bought in 2016 and the shop a customer hits is B2C Commerce Cloud, and striking any line that says the storefront was rebuilt inside a sales org.

A bad answer sounds like Demandware is old, so we will load it into Sales Cloud before the peak. The age of the word is real. The destination is not. Later became names a commerce product. It does not name a spreadsheet of products sitting on opportunities.

#2. Which date can you defend?

1. That is the year the cited sentence gives. The sentence does not add a month, a day, or a separate announcement date. A timeline drawn with seasons is more precise than the record, which means it is invented.

Searches for an acquisition date, an announcement, and a timeline land on that year. If counsel needs a completion day for a contract, the contract is the document. A day remembered from a headline that is not cited is not a date worth repeating.

Do not stack Demandware's year against another acquisition and call the pair one programme. ExactTarget's tools sit in a marketing product from a 2013 purchase. The store is a 2016 purchase with a different home. The years are both real. They are not one event.

Write 2016 on the architecture slide if the slide still says the company is independent. Do not write a sunset next to the year. The year is a purchase. It is not an expiry.

A good answer sounds like the architect writing 2016 beside B2C Commerce Cloud, and keeping ExactTarget's 2013 on a different line because that deal put tools in a marketing product, not in the shop.

A bad answer sounds like sometime in 2016, announced earlier, and really part of the same programme as the email acquisition. The record gives a year. It does not give a season, and it does not merge two purchases because both companies now sit with Salesforce.

#3. Who owns the shop, and which system is it?

Salesforce owns it. Demandware is not, on these facts, an independent commerce vendor a customer still contracts with under that name. The product is B2C Commerce Cloud.

It does not run on the core Salesforce platform. That sentence is the one a sandbox story skips. The core org has its own data model and its own sandbox copies. The commerce instance has sites, a catalogue, prices, and orders of its own. A copy of the core org does not bring the storefront with it.

A Salesforce sandbox does not clone B2C Commerce. Full copy, partial copy, and developer copy are shapes of a core sandbox. None of them is a second shop. If a proposal's method is only a sandbox type, it is still talking about the org, not about the store.

You may also hold a customer or an order summary in the core org because an integration put it there. That copy is not the store. Who owns the shop is Salesforce, through B2C Commerce Cloud. Who is allowed to change a price on a Tuesday is whoever your organisation has named. The record does not know that person. It knows the product boundary.

Owning the company does not mean a Sales Cloud licence includes the storefront. A seller with an opportunity does not, by that access, hold the catalogue. Say the two systems apart when someone asks who owns Demandware.

A good answer sounds like a named commerce administrator opening the instance, pointing at the site a shopper hits, and telling the sandbox owner that full copy, partial copy, and developer copy are copies of the core org and not of B2C Commerce.

A bad answer sounds like we refreshed the full copy, so the shop should have come with it. The refresh did what a core sandbox does. The Friday price is still on the commerce instance because that is where the shop was. An order summary sitting in the core org, put there by an integration, is a copy of a fact. It is not the store.

#4. What was paid?

The record cited here does not publish a purchase price or a licence fee. How much Salesforce paid, how much Demandware was sold for, and what you pay for B2C Commerce now are three different questions. The cited record is silent on the first two. The silence is not filled with a figure to finish a slide.

Your commerce contract is your licence. It is not a number printed in the rebrand record. A search for the acquisition price should end on that silence. A remembered billion, or any other headline that is not cited, is not a source.

Why Salesforce acquired Demandware, and why Demandware sold, are not in the quoted sentence. The sentence gives the year and the later product name. It does not give a motive. A motive cannot be checked against the record used here.

Impact on customers, as far as the record will say it, is the new product name and the fact that the store stayed off the core platform. Customers were not handed a date to leave the shop, and they were not told that a core sandbox became the shop. A business case that needs a deal value has to cite a document that actually prints one. The source used here does not.

A good answer sounds like procurement saying the 2016 record is silent, then reading the B2C Commerce fee off the commerce contract, and refusing to paste a remembered billion into either cell.

A bad answer sounds like the deal was about a billion, so that is what the store costs us. A headline that is not cited is not the acquisition price, and it is not the licence. The two questions stay apart even when a slide has one empty box.

#5. Does B2C Commerce have an end date?

The record does not give B2C Commerce an end date. Do not invent one. Shutdown and sunset searches deserve that refusal, not a borrowed date.

Other acquired names were later retired on a notice. B2C Commerce is not given that treatment. Do not pin a social-product retirement, or a data-platform end of life, onto the store because the deals all sit in one list of acquisitions. The list is not a single shutdown calendar.

A folder named Demandware can look abandoned because the word is old. Abandoned spelling is not a switched-off shop. Look at the commerce instance before you brief an exit. If orders are still being taken there, the product is current under the name B2C Commerce Cloud, and the old word is history.

A renewal that warns the 2016 purchase means the storefront must move into Sales Cloud has mixed a purchase with a migration. The purchase already happened. The store's home is B2C Commerce Cloud. Moving it would be a new decision, not a consequence the record publishes. A second brand, a closed locale, or a feed from a warehouse is an inventory of your estate. The record does not know which of those you run. It knows they are not created by the 2016 year alone.

If someone asks whether customers were forced off Demandware onto a CRM, the record does not say that. It says the company was acquired and later became B2C Commerce Cloud. Forced, declined, and worth-it need your shop in front of you.

A good answer sounds like the commerce owner showing orders still being taken on B2C Commerce Cloud, and showing that no notice in the file ends that product, including no date borrowed from a social product or a data platform.

A bad answer sounds like the folder is named Demandware and nobody likes the spelling, so the shop is being switched off and must land in Sales Cloud. Old paper is not an end date. A move into the core org would be a new decision. It is not what 2016 did.

#What to do with the answers

Read the five as a set. Specific answers stop the ticket. General answers mean the room has agreed that an old company name is a sandbox job, which is how the Friday price got left behind.

Open the commerce instance, not the core sandbox. Find the site a shopper hits. Write four lines for the ticket. Bought in 2016. Now B2C Commerce Cloud. Not on the core platform. No end date in the record. Those lines stop a false migration. They do not choose a catalogue, a price book, or a cutover window. Keep the old name in a glossary if a contract still needs it. Do not let the glossary become a sandbox job. A board can carry those lines and nothing more from this history. A deal value, a motive, and a sunset quarter would make a correct year look like a false project.

A migration, when there is one, is a catalogue, a price book, and a storefront cutover on B2C Commerce. It is not a spreadsheet loaded into Sales Cloud. That scope is on the Demandware implementation page.