Ways to Modernize Legacy Application

Vytas Prazarkevicius
5 min readJan 12, 2021

In my previous post “Legacy Application Costs” I listed common costs and risks of legacy applications. In this post I will give an overview of different ways of modernizing those applications.

Every now and then engineering teams face situation when they need to decide what to do with a legacy application. Questions they often ask themselves are:

  • What if we keep the application as it is?
  • How should we modernize the application? Should we refactor it? Should we rewrite it from scratch?
  • What is the total application cost of ownership now? Are we able to estimate it? What will be the cost of ownership after the modernization?
  • Can we complete modernization project under planned time and budget? Do we have people with the knowledge and skills to make this modernization?

Decisions of how to modernize applications are rarely easy. High level of technical complexity, high modernization costs, business and technical risks are just a few challenges which need to be assessed. These challenges can also hinder engineering teams from being able to see the complete picture.

What engineering teams often do not pay enough attention to is the negative impact legacy application has on business. High costs of maintenance over time, low organizational efficiency and maybe even lost business opportunities are just few examples. Understanding this impact, however, helps when talking to business stakeholders.

Measuring legacy application impact on business is often difficult. It requires organizational maturity to define needed metrics correctly. It requires even more maturity to continuously collect measurements through longer periods of time. And some aspects aren’t just not quantifiable.

Business value as critical success factor

According to Chris Matts, there are only 4 reasons to invest into IT from a business perspective:

  • Increase revenue
  • Decrease costs
  • Protect revenue
  • Avoid costs

This concept can also be applied to application modernization projects.

For example, are we aiming to reduce costs of application maintenance? Then we need to determine what exactly makes the maintenance expensive. Maybe it is inflexible codebase, maybe outdated infrastructure. The cost driver of maintenance should drive decision of what modernization should include and, often more importantly, what not.

During the whole modernization process having clarity on business goals will be a key factor to achieve the expected business impact. Resuming the previous example about application maintenance cost reduction :

  • How to ensure that modernization substantially reduced maintenance costs?
  • How to keep focus on the work which impacts cost? Engineers love making application code cleaner or architecture more scalable in modernization work. However these important attributes of applications may not significantly impact the cost.
  • How to involve business stakeholders in prioritization of work so that most valuable items for cost reduction are worked on first?

Choosing modernization technique

According to Gartner research, the problems of legacy applications usually come from either technology, architecture or functionality.

Technology and architecture issues may cause application costs to be too high, the code too complex or create other risks (security, scalability, etc. risks).

If application functionality does not meet current business needs, then revenue growth or organizational agility opportunities may be lost.

A few examples:

Technology

  • The underlying technology is not supported by vendors anymore
  • The technology licensing is too expensive

Architecture

  • The application architecture maintenance costs are too high
  • The application cannot be scaled to meet the business needs

Application functionality

  • The new features needed by business users cannot be added

Identification of a problem source being technology, architecture or functionality helps further with a choice of application modernization technique.

Personally it was helpful to analyze the legacy applications and think if the problem comes from the technology (that framework we didn’t update for several years) or the architecture (that other app with spaghetti code) or the functionality (we just cannot have automated processing of PDFs the customers keep asking).

Of course in some cases it was a mix of two or all three problem sources. Nevertheless the exercise of thinking and discussing proved to be very valuable for a better understanding.

Gartner researchers also recommend to choose legacy application modernization technique based on problem source. The diagram below illustrates relationship between the modernization technique, the implementation effort and the expected impact. The diagram also helps to limit a number of suitable modernization techniques and put the focus on the most relevant ones.

What are the legacy modernization techniques?

There are seven modernization techniques in the diagram. The most known ones in the IT industry are refactoring and rebuilding. It is worth to look at all of them so that you can consider the best ratio between risk and reward.

  • Encapsulation — creating wrapping around a legacy application or its component that provides a new interface making it easily accessible to other software components. Small changes to the code make the risks minimal.
  • Re-hosting — moving application unchanged to other (usually cloud) infrastructure. This technique is of the lowest cost and risk.
  • Platform migration — adjusting the code to a new platform while preserving existing functionality. The minimal changes like using a managed database or adding auto-scaling.
  • Code refactoring — restructuring and optimizing application code without changing its external behavior.
  • Re-architecting — shifting to a new application architecture while altering the code to use the new capabilities of the platform.
  • Replacing — entirely replacing the app with a different tool rather than investing in its modernization.

Conclusion

The business value of modernization needs to be identified and shared by application stakeholders. Having clear business goals will help to define modernization scope and measure success.

By looking at the legacy modernization from different perspectives we decrease a risk of overpaying while still not solving the core issue.

Technology, application architecture and functionality are the three main causes of why legacy problems occur. The mapping between the causes and the modernization techniques helps to limit the choice and also balance between modernization effort and expected impact.

--

--