Seven Options Software Vendors Have When a Product Hits End of Life

In almost every case, an entrepreneur starts a company to build and take a single software product to market. Unfortunately, all software (especially enterprise software) has a lifespan. Sometimes that lifespan is just a few years (frontend JavaScript frameworks, for example), while other times that lifespan is a few decades (ERPs, for example). At some point, every software vendor is faced with the inevitable decision of what to do when its product hits its end of life. Software companies don't just die when their flagship product dies. Their existing customers, shareholders, employees and partners all have a vested interest in the company continuing to survive and thrive.

Before we get too far, I want to limit the scope of this article to enterprise software that is relatively hard to implement and intertwined with other systems - think commerce platforms, CMS, OMS, CRM and so on. I'll use enterprise commerce platforms as the case study throughout this article, as they're fairly representative of enterprise software and I have some good examples available.

First generation commerce platforms (1990's/2000's-era) have enjoyed a relatively long lifespan because they were hard to implement, they mediated access to the back end systems of record and were so deeply integrated with other front office products like search, content management and contact center. But like all enterprise software, these platforms have now hit the end of their lifespan. Since those first generation commerce platforms were first introduced in the 1990's and 2000's, the following major shifts have happened:

• Invention of REST APIs in 2000
• Introduction and widespread adoption of mobile (~2007) and other non-web channels
• REST + non-web channels led to headless commerce (~2013)
• Rise of "real" cloud which led to multi-tenant SaaS microservices (~2009)
• Real omnichannel retail

Every type of software has been rocked by similar trends over the past 20 years, though enterprise software has been hit particularly hard. In decades past, equally seismic trends rocked software like the shift away from mainframes to client/server and the rise of the internet itself. The only constant in technology is change.

If you're a software vendor offering a product that is facing imminent obsolesce, what are your options for proceeding? Let's explore.

Innovate on the Periphery and Invest in Marketing

Rather than directly confronting the technical issues that have made the product obsolete, vendors can instead innovate on the periphery and invest in marketing. Innovation on the periphery is best exemplified by flashy demos, vertical solution accelerators, re-skinned business user tooling, new SDKs and other things that demonstrate value without touching the core product. Those incremental "innovations" can then be marketed to extend the lifespan of the product.

Salesforce Commerce Cloud (formerly Demandware (formerly Intershop)) does the best job of this in the commerce platform space.

Oracle, Shopify, Adobe/Mageento and SAP/hybris have also adopted this approach to varying degrees of success.

It's a safe and honest way to extend the lifespan of a product, though it only works for so long. Eventually, the limitations of the underlying product come to the surface.

Pretend You've Modernized Your Product

As I've written about in the past, vendors claiming to have substantially modernized their products aren't telling the truth. You cannot retroactively break up a big monolithic app into smaller microservices. Your product cannot become API-first if your product was written before APIs were invented (in ~2000). You cannot retroactively make a single tenant app multi-tenant SaaS.

Yes you can innovate on the periphery (see above) but that is fundamentally different from rewriting large swaths of an application and changing its deployment architecture.

In the commerce space, IBM took this approach. Look at how they marketed IBM WebSphere Commerce V9.0 in 2017:

Microservices architecture, with lightweight, self-contained, distributed servers, supports horizontal scaling, parallel development, and utilization of modern, open source tools.

They ultimately dumped WebSphere Commerce in 2018, selling it to HCL.

Elastic Path did this until they caved and bought Moltin in 2020.

In many cases, the vendors taking this strategy are letting their marketing teams run unchecked. It happens, especially in larger companies, as marketing and product run up to the CEO through different management chains. In other companies, the approach is taken deliberately, as it does help to generate good press in the short-term.

This approach always fails when the market realizes that the product isn't actually modernized. A company's brand and trust in the market are valuable assets to lose.

Putting a Modern Shim Over a Legacy Product

If the core of your product is just too difficult to change, a great way of appearing to have modernized it is to put a wholly new shim on top of the legacy product. Developers interact with the new shim but the legacy product is encapsulated below.

Elastic Path did a fantastic job of this when they built Cortex in 2013 and put it on top of their legacy platform (circa 2001).

Demandware did the same when they used the core of Intershop as their foundation. If you can stuff the legacy code down far enough, it works as a strategy to prolong the life of a product. The issue is that these layers are just masks and the thorny legacy always shows through. No shim can make a legacy product multi-tenant, API-first, cloud native, SaaS, etc.

Add Adjacent Products

Another approach that is especially favored by the big vendors is to add adjacent products to the suite. Rather than just offering commerce, vendors can build or buy other vendors that offer front-ends, content management, search, configure price quote, etc. The goal here is to offer a basket of complementary products that are all welded together and sold together as a package.

With more products, the hope is that customers may overlook deficiencies in any single product. It's the "One throat to choke" or "One hand to shake" approach, depending on how you view your vendor.

This is another safe and (mostly) honest way to extend the lifespan of a product.

Pivot

Rather than trying to extend the life of a product, another approach is to simply pivot to an adjacent space that offers a higher chance of success. For example, Digital River pivoted aggressively to the payments space, completely exiting the Gartner Magic Quadrant for Digital Commerce platforms in 2020, after being a listed vendor for > 20 years.

