Shrinking the problem with legacy commerce platforms

Legacy commerce platforms are still alive and running behind the scenes with many retailers. Each evolution of the commerce industry — from on prem, to cloud, to composable — comes along with the misperception that you need to replatform in order to make any kind of change. That leaves the commerce industry in a stagnant innovation cycle, unable to get out of its own way. What if there was a way to shrink the problem to solve with commerce legacy systems — replacing them step by step rather than all at once?

To answer that question, we first need to figure out how we got into this vicious cycle of replatforming. In commerce, outdated software systems are pervasive because they’re so painful to replace. Replatforming can cost millions of dollars and take months or years. So, they remain alive in the organization until someone has the stomach for a replatform, or the ability to convince multiple executives that the need is dire enough. Stagnation happens in spite of the fact that the customer experience suffers, marketers and merchandisers can’t act quickly enough to respond to trends, and IT teams get saddled with the burden of painful system maintenance.

How did we get here? The very first build-your-own eCommerce systems were replaced by monoliths like Oracle ATG. It’s important to note that Oracle ATG evolved a services business into a commerce product company. As a result, these implementations were extremely complex and customized, leaving them deeply entrenched even to this day.

In the next phase of migration, companies like Salesforce and Demandware capitalized on the promise of the cloud and SaaS making life easier for users, yet still required a painful rip-and-replace of custom components. Now these cloud platforms still live on in their complexity, just as the previous generation did.

You’d think the same pattern has to play out to embrace new technology like composable commerce, which promises flexibility, agility and a return to control for retailers. It’s time that pattern is broken. Yes, we can still have nice things, without having to shut down the entire operation on a replatform.

Identifying acute problems first

Instead of replatforming, it’s possible to break problems down into more manageable components, focusing on the most acute issues first. For example, a brand that wants to expand might choose to isolate a specific geography or product line to reduce the risk of replatforming.

They could build a custom landing page from smaller, API-connected applications, which can hook into existing technology, like an enterprise resource planning system. The goal, in this case, is to keep older systems running smoothly behind the scenes, while giving the brand an opportunity to expand quickly with a fresh customer interface. Over time, other components like the product catalog, search, cart, and more can be swapped for modern applications.

Retailers often have grand ambitions for a “relaunch,” where every feature they could dream up must be present in v1 of a project. The concept of a minimum viable product seems to have missed the entire industry. However, if you look at some of the most successful organizational change management stories across other industries, you’ll find leaders who have earned the right to influence a larger change. These shifts didn’t happen with a flip of a switch.

Reducing risk by shrinking the problem to solve

The exercise of shrinking the problem to solve works especially well for organizations with a low tolerance for risk. Legacy commerce systems stick around for a long time because of risk aversion. Issues like customer downtime, employee disruptions, or broken links in the greater supply chain are very real.

At the same time, risk aversion is oppositional to the growth mindset many companies hope to achieve. It’s nearly impossible to win against competitors, innovate, and avoid risk altogether. However, you can mitigate risk by choosing the parts of your legacy system to sunset phase by phase. Composable commerce is uniquely positioned to win in complex eCommerce systems, where a high level of customization would be too painful to replace all at once. The idea of smaller, API-connected applications even makes change management less painful in the future.

In some cases, it’s possible to migrate from a legacy system to modern application infrastructure without much pain — and potentially along similar timelines as a rip-and-replace operation. It takes a collaboration between IT and business stakeholders to define what’s possible, using an API-connected, composable infrastructure as the catalyst to make a change.