The term “Legacy Software” has negative associations – outdated, rigid, unimaginative. In reality, legacy software often offers real value.
From the user’s perspective, it is familiar and gets the job done. From the vendor’s perspective, it is a reliable revenue stream which requires no more than “maintenance-mode” attention and effort. The enterprise software market is filled with unremarkable software products that facilitate the completion of specific tasks in an efficient and economical manner.
Inevitably, for all software, this equilibrium will one day fall out of balance: the market will demand features and functionality that are incompatible with the current product due to limitations of the initial technology platform. For the provider of legacy software, this creates classic “innovator’s dilemma” – how willing is an incumbent to invest resources to displace its current product?
Many factors come into play: the level of complacency of the incumbent, the required investment amount, the skillset within the company to leverage new approaches and technology, the market opportunity.
Ironically, confounding this effort – or, at the very least, greatly increasing its expense – are the company’s prior achievements. The greater the success an incumbent has achieved, the harder it is to innovate. Not only does success breed complacency, it also creates practical challenges stemming from one unavoidable fact:
Legacy software comes with legacy customers.
This group brings creates drag in a variety of ways:
- Through their use of the prior software product, legacy customers have created data and history which will need to be migrated to the new product;
- As they are still using the legacy product, they will need to be supported until the time where the new product is finished and launched. Until the migration of users is complete and the legacy software is 100% deprecated, resources will need to be devoted to two separate products; and
- Legacy customers are demanding: they bring expectations as to how the product should work. These are not only the Innovators and Early Adopters who, by nature, are risk-taking and willing to weather reliability issues or a limited feature set in exchange for early access to a promising product. Rather, some of these users are Laggards who are risk averse, demand a full suite of product capabilities, are intolerant of bugs, and will require close attention when training on the new product.
The pace of disruption can be surprisingly sudden and is not always obvious. The incumbent’s challenge is to predict the moment when its legacy software is no longer tenable and design, build, and launch a full-service product ahead of that date. Pulling this off is neither easy nor cheap.