Planning your move from Salesforce Commerce Cloud to Microservices

Enterprise software companies are struggling to adapt to the new wave of commerce software referred to as headless commerce. This new wave gives brands and retailers direct access to commerce APIs and microservices from cloud-based SaaS providers, freeing them from the technical debt, design constraints, and high costs of old platforms like Demandware (now referred to as Salesforce Commerce Cloud).

Realizing it couldn’t adapt its outdated platform to this new wave of commerce software, IBM sold its commerce platform called Websphere to HCL at the end of 2019. This was right around the time headless commerce was starting to gain traction. IBM knew it couldn’t transform its 20-year-old platform into a suite of microservices to support modern retailers and wisely folded.

Meanwhile, Salesforce is stuck with the old commerce platform it purchased for $2.8 billion in 2016 and rebranded into Salesforce Commerce Cloud. Sure, Salesforce gained revenue from large Demandware customers, but five years later there is no growing appetite for old commerce platforms like this. These platforms are often referred to as legacy or monolithic platforms because commerce services (cart, checkout, pricing, etc) are tightly coupled and highly dependent on one another.

In short, this is an old way of building and selling software. The new way is building and selling independent services called microservices and creating APIs so they can communicate with any other service without being dependent on them. This is what we build and sell at fabric. It’s also what Amazon has used to grow so fast. 

Demandware does not fit this model. But this is not stopping Salesforce from trying to make it appear like it does. Salesforce recently paid $60 million for the frontend-as-a-service company Mobify to add a headless CMS to their offering to make Demandware seem like a scalable commerce solution. Just remember: any platform can expose APIs and offer a headless CMS. Not every platform can do this and be microservices-based.

Why Demandware Does Not Scale

Even SMB commerce platforms like Shopify are trying to force their way into this new wave of commerce software. Like Demandware, Shopify Plus is a monolithic platform that merely exposes APIs. But even after checking the boxes for headless, their inflexible architecture remains too rigid to support modern brands and retailers. It also promotes vendor lock-in, dependencies, and single points of failure.

Monoliths like Salesforce Commerce Cloud don’t just lock customers into their pipeline based operations. They also keep customers blind from insights to be gained from domain-oriented logs. As an example, if Amazon depended on Salesforce as a commerce platform, it would’ve lacked innovation in bringing new features to the world (at the time) such as personalization, recommendations, 1-click checkout, etc. None of this IP would have been possible if Amazon did not have access and ability to experiment with its data. 

Not only do monoliths limit growth, they also advocate for a one-size-fits-all approach but it is to their benefit. I saw this live at Staples with IBM Websphere where we were held hostage to generic features designed for industry-agnostic use cases. We never ended up using a lot of this functionality and Websphere was incapable of providing any forward-looking solutions. 

In this post, I’ll present some points to consider before adopting a headless and microservices-based commerce strategy and list key considerations in transitioning away from monoliths so retailers can remove barriers to commerce growth.

Demandware reminds me of the outdated IBM Websphere we were using at Staples when I joined in 2013 as chief digital officer. Around the time I became CTO, we had started moving away from Websphere toward microservices with custom builds and a variety of open source software like Spring Boot. Unfortunately, reliable microservices-based SaaS created by commerce veterans like fabric was not around at that time.

One of the reasons Websphere did not scale for us is because SKUs couldn’t be more than six digits long. And when I asked why I was told “because our system can't handle it.” This was unacceptable as we had our vision on scaling to support millions of SKUs. Similar to how we abandoned our traditional IT organization, we abandoned this legacy platform and moved to microservices.

While I do not have direct experience with Demandware, below is what I do know about Demandware and there are obvious signs it’s not built for scale. Please let me know in the comments which technical challenges you are facing with it.

Demandware blocks access to new growth channels

If you’re a B2C retailer using Salesforce’s B2C commerce platform and want to grow by opening a B2B channel, you must purchase an entirely different B2B commerce platform or suite of features from Salesforce. This approach to feature-based selling blocks growth. To grow through B2B as a B2C company or vice-versa, you must enter into yet another slow, painful, and expensive contract. On the other hand, with platforms like fabric, you can create a B2B commerce experience with the same data and APIs you’re using for B2C.

Commerce is not a focus area for Salesforce

Salesforce has many offerings serving many different customers: Heroku, Tableau, and most recently Slack. But at their core they offer a CRM. Demandware is not their main product and will likely never be as well supported as their core software offerings. Also, when a business is split like Salesforce is, there's always a risk that Demandware could be sold off like IBM Websphere or shut down like Amazon Webstore. On the other hand, fabric is focused entirely on commerce because commerce is our business. This focus is what made the small business platform Shopify so successful.

Demandware is managed by CRM experts, not commerce veterans

At its core, Salesforce is a CRM company and it’s clear that Commerce Cloud is a “funnel” for upselling its marketing, analytics, and sales enablement products. Further, the popular software analyst Ray Wang said the acquisition of Mobify by Salesforce shows how desperate Salesoforce is to modernize “its monolithic Demandware platform.”

How Microservices Support Commerce Growth

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.

Microservices are flexible

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. The architectural constraints of yesteryears do not apply today. 

Microservices are fast

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.

Microservices are secure

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.

Moving from Demandware to Microservices

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. This is referred to as the strangler fig pattern, or, as we like to call it at fabric, the end of replatforming.

Step 1: Decide where to start

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. Below are some areas to consider.

Cart and Checkout: If your primary business goals surround increasing conversions, checkout speed, or offering new payment options, you should start your migration with cart and checkout. Compared to a product information manager (PIM), these are smaller services that are easier to get started with. They can also lead to some quick wins.

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.

Step 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.

Step 3: Migrate data

Before you “flip the switch” on your new service, you’ll need to move data from Salesforce Commerce Cloud 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. There are code snippets for getting started with this in this post.

Step 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.

Move to Microservices Faster with fabric

Demandware 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 can consider leaning on a third-party like fabric to provide some of the fundamental commerce APIs and applications.

We also offer an experience layer through Experience Manager (XM) to help you create unified buying experiences across channels. And since reinventing the wheel is rarely the best choice in software development, fabric can help you migrate your data from Salesforce, saving you a significant amount of engineering effort.

Again, while moving to microservices requires a good deal of initial momentum—whether that means abandoning groupthink or outdated IT practices—this is the future of commerce technology and what’s needed to gain market share, build for new channels, and create frictionless buying experiences.

To conclude, moving from a monolith should not be just about modernizing your technology stack. It should force every company to think about product-driven organization and domain driven design. This is one of the core reason platforms like Amazon and Alibaba are able to continuously stay ahead of competition.