Moving from Salesforce Commerce Cloud to Microservices-Based Commerce

E-commerce has been changing rapidly in the past decade. We’ve seen retailers move from clunky on-premise software suites to the first wave of cloud platforms, but as with most things in tech, nothing stays the same forever.

“Today, we are moving into the 3rd wave of e-commerce platforms...3rd gen’s “headless commerce” architecture allows for immense scalability and customization by efficiently handling the front-end and back-end separately...It’s finally inexpensive to deploy, yet capable of delivering the most powerful, personal brand experiences in-store design.” - Scott Beechuk, Norwest

While many of the early cloud e-commerce platforms have bolted on APIs that allow customers some access to the underlying functionality they provide, they’ve built this on top of existing, monolithic architectures. This is true of Salesforce Commerce, and it’s one of the reasons that you might be looking at a migration.

In this piece, I’ll introduce more of the reasons companies are moving from Salesforce Commerce Cloud to microservices. I’ll share some of the major technical considerations you’ll need to make as you plan the transition, and I’ll offer you a look at how you might start this migration yourself using Salesforce Commerce’s export features and API. While every store is different, this guide will give you a starting point as you plan your journey from Salesforce Commerce to microservices.

Why Microservices?

While the initial momentum required to make a migration off Salesforce Commerce is significant, the long-term benefits of microservices can be a huge competitive advantage to companies that need to grow quickly and remain flexible. As you migrate to microservices, you’ll notice a few major benefits:

1. Flexibility - Need custom reports? Spin up a reporting service. Need a product importer? Deploy an independent microservice to handle it and ensure that long-running imports don’t slow down your user experience.
2. Speed - Performance has been an issue that Salesforce Commerce users have noted, especially in the admin areas. One of the most compelling reasons to adopt microservices is the potential to speed up internal operations. While you need to understand the latency implications of microservices, the fact that you can scale pieces of your application independently is invaluable in e-commerce.
3. Security - In 2020, Hanna Andersson’s Salesforce Commerce store was found to be infected with malware that allowed hackers to steal customer identities, credit card information, and personal addresses, which were then sold on the dark web. While microservices bring their own security challenges to the table, the isolation of each service can make the attack surface smaller and less appealing.

Replacing Salesforce Commerce

Once you know that microservices are the right choice, the next step is to create a plan to migrate each piece of your store from Salesforce Commerce Cloud to your new microservices. Because of its monolithic design, it isn’t necessarily easy to migrate from Salesforce Commerce, but by taking it piece-by-piece and starting with the most valuable functionality, you can start to see benefits early in the process.

Here is the approach you can take to migrate off Salesforce Commerce and onto microservices:

1. Decide Where to Start the Migration

The first step is to decide which of the components or services you need to replace first. This decision should be based on your business goals and an understanding of the technical lift required to migrate each part of your store.

For example, if your team is struggling to make bulk edits to products in your catalog, you might want to start with the PIM (product information manager). If customers are complaining about a clunky checkout process, you can start with the OMS (order management system).

There is a lot to building a scalable e-commerce data model, but here are a few of the pieces you might start with:

Product Information Manager (PIM)

A PIM is typically an isolated service that stores your product data, provides an admin interface to modify products, and interfaces with your various distribution channels. Because a PIM typically stores structured data (product names, descriptions, etc.) and rich media (images, videos, user guides, etc.), you will need a database and file storage system.

Replacing your PIM can be tough because it might integrate with several other key parts of your system, and building one from scratch is a lot of work. So, you might want to consider integrating with an existing PIM like Fabric’s. Using a robust, third-party PIM will help you get to market faster, plus Fabric can help you migrate your data from Salesforce Commerce Cloud.

Order Management System (OMS)

If your primary business goals surround increasing conversions, checkout speed, or offering new payment options, you should start your migration with the OMS. Your order management system will typically take incoming orders, process payments, track inventory, coordinate with warehouses and delivery providers, and allow customers to cancel or change orders in progress.

Depending on the size of your microservices, this might involve a few distinct services. Your OMS will need to store order and inventory data, connect with a payment gateway, hook into a transactional email provider to handle notifications, and process various events and fallbacks throughout the order lifecycle.

While having an OMS is critical, for most e-commerce companies, it’s not really a differentiating feature. If that’s the case, you can shortcut the microservices adoption process by adopting Fabric’s OMS instead of building your own from the ground up. Fabric gives you a headless API to process multi-channel orders, notify external systems, cancel and refund orders, and securely process payments.