While Shopify positions itself as a commerce platform, it's making serious inroads into payments.

Pivoting to adjacent markets is a great approach that's intellectually honest. Your customers know your position and can look for alternatives if your new approach doesn't meet their needs.

Dispose of the Platform

Another simple yet effective approach is to just sell off the product entirely. If you no longer wish to compete in a given space, there's no reason in continuing to pretend that you do. If you lower the price enough, you can always find a buyer for your asset.

In the commerce platform space, Microsoft essentially exited the business in 2007 when it started outsourcing its maintenance and development to Cactus Commerce. That platform was later purchased by Sitecore and now forms the basis of its B2C commerce offering. IBM sold off WebShere Commerce commerce platform to HCL in 2018.

Exiting a space you no longer wish to compete in is an honest way of doing business.

Slowly Replace the Product With a Modern Successor

In this approach, a vendor offers two products for sale at the same time:

1. The legacy product that's hit the end of its lifespan
2. The all-new/modern successor to #1

This is the worst approach to take and it never (ever!) works. A legacy product that's hit the end of its lifespan is used by hundreds or even thousands of the vendor's customers. Each of those customers are paying a substantial amount of money to the vendor for ongoing maintenance, hosting, professional services, etc. That revenue to the vendor is nearly all margin. Nobody wants to disrupt that high-margin revenue stream. That revenue is taken for granted and often subsidizes other initiatives. According to Brightworks research:

"Oracle derives 52% of its revenues from maintenance. Those revenues have operating margins of 94%."

Brightworks goes on to say:

"These revenues account for more than all of Oracle's operating profits. (Maintenance revenues do not have sales and marketing costs, they are for the most part, automatically renewed, they do not have R&D costs and they have minimal G&A costs). Without the golden steam of maintenance revenues, there's no stable, highly profitable and usually predictable Oracle."

Maintenance revenue and revenue from customers paying their SaaS subscription every single month are what make the software industry work. Nobody wants to tell the public market, VCs or PEs that you're turning off a large, highly profitable revenue stream.

When a customer shifts from your old product to your entirely new product, they always have to do a full re-implementation of the new product from scratch. At that point, they must be re-sold your new product. It costs a lot both in money but also organizational resources (people, focus, etc). In the transition from old to new, many customers are lost to competitors. Forcing your customers to buy and re-implement a new product is guaranteeing that many just won't come back. Customers adopt products in droves and they leave in the same way. Customers like to do what other customers are doing, especially in the risk-averse enterprise space.

Vendors can't do both. It's less risky to keep customers on the old product as long as possible. Vendors try to increase revenue by increasing prices once the customers are locked in and by other commercial shenanigans. Humans and companies are driven by short-term thinking. Nobody wants to stay for the 10+ year journey of building an entirely new product from scratch, killing off the old product, selling the new product to hundreds or thousands of customers and then being there to support them through all of the implementations. Most managers in a position to make such decisions would rather put in a few years, keep hitting their short-term financial targets and then leave when the going gets tough.

In the commerce platform space, Magento did this when they killed off their flagship Magento 1 product in 2020. Shopify and BigCommerce have built a substantial business in picking up disgruntled customers through the transition to the all-new Magento 2.

Why stick with Magento when newer competitors like Shopify and BigCommerce were built natively multi-tenant, SaaS, etc?

Elastic Path has struggled to get its customers to adopt its all-new Moltin product. In selling the customer references and features of its legacy product, while simultaneously selling the MACH-based architecture of its Moltin product, they've confused the market and fragmented their internal teams. Having to maintain a legacy product while building and taking to market an all-new product is extremely taxing to any organization and for the reasons I outlined earlier, not possible.

Hybris saw the the movement to MACH in 2014 (before the term was even coined) and to their credit, they built a great all-new platform called YaaS (SAP hybris as a Service). Technically, YaaS was far ahead of its time and was absolute the right product that would have allowed hybris to remain dominant for the next 20 years in the commerce platform space. However, their large sales force was paid far more to sell legacy hybris. For short-sighted commercial reasons, it never worked out and they killed it in 2018.

The correct but difficult approach is to just sell off or kill the legacy product so that the entire organization can focus on the new product.

Final Thoughts

As you have seen, vendors have a wide range of options they can pursue once their products hit end of life, some better than others. I realize that larger forces often dictate strategy (e.g. investors, boards, market conditions, etc) and that the decisions made often aren't mis-informed or malicious, rather they're the only options available at a given point in time to a particular organization. We at commercetools will some day face this issue and I hope we will have learned from all the great case studies available in our space. We owe a lot to these early pioneers, and with any luck we won't repeat their mistakes.

About commercetools

commercetools is the world’s leading platform for next-generation B2C and B2B commerce. To break the market out of being restrained by legacy suites, commercetools invented a headless, API-first, multi-tenant SaaS commerce platform that is cloud-native and uses flexible microservices. Using modern development building blocks in a true cloud platform provided by commercetools, customers can deliver the best commerce experiences across every touchpoint on a large scale. 

More information at commercetools.com.