Everything has a life and software applications are no exception. Legacy application modernization, re-hosting, re-platforming, re-factoring are few buzzwords being heard around the software industry. From ISVs to enterprises, everyone is talking about them. In a typical product life cycle, every product reaches a stage where it needs to modernize. We have seen even computationally intensive CAD and CAE products modernizing themselves and moving to the cloud. These are big decisions. We can compare it to replacing old machines in a manufacturing plant with the latest ones. Cost-benefits and RoI analysis drive such endeavours. I have been personally involved in many such transformational journeys. Let us look at various aspects of legacy application modernization.
Let us start with the main question – WHY?
Need for legacy application modernization
The underlying technology on which products are built evolves over the time. Compared to legacy products, modern products tend to leverage the latest and best in technology. Modern applications are generally faster, more robust and more efficient. In most cases, legacy products are not scalable, not available everywhere and not cost-efficient. When you are competing with modern applications, especially In the unforgiving consumer market, losing market share in the face of disruptive competition is inevitable. In a mature and crowded space like video conferencing, a product like Zoom walked in and took it by storm. In the world of applications, one also has to constantly look at the technical debt and keep on improving to stay relevant. Here are some more reasons why product owners think of modernization:
- Limited reach, scale, accessibility and uptime
- Inefficiencies due to sub-optimal architecture
- High operational costs
- Difficulty in terms of maintenance or upgrade
- Difficulty in adding newer functionality
- Incompatibility with other newer products due to limited backward compatibility
- Challenges in finding people working on older technologies
- Inability to move to newer business models such as ‘pay per use’
Because of these challenges, customer acquisition becomes difficult and market share is lost.
If there are so many concerns around older applications, then why are companies reluctant to modernize?
Reluctance to modernization
People have carts with square wheels and they are hard to push. They don’t change those square wheels to round wheels as they are busy pushing the cart with square wheels J
The following is not an exhaustive list. But here are some commonly seen reasons because of which product owners delay modernization:
- Why break something that is working?
- Lack of awareness of the latest and the best available in the constantly evolving technology space.
- Too much effort and cost to move the product to newer technological platforms.
- Other business priorities take precedence.
And most importantly – IT IS NOT EASY!
There are many decisions and investments, which have to be made. There is disruption.
Do you need product modernization?
We suggest the following thought process to our customers while deciding whether they need to go through modernization.
- Do you want to change the business model from Capex to Opex and move to SaaS like recurring revenue models?
- Are you struggling to react to customer needs because of old architectures?
- Is it becoming unwieldy and costly to maintain the product?
- Do your costs go up with scale? Do you need horizontal scaling instead of typical vertical scaling?
- Are you sensing performance issues?
- Are you struggling with availability, reach or scale-up issues?
- Are you struggling to onboard partners or the developer community, as your system is not compatible with modern API based systems such as REST and JSON?
- Is your system secure enough?
When our customers, the product owners face one or more of these issues, they are usually willing to look at modernization more seriously. Therefore, if you decide to modernize, you need to follow certain steps.
Re-hosting vs Re-platforming vs Re-factoring
Gartner talks about 7 options of modernization. Let us discuss the 3 most useful ones. As the name suggests, with re-hosting, you simply take the application and host it in cloud environment. It is quick but it does not leverage cloud capabilities much. Re-factoring is on the other side of the spectrum where you make the product cloud native leveraging micro-services. This really leverages cloud capabilities but it is time consuming and you get locked-in with the cloud provider. Re-platforming is somewhere in between where there are minimal changes in the code. This choice is critical. It impacts time & cost of switching and has long term business impact. In some cases, it may not be feasible to carve out microservices from an existing application. Instead, a microservice architecture with Kubernetes or Service fabric in Azure for normal services scalingis used rather than converting all services to microservices. All such decisions need thorough understanding of business challenges, goals and the existing product architecture to decide the best route to achieve RoI while keeping long term outlook in mind.
Approach to Application Modernization
Once a product owner decides that she needs modernization, we take our customers through the following steps.
- Not every product and certainly not every component needs modernization. Decide what components need to upgrade.
- Decide which components need re-hosting, re-platforming and which components need re-factoring.
- Work on the architecture and define the tech stack.
- Compute time & cost needed for development and perform a cost-benefit analysis.
- Know the current state:
- Build a good regression suite on your existing product so that you can test the new system against these tests. Baseline test input data and output baselines are also required.
- Baseline the performance of your systems in terms of load and response timings.
- Set new performance, availability and failover SLA for the new system.
- Plan how you will migrate your data/databases (sample migration, major migration, delta migration and then go live.)
- Engineer the modern product and migrate.
Of course, it is easier said than done. Many more steps are involved once you decide to take the plunge. Each product or system has its own specifications to be looked upon. I have just tried to cover and the most common scenarios.
As I said before, it is a big step. Considering the end customer environment, the challenges multiply. As this not only consumes time and money but also has long-term impact on business success. Real experience and expertise in product engineering is necessary for legacy product modernization.
I would leave you with some interesting modernization stories here. Every decently successful product has to experience this journey at some time. Happy modernizing!
Author
Prafulla Upase | Associate Director
Prafulla is a Microsoft Azure Architect (Technologies) with 20 years of experience in managing various stages of the Product Life Cycle such as Requirements Gathering, Analysis and Design, Development for Client-Server, Desktop Applications & Web and N-tier Applications on-premise and Azure Cloud.
