# Who to hire for Demandware on Salesforce

Demandware is B2C Commerce, a storefront platform with its own developers, its own release discipline and its own peak-trading risks. Hire for that, not for a CRM project.

**Published:** 2025-11-05
**Canonical:** https://synconai.com/hire-demandware-salesforce-partner
**Author:** SynconAI Architecture Team

## In short

Hire a B2C Commerce delivery team that can name the storefront approach it would use, holds the Salesforce Certified B2C Commerce Developer and Architect credentials, and has shipped through a peak trading week. Demandware is now B2C Commerce, a storefront platform, so a CRM consultant who treats it as a data load is the wrong hire.

## Sources

- **The ultimate guide to Salesforce product rebrands** (retrieved 2026-10-10)
  https://gearset.com/blog/salesforce-product-rebrands/
  > In 2016, the company acquired Demandware, which later became B2C Commerce Cloud.
- **B2C Commerce | Salesforce** (retrieved 2026-10-13)
  https://www.salesforce.com/commerce/b2c-ecommerce/
  > Simplify the management of multiple brands and regions with our multi-site architecture, and get dedicated staging and dev environments to de-risk deployments.
- **B2C Commerce | Salesforce** (retrieved 2026-10-13)
  https://www.salesforce.com/commerce/b2c-ecommerce/
  > Price books, promotions, carts, catalogs, content libraries and much more can be defined as shared or site-specific.
- **Composable Storefront | Salesforce Commerce Cloud** (retrieved 2026-10-13)
  https://www.salesforce.com/commerce/composable/
  > This phased deployment strategy de-risks your headless rollout and lets you transition at your own pace.

## What to take away

- Demandware is B2C Commerce today. It is a storefront platform, with merchandising, sites, price books and code deployments of its own, and it is not a module of Sales Cloud.
- The credentials that match the work are the Salesforce Certified B2C Commerce Developer and B2C Commerce Architect. The B2C Solution Architect credential helps when several clouds are involved.
- The decision that shapes the hire is the storefront approach: keep template-based storefronts, move to a composable storefront, or do both in phases.
- A first engagement should be a release-readiness and performance review of one site before any redesign.

## The guide

Retail teams searching for a Demandware partner are often ten years into a platform that has changed owner and name. The old runbooks still say Demandware. The people who wrote the first cartridges have moved on. The product is B2C Commerce, and the cost of getting this hire wrong is not an awkward project, it is a broken checkout in your biggest trading week.

This page sets out how to hire for that work. It explains what a partner really does on B2C Commerce, which credentials map to the job, why the storefront approach matters more than any logo, how to scope a first engagement, and ten questions to ask. It ranks no firm. For what the work costs, see [Demandware implementation cost](/demandware-salesforce-implementation-cost).

## What the platform is, and why it changes the hire

The rebrand record records the lineage briefly: "In 2016, the company acquired Demandware, which later became B2C Commerce Cloud." The consequence for a buyer is that B2C Commerce has a long and independent history. It has its own merchandising console, Business Manager, its own code model, its own jobs framework and its own way of deploying code. A consultant who is excellent at Sales Cloud may never have touched any of it.

Salesforce's page on the platform describes the multi-site design: "Simplify the management of multiple brands and regions with our multi-site architecture, and get dedicated staging and dev environments to de-risk deployments." Pay attention to the staging and development environments, because that is where release discipline lives. A partner who cannot describe how code moves from a developer's sandbox to staging to production, with data replication in between, has not run a serious storefront.

The same page makes a point that matters for scoping: "Price books, promotions, carts, catalogs, content libraries and much more can be defined as shared or site-specific." That is a design decision with consequences. If you run three brands and two countries, the choice of what is shared and what is local determines whether a price change is one edit or twelve. A partner should ask about it in the first conversation.

## The storefront decision comes first

Before you hire, you need a view on the storefront, because the skills differ.

**Template-based storefronts.** Server-rendered pages built on Salesforce's reference storefront code, with custom cartridges layered on top. The skills are back-end JavaScript, ISML templates and a long familiarity with cartridge layering. Many mature estates run this way and run it well.

**Composable storefronts.** A headless front end, built on the Progressive Web App Kit and hosted on Salesforce's managed runtime, talking to B2C Commerce through APIs. The skills are modern front-end engineering, React, API design and caching, plus enough B2C Commerce knowledge to use the APIs sensibly. Salesforce's own page says the approach can be phased: "This phased deployment strategy de-risks your headless rollout and lets you transition at your own pace."

