Legacy Modernization – Are you asking the right questions?

legacy modernization

At CAPIOT, for over five years now we have been helping customers move forward by modernizing their ability to share data seamlessly across the organization. Increasingly, we come across enterprises desiring to transition from on-premise monolithic applications to highly dynamic microservices-based cloud native applications.

The first step for us in those conversations is to ensure that the right questions are being asked. Not just technical but also the people and process questions. In this post, I have touched upon what we see are key questions and approaches that organizations should ask  (or need to ask) to navigate this tricky terrain of legacy modernization. 

Before we dig in, a view on why legacy modernization is getting executive focus.

The short answer is – disruption. Every day, we see examples of how mainstream businesses are being challenged by digital natives who deliver better customer experience and innovate faster.

In a recent article by highly respected and trusted Uday Kotak (MD & CEO for Kotak Mahindra), talked about how the current financial system is being challenged to undergo cleansing, forced to evolve to new business models and transformation to ‘phygital’ – that is physical and digital. 

The same week we were in a conversation with a very large bank that came across a scenario involving a large part of their customer base from rural India. The customer base is tech-savvy but in true Indian fashion hates to pay any merchant charges for an electronic transaction. The bank then offered them UPI. The adoption was nothing short of amazing but that has left the bank with an interesting problem – how do you scale the core of the bank to deal with these microtransactions?  This is just one example of the problems they were facing.

Another interesting one, the very next day was when a fintech from Bangalore sent the same bank a file with 75,000 transactions of 1 INR each. There were heated conversations when this happened, hysterical reactions across the board. Details of this are best discussed in private on a Friday evening. Moving on.

This trend of increased speed of innovation and resulting business execution challenges isn’t isolated to Banking but is equally intense across verticals like logistics, travel, and insurance. There is evidence that the ability of the business to rise to the changing market dynamics depends on their ability to leverage their technology platforms. In short, the software is becoming a core differentiation. And more importantly, statistics is saying that high performing organizations deploy software faster  – up to 46x faster – the magnitude of the difference is huge.

To succeed means to move fast, and to move fast requires a fundamentally different approach to thinking and execution. So far so good but try doing that with legacy systems that do not support this fast-moving business need. Very quickly then comes the business case for legacy modernization that goes all the way up to the executive.

So there’s the need but the second problem then is that while innovation is key, in reality, businesses spend over 70% of their resources just to keep the lights on. This means resources are scarce for any modernization program that does not deliver new business value. However, this is when we come in and force the business to ask the right questions. With examples, we illustrate that modernizing these applications is important to deliver the differentiation needed and what is even more important, is to create a factory that can deliver new software faster. The better the factory, the higher the differentiation. What is important here is how does a business put a platform in play that allows delivery of this new system of differentiation while leveraging legacy investments.

With the questions around both needs for modernization and budgets asked and hopefully answered, let’s look at the what are the approaches and execution centric questions that the business needs to ask.

There are fundamentally three workable options to application modernization :

  1. Rehost: Essentially, moving the existing platform to a modern deployment platform. Lift and shift to a container orchestration platform and then use the platform to implement auto-scaling or wrap the app into the CI pipeline to get faster deployment cycles.
  1. Re-platform:  It means to move the existing workload to modern deployment platform. Create new or replace existing functionalities i.e. strangle the monolith. In his post, a step by step approach to get away from the legacy system –  Paul Hammant – discusses out how legacy strangulation is a proven way for moving forward.

Legacy modernization                 (Source: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/)

  1. Refactor: Complete rewrite from the ground-up. It is expensive but provides the most bang for the buck. It requires a lot of decision making around the approach, language, and framework before the first line of code is written. Highly recommended that one or two successful implementations are done before picking the refactor option. Sometimes we do recommend refactor but with a platform approach (details of this in a separate blog )

Which options work best is based on analysis and prioritization of business benefit and risk. However, empirical data from our engagements suggest that these 3 approaches are actually sequential steps to achieving a modern architecture. For example, applications that are large and complex, it is better that they are re-hosted first by leveraging modern deployment approaches and then incrementally modernized by leveraging approaches to legacy strangulation.

From a technology perspective, irrespective of the approach three key technologies play a critical role in the application modernization journey, they are – Containers, Microservices, and APIs. 

Containers help with deployment acceleration and reliability. Microservices provide the separation of concerns and glue that brings various functionalities of apps together. There is a lot of material on the web that discusses the characteristics and nuances of microservices architectures. Combined together, automated deployments, containers, microservices, and APIs allow deployment of software functionality much faster. More so, they not only ensure that the code gets to production faster but also can be rolled-back equally quickly in case of problems. Approaches to deployment like blue/green or canary are native and create a strong differentiation in an organization’s ability to move fast.

Note, I am not suggesting moving to a microservices app, in fact for several organizations it may actually be better start off with creating a fast-moving monolith that can be changed and deployed several times a day. This is in some sense creation of deployment automation culture before bringing in the independently deployable capabilities. 

Which approach, how to design and go through the program of work for application modernization, requires answering several questions that range from discovery to organizational culture to technology decisions, I have listed some of them here to demonstrate the range and depth of thinking that needs to be done:

  1. Has the organization defined an overall business objective, that is detailed and measurable
  2. How do we organize a discovery session so that we can define a measurable business goal for an application modernization initiative?
  3. Where is the majority of the application budget going today? If more than 80% to keep the lights on then deployment automation i.e. re-hosting can help? This releases resources for improvement or strangulation.
  4. What kind of organizational structure and culture changes are required to have a fast-moving modern software factory environment?
  5. If we did a pilot, what would a successful pilot look like?
  6. What is an effective API strategy specifically from a legacy leverage point of view?
  7. How do we ensure that the API strategy rollout does not overwhelm the legacy system (bound to happen)?
  8. How do we ensure that the data required from various silos are available for the modern application?
  9. At what point do we start strangulating the legacy application?
  10. How do you make legacy systems and the new age microservices-based applications work together?

Answer to each of these questions is probably a blog post on its own. I’d be happy to talk through these in detail, so do reach out if you’d like to know more. 


At CAPIOT, we offer a six-week lab that focuses on application modernization. During these six weeks, our platform engineering team works with your IT  and business team. Together they build proof points that leverage cloud native technologies and agile practices to solve real problems.

Key outcomes being – your team has firsthand experience in using open source technologies, rapidly build of prototypes and adoption of agile workflows to deliver an application modernization initiative. This lab provides access to a proven and repeatable way for modernizing apps.

Application modernization initiatives are more than just technology. Most complex decisions actually are around people, process and data. To learn more you can get in touch with us at info@capiot.com or call us at +91-77778-88673.



Author Bio: Hitesh Salla is the Co-founder and CCO at CAPIOT. He has extensive experience in architecture, design, development, and delivery of ESB and API led connectivity solutions in complex environments.