The elephant in the room for many technology companies is their legacy software. Revenues are reasonable, but there is lots of potential for growth. The problem is that the elephant prevents further growth at an accelerated pace.
Replacing a legacy product or service is no easy task. To replace or not to replace is often the quintessential question. Unfortunately, the answer is rarely straightforward. Real business reasons and return on investment are necessary to embark on the quest to modernize software. Some legacy software can have a longer lifetime, but most are cause for concern.
What is legacy software?
The simple definition, according to Michael Feathers, is “code without tests.” The harder definition and one that factors in business rationale is an older system, often on less-frequently used technologies, that impacts business results in negative ways, such as customer satisfaction, decreased revenue, inhibited growth, or slow time to market.
Some key questions to consider when determining whether to address the legacy software problem head-on:
- Are there obsolete components that are no longer supported? Lack of support of technology or component means that finding resources with the right skills is more difficult. Obtaining fixes may not be possible, particularly if the source is not open.
- Are there obsolete components preventing upgrades to various other systems or inhibiting performance? Older technologies that are restricted to 32-bit environments may prevent operating system upgrades or adversely affect overall system performance.
- Are there continuous reliability concerns affecting customer satisfaction? Legacy software often suffers from “fix it here, break it there” syndrome. The battle for stability is never-ending.
- Are there issues with the user experience causing customer attrition? Even enterprise software today must satisfy the end-user the same way that consumer software does. Gone are the days where users put up with shoddy experiences because it’s better than nothing. Mobile applications, for example, must behave as consistently and reliably as any other applications on the platform.
- Is the lack of modern approach pushing potential new customers to competitors? Like it or not, users are attracted to well-designed user experiences and user interfaces, and a new solution with a modern look and feel often wins out vs. older-style applications.
- Is technical debt out of control? A multi-million-line legacy application that lacks any kind of test or deployment automation slows down shipping and introduces significant quality risk. Business logic code centered in the database is difficult to test and maintain.
- Are there inefficiencies in enhancing the system? Poor design, including monolithic design and poor coupling of components (a change in one area affects many components), significantly slows down the development team.
- Is it difficult to integrate with other third parties? Legacy software often does not have a robust and usable API in place, and that creates difficulties for a services team or other developer to hook into the application. As a result, all customizations are done in-house, potentially creating separate code bases.
- Is it difficult to attract and retain key people? An older system built on COBOL, for example, causes recruiting difficulties due to the older technology and general absence of developers in the market. A newer system based on technologies that the “cool kids out of school” are using eases recruiting and the acquisition of good engineers.
- Are there business-critical resources whose departure would be costly? Legacy systems built by long-tenured employees with little documentation introduce significant business risk. A new system built the right way, makes technical knowledge more pervasive.
- Is the customer on-boarding painful? Code that only supports customization vs. per-user configuration without source changes is slow to deploy and introduces maintenance difficulties with multiple versions of the product.
If the answer to some of those questions is a definite “yes,” it may be time to undertake a project to replace the older system. Some key considerations are:
- Is the product or service intended for cash-flow or growth? If cash flow, perhaps a significant effort to replace is not worthwhile. However, if the product or service has growth potential, undertaking a replacement effort sooner rather than later may be beneficial.
- Is time of the essence? Are competitors consistently winning? If competitors have newer offerings that are leading to wins in competitive situations, a solution is needed quickly. This factor is a key contributor to determining the approach.
- Is a seamless migration strategy needed? In most cases, yes. Consider how customers will migrate from the old system to the new one. The effort and complexity to support seamless migration could be extensive.
- Do existing customers need continued incremental value? The old system may need maintaining while the new one achieves feature parity.
- Is the preservation of monthly recurring revenue a requirement? Again, maintaining two systems may be necessary. Consider the resources and cost in doing so, along with how long this situation will last.
Once the go-ahead for replacement is decided, and key considerations are outlined, some potential options for replacement are:
- Wrap existing components with APIs. Exposing new APIs that wrap external functionality may solve some issues in the short term. For example, if integration is a pain point, using modern technologies to implement RESTful APIs may help a services team or third party developer customize or integrate with the system in more reasonable ways. However, if issues are deeply rooted in the architecture (e.g., the database), API wrappers may not lead to desired business results.
- Big bang replacement. Lock some engineers in a room for many months to replace the system. While attractive and seemingly efficient, this approach rarely succeeds. Many benefits of a more Agile approach are lost, such as quick and continuous feedback and early delivery of business value.
- Incremental replacement. Take functional vertical slices through the system (e.g., one of a suite of applications) and build it out to achieve a “minimum viable product (MVP).” Bring new customers to the new increments and migrate existing users as appropriate functionality comes online. This approach minimizes risk and gains many of the advantages of Agile development such as frequent feedback, leveraging learning for future increments and faster delivery. There is a risk of re-work, but that risk exists in all the options as real-time learning continues.
Legacy software is a problem that plagues most technology companies at some point in their lifetime. Thoughtful consideration of reasons for replacement and careful examination of the options is the key to future business success.
