Moving from Salesforce Commerce Cloud (formerly Demandware) to Shopify Plus (and also BigCommerce as well, to a slightly lesser extent) is becoming a big trend at the moment, with Shopify improving its offering in the mid-market space significantly and representing a considerably lower cost platform option. 

A few years ago there was a surge in smaller brands moving to Salesforce Commerce Cloud and these are the ones that I’ve seen primarily looking at alternative options, with an objective of being more agile with new feature development and generally gaining a bit more control over their store (as well as reducing and re-aligning costs). Examples of recent migrations include Gaiam, Crabtree & Evelyn, Hypnotik and The Cambridge Satchel Co.

We’ve had a number of conversations with Salesforce Commerce Cloud retailers (generally brands) about moving to Shopify over the last few months and we’re also currently working with a couple currently – I decided to write this post to highlight some of the key considerations. 

At this point, you’re probably aware of some of the key business benefits of moving to Shopify Plus, with the two biggest ones being agility (things that can take months, can take days) and total cost of ownership (particularly around optimisations and new feature development, as well as licensing obviously). There’ll definitely be compromise in moving to Shopify, but there are some significant benefits also.

Overall, Shopify is a far more simple and lean eCommerce platform than Salesforce and a migration is likely to require you to look at a number of aspects in different ways, particularly with third parties being such an important part of a Shopify Plus technology stack. The average Shopify Plus build will probably have 10-15 core apps and third parties, with Salesforce Commerce Cloud have very few, if any.

The points below are ones that I think need to be understood going into the migration – please feel free to suggest any others in the comments below.

International store setup + separate price books / files

This is a big one, as Salesforce Commerce Cloud has a robust, established offering in managing multiple stores and individual currencies. Salesforce Commerce Cloud offers the concept of both separate stores and separate price books (which you’d use for currencies), which are easily managed at different levels via the admin interface.

With Shopify Plus, you don’t have a like-for-like situation, with individual stores operating almost entirely independently and currencies (currently) only being manageable via a fixed exchange rate / conversion, with basic rounding. However, the fixed price multi-currency features are going into beta now, so this isn’t something to get too hung up on – you can also achieve separate price books via a third party called Reach, it just adds a bit more complexity around integrations. 

With the independent stores, this is just a different way of thinking really – each store will have separate setups, apps, product IDs, API keys etc – however, this is definitely manageable and there are various third parties and approaches that can reduce the associated overheads. For example, there are sync’ing apps to help with passing / updating data between stores, you can use your ERP more effectively, a third party PIM can help with product data, lots of apps have the ability to work across multiple stores and there are solutions like Excelify to help make CSV imports easier. You can then also manage your themes etc at a global level.

Lots of people get hung up on this (and it definitely does take some getting used to), but it’s generally not as bad as it may come across once you’ve defined some solutions and put a good architecture in place.

Product / catalog data nuances

In Salesforce Commerce Cloud, there are a number of different types of products that allow for complex relationships between different products and variants. Salesforce Commerce Cloud also supports the grouping of variants, bundled products and product sets – allowing for a lot of complexity in product data and things like advanced configurable products (particularly useful for fashion). You also then have advanced product attribute settings, the concept of attribute groups, built-in features for manaing sizing and colour etc.

Overall, the product management side of Salesforce is pretty strong and natively supports quite a lot of complexity. 

Shopify is very different to this and is based on a single standard product type which is then extended via variants and tagging (and metafields, which we’ll come on to). Product variants are exactly what you’d expect and are generally used for things like sizing (and occasionally colour, depending on how you set things up). Variants can carry independent values for things like SKUs, images etc. You then also have a set of standard fields against the product for things like descriptions, type, barcode / MPN / GTIN etc.

You would then use tags in place of product attributes, so a standard product could have tags like:

  • Brand: nike
  • Material: cotton
  • Gender: mens
  • Sale: yes

These are just a few examples, but the core product data in Shopify would generally be managed like this and then used for things like filtering, smart collection rules, front-end bits, merchandising logic etc. You then have metafields as external data points that can be used to store additional data, such as richer text content, videos, specifications etc. Almost all of our clients would use metafields on products.

For things like the product relationships, e.g. colour (that Salesforce allows for), you’d generally use theme logic and tags to simply link between separate products. You’d then also use Shopify scripts to allow for things like bundling and tiered pricing etc. 

Overall, Shopify isn’t as polished as Salesforce Commerce Cloud when it comes to the catalog management side of things, but it’s fine and perfectly manageable when you get used to the formats and principles. You can also use Excelify (a more advanced import / export solution for Shopify) to help manage product data migration (that’s how we’d generally handle this). I actually quite like how much freedom you have with Shopify data compared to platforms like Salesforce and Magento – there’s more room for error, but it’s easier to architect different types of solutions without the need of a developer. 

