Life Cycle Extension

How to go forward with an existing software product

When startups create their first software product, they begin from scratch, allowing them to use the latest available technologies. That means that they have multiple resources available, helping them kickstart their development, design, and validate their lean MVP going on to disrupt markets through innovation. But what about the majority of the software companies that have been around for years having built their applications that no longer use the most innovative platform, architecture, and technology? How do established software companies keep up with changes, market demand, and remain relevant in today’s volatile market?

Definition of Life Cycle Extension

Lifecycle Extension is any modification that is needed and performed on a legacy application bringing it in line with the requirements of the business.

Established Vertical Market Software (VMS) companies have two significant factors that every startup dreams of having. The most important differentiator between a startup and an established company is the customer base and the revenue scheme that comes with having a customer base. The second most important differentiator is the application itself; most of the time this is a featureful, functionally complete application providing value so that customers are willing to pay a monthly or yearly recurrent license fee to use it.

This also implies that there is at least one software solution creating that value, which is mature, and the original codebase can be traced back to one to four decades.

You have to manage the product so that its value and market position is preserved for as long as possible. And there are many different approaches to maintaining the value of your solution, otherwise described as extending the life cycle of your product. Our past experiences in this area and research of Life Cycle Extension programs at VMS companies have taught us the following:

1. Consider the different approaches (from complete rewrites to a new modern-day UI/UX design), costs, and timeline carefully
2. Ensure business-as-usual for your customer base by splitting the current application and customer service from the Life Cycle Extension program.
3. Watch out for pet projects that don’t focus continuously on value creation and market demand and which will harm your RIO.

Extending the lifecycle of your product sometimes may require a rewrite or migration, but it is not the only choice that VMS or software product company have to remain relevant in the market and keep the competition at bay.  There are other lean and less intrusive approaches which may be appropriate for your solution.

Legacy applications

There are many definitions describing a legacy application: from the typical obsolete and outdated system to an application without unit. Generalizing the term, we can say that legacy applications have been around for a long time and are based on technologies and platforms that were modern in their time but have since been overtaken by one or more new generations.

Furthermore, there are relatively young (a couple of years old) applications built on modern technologies and architecture that have gathered so much technical debt and are based on poor architectural decisions that they provide less value than much older applications which are more structurally sound and thereby flexible,  easy to maintain, and upgrade.

To simplify matters, when discussing legacy applications, we refer to applications that have already proven their value to customers and generate revenue. In a VMS company, a legacy application represents a core of the value.

Strategy

Before even considering any Life Cycle Extension solution, you need to have a clear picture of the objectives. Sometimes it is difficult to navigate between different options that make sense for a solution. But we can simplify the process by using two criteria to determine the strategy for dealing with the extension of the application:

• Criterion 1:
  • Does it meet the business needs and how?
  • If not, how does it differ from the market needs?
• Criterion 2:
  • How much pressure is there on the R&D costs from extrinsic factors like platform licensing fees, a lack of available platform developers, an increase in cost and availability from the platform developers, slow release cycles due to the platform, technology or technical debt.

Figure 1: Life Cycle Extension strategies

Do-nothing

If your application meets the business needs, it is not in a commoditized market, or it is a best of breed solution, it still allows rapid development cycles at reasonable costs, and there are no risks from a platform and availability of developers’ perspective, then your application is probably in a sweet spot that requires no major change. This means you can “Do nothing” or rather keep doing what you are doing.

Modernization

Over time, the world and your particular vertical segment have moved into directions that you can no longer sustain with your current platform or architecture like having a native application, but your customers ask for web and/or mobile functionalities. Or your customers demand changes in your applications that are fundamental. For example, they are no longer satisfied by a data-driven interface, and they need help and guidance with their processes so a more process-oriented interaction with the customers would make sense. Then perhaps a “Modernization” would enable you to bypass current limitations without fundamentally replacing your complete solution.

In a modernization, your current system does not need to be moved but may be redesigned or upgraded in its current environment.

Replacement

However, if during the past years the market has become crowded with multiple featureful solutions that already answer your customers’ requirements better than your application does, then replacing your solution with an external one (through mergers & acquisitions for instance) might be the most cost-effective answer.

Migration/Transformation

If functionally the application is in order, your customers are happy, but your R&D costs are difficult to sustain because your platform vendor is squeezing you with licensing fees that have gone through the roof because their customer base is shrinking while their operating costs have not. Or maybe your whole core development team will retire in the following years, and it is impossible to find new and young developers willing to work on your platform. If all mentioned above rings true, then maybe a “Migration” would be your best option.

A migration means moving a system from one platform or environment to another, without intentional system design changes. The target platform or environment is superior to the current one due to e.g., better costs, performance, security, resilience, or supportability.

Most of the times, when a migration is performed some less than perfect areas in a solution will need to be adjusted. That is the situation with the “Transformation”. A transformation is a combination of both migration and modernization. The core of the original system may be preserved, but it is moved to a new preferred platform and is also improved by design to increase the functionality and capability.

In upcoming articles, we will dive into each of these strategies and highlight best practices and recommendations as well as discuss antipatterns that should be avoided.

Remus Pereni
CTO