**A hybrid.** Move the highest-impact pages first, keep the rest on templates, and accept two codebases for a period. This is common, and it demands a partner who has done it, because routing, sessions and the basket have to behave across both.

Ask each candidate which of these they have shipped, how recently, and how many people on their team write the front end. A firm that is strong only at templates will steer you towards templates. A firm that is strong only at headless will steer you the other way. Neither is neutral, which is why you should form a view first.

## Credentials that match the work

| Credential | Why it matters here |
| --- | --- |
| Salesforce Certified B2C Commerce Developer | Shows working knowledge of the code model, cartridges, controllers, jobs and the data APIs |
| Salesforce Certified B2C Commerce Architect | Shows ability to design across sites, integrations and performance, and to review other people's code |
| Salesforce Certified B2C Solution Architect | Useful when commerce must work with marketing, service and sales clouds |
| Salesforce Certified Platform Administrator | Relevant only if the core org is in scope |

These names are listed on Trailhead's credentials pages. Check the current names before you quote them in a request for proposal. Treat the Developer credential as the floor for anyone who commits code and the Architect credential as the thing to ask of whoever signs the design.

Credentials do not tell you about peak load. Ask what the team's busiest event was, what broke, and what they changed afterwards.

## Work a partner really does on B2C Commerce

The work usually splits into six areas.

1. **Storefront build and upgrade.** New pages, checkout changes, search and merchandising refinements, or a staged move to a composable front end.
2. **Catalogue and price-book operations.** Importing and replicating catalogues, structuring price books by currency and site, handling promotions that interact, and running scheduled jobs that keep data fresh.
3. **Integrations.** Payments, tax, address validation, order management, warehouse and ERP systems, and the feeds that move product and stock data in and out.
4. **Performance and release.** Caching strategy, page speed work, code-version discipline, regression tests, and the checklist before a trading event.
5. **Multi-site and multi-currency design.** Deciding what is shared across sites and what is local, and handling languages and currency rounding.
6. **Connections to the rest of Salesforce.** Customer data, loyalty, marketing journeys and service, where the commerce platform must exchange data with core products.

When you write the brief, say which of these six you need. A partner who answers "all of them" has not read the brief.

## A first engagement worth buying

Start with a release-readiness and performance review of one site, over a few weeks. The partner reviews your code versions and deployment process, your caching and job schedules, your top integrations and your last peak event. The deliverables are a risk register, a short list of fixes ranked by trading impact, and a view on the storefront approach. A candid recommendation to leave things alone is a perfectly good outcome.

Follow it, if the review is good, with one contained change on a low-risk page. The aim is to watch their release behaviour: how they test, how they use staging, how they roll back. You can scale up from there.

Avoid starting with a replatform. Nothing in the rebrand record tells you that the platform is going away, and Salesforce's pages describe active investment in both template and composable approaches. A move should be a decision you make for business reasons, discussed on [should I migrate from Demandware](/should-i-migrate-from-demandware), not a project a vendor sells you in the first meeting.

## Red flags specific to this product

**A CRM mindset.** Proposals that talk about objects, flows and permission sets, and say nothing about cartridges, jobs, staging and replication. A spreadsheet loaded into Sales Cloud is not a storefront.

**No peak-trading story.** If nobody on the team has been on call for a major sale, the first one will happen to you.

**Unreviewed custom code.** Cartridges accumulate. A partner that does not propose a code review before changing anything is guessing about what is already there.

**A front-end only plan.** A headless project that spends its time on the front end and none on API limits, caching and checkout reliability.

**Treating sites as copies.** Cloning a site for each brand without deciding what is shared leads to price books and catalogues drifting apart.

## The integration seams a partner must know

Most B2C Commerce incidents start at a seam, not in the storefront code. Four deserve a named owner in your statement of work.

The first is the product feed. Catalogue and price data usually arrives from an ERP or product information system on a schedule, in files or through an interface. A partner should explain what happens when a feed arrives late, arrives twice or arrives half-formed, and how the storefront behaves while it is wrong. Ask to see the job monitoring they would put in place.

The second is stock. Showing a product as available when the warehouse has none is the fastest way to turn a sale into a complaint. Ask how often stock is refreshed, how reservations work during checkout, and what happens when two customers buy the last unit at the same moment.