Other Shopify users choose to move product configuration to React.js or Vue.js to create a faster, cleaner experience that also scales beyond Shopify’s variant limit. Examples of this include:

This can be done with any platform, but it’s getting more common with complex merchants using Shopify Plus.

Payments 

This has been one that has come up every time I’ve been speaking to Salesforce retailers about making the move – with most of them using a third-party payment provider like Adyen and ideally wanting to keep it. Adyen (very commonly used alongside Salesforce Commerce Cloud), in particular, doesn’t play well with Shopify (doesn’t have a direct integration), however, there are options if Shopify Payments doesn’t work out for you (Stripe and Worldpay being two good ones).

The majority of Shopify Plus customers use Shopify Plus on at least their primary stores, because of how well integrated into the platform it is and how simple it is – it definitely does have a lot of benefits overall. The rates for Shopify Payments are set, but you can negotiate a little bit if you can prove that you’re losing money by making the switch.

This is a very different way of looking at things with Shopify, but overall, Shopify Payments remains fine and still has all of the core functionality that a third party payment provider would offer, as well as the same technical capabilities, they’re just available within Shopfiy and via the API.

Less focus on native features and more need for apps 

The biggest difference between Salesforce and Shopify for an eCommerce team is going to be the reliance on apps with Shopify, which isn’t a bad thing, it’s just very different. 

Salesforce Commerce Cloud has always been pitched as a solution with very strong native features around things like catalog management, promotions, search and merchandising, international, gifting, marketing etc – whereas Shopify is more of a shell, that’s then developed via apps and third parties. 

Some examples of features that are native to Salesforce Commerce Cloud and would require an app in Shopify, include:

  • Filtering – we’d usually use BoostCommerce as it allows for an in-line product grid (others rely on JS) and is pretty flexible and feature-rich
  • Gift cards – Shopify natively supports gift cards, but you need to use an app or extend to send directly to the recipient.
  • Imports – as above, we’d generally use Excelify to allow for richer and faster imports / exports.
  • Search & product recs – Where Salesforce has Einstein across product recs, search and categories, in Shopify you’d use separate third parties, such as Klevu (search) and NOSTO (product recs, amongst other things)

Data migration

From the above product data section of this guide, it’s clear that there is going to be very different data structures here and you’re likely to need to spend a lot of time in spreadsheets to migrate your existing data. Some fields will just need headings changed, but the attributes in particular will require a bit more work.

Customer and order data is likely to be the same – with Shopify having fairly limited fields compared to Salesforce Commerce Cloud. For customers, you may need to use a third party app to allow for custom fields, just to ensure you’re able to pass across all data you have. An example of a field that isn’t natively used in Shopify could be ‘title’ or ‘date of birth’. You’ll also need to think about how you migrate things like opt in data (against customers), if relevant.

Order migration in Shopify can be tricky, but this is always the case when moving platforms. There’ll likely be a lot of manual work involved here, but I would personally say migrating your order data is hugely important, as lots of people seem to compromise here. The EZ Importer app has been useful to us a few times with order data migration.

SEO Flexibility & Migration

Another pretty big restriction for Shopify is on the SEO side, with fixed URL structures, no ability to edit the robots.txt file, forced URL structure for separate international sites, no multi-store offering to support hreflang etc. These are fairly big issues, but can mostly be addressed via workarounds. 

Salesforce Commerce Cloud is pretty weak out of the box from an SEO perspective (lots of parameters nad dynamic page types that need to be addressed), but it’s very flexible and it can be fully optimised with work.

When actually migrating, this is probably the most important thing to focus on, as there’s going to be a huge amount of change with the URL structures and international domains (e.g. most SFCC users would use sub-folders, which can’t be achieved in a scalable way with Shopify Plus). As long as you plan and manage this well, it can be done well (be it with some risk), but it needs a good level of time and financial investment to ensure it’s done properly.

APIs and integrations 

Shopify have a very standardised set of APIs available across the platform, which is actually really nice to work with. All of the APIs are very well documented (online) and they’re in the most part very easy to work with and allow for most standard needs. 

A lot of people talk about the API limits with Shopify Plus, but I’ve never really had any issues with this, you would just need to allow for these when using the APIs – for example, if you’re importing millions of orders, you’ll need to give yourself enough time. I’ve never really seen anyone hit the limits with standard integrations etc. Overall, I think Shopify’s APIs are better than most expect them to be.

For major integrations, most Shopify Plus stores would use a third party platform / service, such as:

With Salesforce Commerce Cloud, I know there’s an increasing amount of people using Mulesoft, which is a more enterprise version of these integration platforms. These platforms / services differ in terms of service and how they operate (iPaaS vs standard integrations) and they’re generally used to integrate ERPs, WMSs, OMSs etc. 

—

If you have any additional points or questions, please feel free to email me or add them in the comments below.