A large enterprise software company was the established standard in its market, with overwhelming market share. Its institutional customers had invested millions in the software and millions more customizing it for their workflows. Yet it was losing share at an alarming rate to a smaller, less well-funded competitor whose product was faster, easier, and more intuitive.
The Buyers Weren't the Users
Purchasing decisions were made by senior people within the institutions; however, the employees and customers who used the product preferred the newer interface. Those users did not have purchasing authority, but they could take their business elsewhere. Their dissatisfaction eventually reached the institutions and then the incumbent vendor.
The incumbent still had an enormous advantage. Customers had invested heavily in customization and employee training, creating substantial switching costs. There would be no overnight exodus, but the company still had to ask whether new institutions would choose it and whether existing customers would invest again when major changes became necessary.
Potential Acquisition
The company was an acquisition target, and I was one of three people performing technical diligence. The potential acquirer needed to know whether the incumbent's installed-base advantage could be rescued.
The strategy seemed straightforward: overhaul the product and offer it to the existing customer base before erosion got any worse. A difficult technical question lurked inside that strategy: what would happen to all the customization?
Customers had already spent enormous sums tailoring the old product to their requirements. Could that work be carried forward into a substantially improved interface? Could the conversion be automated, or would modernization require extensive manual work for every customer? The answer would determine the time and cost required to compete.
The Enterprise SaaS Paradox
An enterprise-product team cannot know every requirement at the outset. Even customers may not know what they need until they use the software. A requested feature may initially look customer-specific and later prove broadly useful.
Suppose customer 1 asks for A, B, and C. The vendor must decide whether to add those features to the core product or keep them custom. Customer 2 then asks for C, D, and E, and customer 3 asks for C, F, and G. Feature C now looks like a candidate for the core. But customer 4 may want C implemented differently.
This is the hard job of the product owner. Updating the core makes deployments faster and higher margin, but bloating the core can bury the company in development and QA expenses.
Compatibility Is a Double-Edged Sword
For decades, the incumbent had protected its customers' investments by retaining compatibility with prior versions. That discipline helped it remain dominant, but the product still reflected assumptions made when it was first conceived.
The smaller competitor had no historical architecture or installed base to protect. Its developers could begin with what the market had learned and design the product around current expectations. Users preferred the result.
The Diligence Question
My work was not to determine whether the competitor had a nicer interface. The potential acquirer asked what it would take for the incumbent to catch up.
I studied how the product was architected, customized, and deployed, then evaluated the work required to move from the existing platform to something that could compete effectively with the newer entrant.
The incumbent's market share, customer relationships, and switching costs were genuine competitive advantages. But they were also buying time for a modernization effort that could no longer be postponed.
That meant understanding not only what needed to change, but how much of the existing investment in customer customization could survive the transition. This included estimating the time and money required to make it happen. Our assessment shaped the acquirer’s decision.
See other Legacy Modernization: Legacy Monolith · Sustaining Workload