User Interface

If the Salesforce Commerce Cloud UI is not providing the experience you want, you might start your migration with the frontend. In this case, you can decouple the Salesforce Commerce UI from the API and migrate to your own single-page application as a first step. Then, as you build the supporting backend services, you can swap out various parts of the Salesforce Commerce API.

Supporting Services

Another place you can start with is your application’s supporting services. For example, if you’re not satisfied with the personalization engine in Salesforce Commerce Cloud, you could replace it as a standalone microservice. If you need subscription options that Salesforce doesn’t support, you could build a pricing and subscription microservice first.

In addition to handling your core headless e-commerce microservices, Fabric also offers several supporting services including loyalty, offers, and subscription products, so you don’t have to build all of these yourself.

2. Build a Middle Layer

Once you’ve decided which part of your e-commerce application to replace first, you’ll need a way to “swap” it in for your new microservice. A common solution to this challenge is to implement an API gateway. Using the gateway pattern, you can abstract the interface to Salesforce Commerce Cloud’s API and replace each endpoint with requests to your new microservices as they go online.

As you move more of your application to microservices, another consideration you’ll need to make is how each service will be networked, monitored, and accessed. This problem gets inherently more difficult as the number of microservices you have grows, so many businesses have adopted the service mesh pattern to help assuage this.

3. Migrate Data from Salesforce Commerce to Microservices

Before you “flip the switch” on your new service, you’ll need to move data from Salesforce Commerce to your new microservice’s database. The easiest way to accomplish this is to export the requisite data from Salesforce Commerce, import it into your microservice, and then configure your API gateway to start serving requests through your API instead of Salesforce Commerce.

Exporting Data from Salesforce Commerce

Salesforce Commerce Cloud offers XML exports for each of the schemas they use. You can export your data via the Business Manager or Pipelets. The catalog.xsd schema, for example, contains all your products and custom attributes:

...
<product product-id="123456789">
    <ean/>
    <upc>123456789</upc>
    <unit/>
    <searchable-flag>true</searchable-flag>
    <tax-class-id>standard</tax-class-id>
    <custom-attributes>
         <custom-attribute attribute-id="color">navy</custom-attribute>
         <custom-attribute attribute-id="size">007</custom-attribute>
         <custom-attribute attribute-id="width">N</custom-attribute>
    </custom-attributes>
</product>
...

Importing Data into Your Microservices

Once you’ve downloaded the data that corresponds to the microservice you’re currently implementing, you can parse and import the data into your database. These files may be quite large, so you will likely need to load the data in chunks. Here’s an example in Node that uses the XmlStream library:

const fs = require('fs')
const XmlStream = require('xml-stream') ;
const stream=fs.createReadStream(catalog.xml');
const xml = new XmlStream(stream);

xml.preserve('product-id', true);
xml.collect('product');
xml.on('endElement: product-id', function(item) {
  saveToDatabase(item);
});

If you’re saving thousands of products and each insert takes even a second, this import could take a long time. Even worse, if a single record fails to save, the whole script will fail, and you’ll have to start over or try to figure out where it left off.

To combat this limitation, you can queue jobs up using a service like Amazon SQS in your saveToDatabase function:

...
const sqs = new AWS.SQS({apiVersion: '2012-11-05'});

const saveToDatabase = (item) => {
  const params = {
    // Add any parameters for SQS here
    MessageAttributes: item,
  };
  sqs.sendMessage(params, function(err, data) {
    // Handle errors here
  });
}

This example isn’t comprehensive, so be sure to read up on how to process and receive messages in SQS in the documentation.

4. Release, Test, Repeat

As you replace each piece of Salesforce Commerce Cloud’s API with your new microservices, keep an eye on your logs and error alerts. After each phase of the migration, you’re likely to find that adjustments are necessary, but comprehensive testing (automated and manual) can help you minimize downtime during the process.

Conclusion

Salesforce Commerce might have been a good starting point, but if your business needs more flexibility, security, and speed, microservices are likely the next stop in your platform’s evolution. While building your differentiating services in-house is a good idea, you might want to consider leaning on a third-party like Fabric to provide some of the fundamental e-commerce APIs. Reinventing the wheel is rarely the best choice in software development, and Fabric can help you migrate your data from Salesforce Commerce, saving you months of engineering effort.