The third is payments and tax. These are the integrations where a defect costs money directly. A partner should describe their test approach with the payment provider's test environment, how they simulate declines and timeouts, and who is on call when a provider has an outage.

The fourth is the link to the rest of Salesforce. Salesforce's page says that built-in API compatibility is intended to connect commerce with marketing, service and sales. That is useful, but it still has to be designed: which customer record is the master, how consent travels, and what happens to an order placed by a guest who later registers. Ask who would own that design, because it falls between a commerce team and a core-platform team and is often left to neither.

When you compare proposals, check whether they name these four seams or bury them under "integration". The firms that name them tend to have been burnt by them, which is a better qualification than a certificate.

## Ten questions for the first call

1. Which storefront approach would you use for us, and which have you shipped in the last two years?
2. How do code versions, staging and data replication work in your normal release?
3. How would you structure price books and catalogues across our sites, and what would be shared?
4. What was the busiest trading event you supported, and what broke?
5. Show us a job you wrote and explain how you monitor it.
6. How do you test a checkout change, including payment and tax?
7. Who on the team holds the B2C Commerce Developer credential, and who holds the Architect credential?
8. How do you handle a change that touches both the template storefront and a composable storefront?
9. How would you limit the load your integrations place on us during a sale?
10. If we do nothing for twelve months, what is the main risk?

The last question is the honest one. A good partner will name a specific risk, not recite a sales line.

## Checking references and evidence

Ask for a reference who owned trading during a project, not the sponsor. Ask what happened in their next peak. Ask whether the codebase was easier or harder to change afterwards.

Ask for a code sample from a previous engagement, with client details removed. A partner who has to write one for the occasion is telling you something. Ask to see their pull request and review practice for a cartridge change.

Ask for numbers you can verify on a public site: page speed measured by a tool of your choice, not a slide.

## Commercial models and the statement of work

A fixed fee suits a bounded review and a single change. Time and materials with a cap suits integrations, because unknowns surface late. A retainer with a defined monthly capacity suits the unglamorous steady work of promotions, fixes and release support.

The statement of work should name the sites and environments in scope, the storefront approach, the named developers and architect, the testing and release process, the handover documentation, and an explicit statement that the platform is B2C Commerce and not the core org. Add a rule on code ownership and repository access from day one. Require a change freeze calendar around your trading events. Cost background is on [the Demandware licence page](/demandware-salesforce-licence-cost), and the commercial history on [what happened to Demandware](/what-happened-to-demandware). For connections to the core org, read [integrating Demandware with Salesforce](/integrating-demandware-with-salesforce). Salesforce's own description of the platform is at [B2C Commerce](https://www.salesforce.com/commerce/b2c-ecommerce/).

## When you can skip a partner

You do not need a firm for a banner change, a promotion set up in Business Manager, or a content update that a trained merchandiser can do. If you have a developer with the B2C Commerce Developer credential who already owns the code, small fixes are internal work. Bring in outside help for a storefront move, a performance problem, an integration that needs design, or before a trading event you cannot afford to miss.

## Questions

### Which credentials matter for a Demandware or B2C Commerce partner?

The Salesforce Certified B2C Commerce Developer for anyone writing code and the B2C Commerce Architect for whoever signs the design. The B2C Solution Architect credential helps if commerce must work with marketing, service or sales. Credentials do not prove peak-load experience, so ask about it directly.

### Is Demandware still supported, or do we need to move?

Demandware became B2C Commerce Cloud, and Salesforce's current pages describe both template-based and composable storefronts on it. Nothing in that record forces a move. Treat a move as a business decision, and hire first for a review of what you already run.

### Should we choose a composable storefront or stay on templates?

Form a view before you hire, because partners lean towards what they know. Template storefronts suit stable estates. A composable storefront suits teams that need a modern front end and can support it. Salesforce says you can phase the change, moving high-impact pages first.

### What should the first engagement be?

A release-readiness and performance review of one site, covering code versions, staging, jobs, integrations and your last peak event. It should end with a ranked risk list and a view on the storefront approach. A recommendation to change little is a legitimate result.

### Can a Sales Cloud consultant handle B2C Commerce?

Not safely, unless they have also worked on cartridges, Business Manager and storefront releases. The platform has its own code model and deployment process. Ask for B2C Commerce Developer or Architect credentials and a named reference from a live storefront.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).