How To Implement Legacy Code Modernization

Posted by Pete Heard | January, 19, 2017

In this article we will discuss Legacy Systems and Code Modernization which is often the Achilles’ tendons of organisations that are undergoing large scale Digital Transformation. From there, we will go on to discuss some high level strategies for dealing with this modernization.

What We Will Cover:

  • What Are The Characteristics of Legacy Code and Systems?
  • What Problems Do They Pose?
  • An Action Plan For Modernization
  • Conclusion

What Are The Characteristics of Legacy Code and Systems?

Legacy systems and the associated code that runs on them can be categorised in a number of ways. Generally, they exhibit some key characteristics such as:

  • Undocumented and Vendor Specific

The applications are undocumented and are using vendor specific implementations (such as frameworks, utilities and tools). They are connected through IO on the same machine or set of machines.

  • Fragile Internal Designs

Quite often changing these systems will be difficult because there are deep architectural issues within the code. Software Coupling is rife and it is difficult for software developers to understand any single part in isolation.

  • Little or no Automated Testing

There may be little or no automated testing with these systems. This compounds the internal design issues somewhat since it becomes even harder to change them.

  • Limited Access to Them

They may sit within teams or departments that have taken over ownership but can’t easily provide access to them for various security or operational reasons. They will often be deployed in a live or near live environment and perhaps their development environments have been poorly maintained.

  • No Boundaries or Modularisation of Subsystems or Code

It’s just one big ball of tar! Unfortunately all of the above contribute to an unhealthy application that is just one big mess. There is no modularity so trying to upgrade or improve parts is very risky.

An example of a jumbled mess of concerns on the left and a neat well abstracted design on the right

What Problems Do They Pose?

Legacy code isn’t an issue if it isn’t causing any problems. Just because something is old does not make it inadequate, especially if it is serving a purpose, but what are some of the problems that legacy code can cause? Here are a few:

  • Cost

According to a study by Forrester, 75% of North American and European enterprise IT budgets are expended on ongoing operations and maintenance, leaving a mere 25% for new investments. Simply put, this considerable cost is eating up businesses ability to innovate and bring new products to market. This leaves your business exposed to threats from competitors simply because your applications are so cumbersome!

  • Risk

It’s quite possible that simply not upgrading or being able to easily change your legacy systems means that your day-to-day business operations will be impacted upon. This is obviously a cause for concern, especially in larger companies with interconnected departments that have a high reliance on IT in order to carry out their work and create revenue.

  • Process Loss and Data Security

Quite often organisations can have intricate business process rules wrapped up in large fragile code bases. Because their systems are undocumented this can pose a problem since if they are to be replaced, they are difficult to test. Added to this, security violations and or data protection problems can emerge because of this ‘black hole’ of knowledge.

  • Skills

With outdated systems or even code that isn’t de-coupled from outdated systems, legacy systems can create staff resourcing issues. Older technologies may have fewer people available that understand them and companies may have to rely on vendors to provide expensive maintenance contracts or consultants.

Choosing an Effective Strategy (Eliminate, Replace or Modernize)

In a recent survey of insurance firms by BT Global Services, the firm’s researchers reported that although legacy systems were affecting the ability of insurance firms to generate new business, only 42% said they would rather adopt new systems. Some 37% said they planned to upgrade old systems.

In order to scale your Digital Transformation projects successfully you are going to need to come up with a plan for your legacy systems. One tool that helps you plan is the Gartner TIME Model:

Use the Gartner TIME Model

Using the Gartner TIME model technical business leaders can come up with a way to decide how important it is that they upgrade their systems. The system uses two factors to evaluate a code base or system that is deemed legacy:

  1. Business Value - this is both the current value to the business in terms of revenue and the opportunity the application provides for future growth.
  2. Technical Quality - this is the measure of code quality; higher quality code will allow you to change it more easily.

Gartner provides a handy ‘quadrant’ which includes these two factors and some action plan outputs:

Gartner’s TIME Model for legacy systems appraisal

The model explains 4 states that organisations can decide to categorise legacy code into in order to help them decide what to do with it:

  1. Eliminate –> [Remove] applications in this area are offering little value to the business and can be removed. Often they would have already been removed but no auditing has taken place or management have not made this removal a priority
  2. Migrate –> [Consolidate] these systems need to be re-written or consolidated into other applications. Skilled engineers should be used to decompose the functionality along with the right people that understand what these applications do.
  3. Tolerate –> [Modernize] after an analysis has been made the decision in this case is to ‘stick with it/grin and bear’. However, a systematic approach to slowly improve should be made for the long term with regard to this type of application.
  4. Invest –> [Modernize or Replace] these applications represent the future of your business objectives and are supporting significant revenue opportunities. At this point a well-structured plan should be made to entirely replace or significantly modernize.

The next section will talk about modernization of legacy code and the approach that can be taken.

An Action Plan for Modernization

Digital Transformation (the business transformation of people processes and technologies) is not something that can be achieved in one fell swoop. In order to mitigate risks, organisations need to take it on a step-by-step basis. In fact, as part of a sound business strategy, being able to improve small parts of complex system at the low level will (over time), yield significant advantages over simply trying to make too many large changes at the same time.

One case study that highlights this point is that of Team Sky that used ‘Marginal Gains’ to win the Tour de France within 5 years.

So let’s a review a process for making small improvements to our code and see can we start cashing in on those Marginal Gains!

The Code Review/Audit

When we decide to modernize code the first thing we need to do is to audit the code and try and work out how hard modernization might be. This should be done by a skilled engineer who has experience in building large and complex decoupled systems. Typically, they will have lots of skills in refactoring and improving legacy systems and will be able to make a judgement on the viability of improving/modernising it.

There are 3 key areas to consider during this audit.

  1. How many other physical systems this code touches (including on the same machine) – this is known as External Boundaries
  2. What is the most heavily used code? (You can use source control to find out where most changes have happened). If no source code exists, speak to people who know the system and investigate – this is known as Axis Of Change
  3. Create a ‘dependency map’. Loosely speaking this is a map of internal coupling in the application. It is a good way to assess complexity and is a good exercise for the engineer to begin to get a bird’s eye view - this is known as Internal Complexity

The Cycle of Improvement

Once the code has been audited and a decision has been made to begin to Modernize the code, the following steps can be followed:

  1. Find the most commonly used set of features in the application that are used most often. Then catalogue some manual ‘smoke’ tests which can be used to check that the system still works.
  2. Set up a Continuous Integration environment to where you can push code which will execute automated tests against the code.
  3. Write some automated tests which will cover the manual tests (outlaid in step 1). If you can’t write these tests at the code level then write them against the ‘outer loop’ of the application.
  4. Refactoring (Formatting): make small changes first to the area you identified that is used most often and build out the automated testing. The first refactoring to make should be simple, so try simply renaming variables and functions. File names should also be made consistent at this point.
  5. Refactoring (Design): once you have refactored the small low level formatting details, begin to build up a picture of where duplication exists. This will help you decide what core interfaces you need. At this point compare what you need with what you have (that is already in the app). Then you will be in a position to tackle the architectural issues in the application.

The above steps can be repeated in small iterations, lasting only a few days at a time. The trick is to make very small changes and to keep adding automated tests as you go. You should also enlist some users to help with testing at this point.

A great book to read to help keep you on track when refactoring legacy code is Working Effectively with Legacy Code (by Michael Feathers)


In this article we have discussed a hot topic in today’s Digital Transformation landscape; Legacy Systems!

We have seen how firstly organisations can define what state their applications are in (by using Gartner’s TIME model). This will help them get an idea of where to focus and which route to take (Eliminate, Migrate, Tolerate or Invest). Then we discussed an effective approach to modernising applications which involves taking small steps and thoroughly testing work.

Most organisations see Legacy code as a thorn in their side. It’s worth remembering that every organisation has legacy code so whatever operational cost they are experiencing it is offset by the fact that competitors are having to deal with exactly the same.

Organisations can realise that Legacy Code actually represents an opportunity to enhance the structures supporting their IT systems. By taking a proactive approach to, and modernising assets with high business value, they will begin to see pay-off later down the line that will manifest in more business flexibility; enabling greater competitiveness.

Connect with the author :

Pete Heard is the founder of Logic Room. He helps organisations create web and mobile software using JavaScript and the related ecosystem of technologies such as React, React Native, Node, Angular and Typescript.

We are a software consultancy that builds well-engineered web and mobile products for our clients, would you like to learn more?

Request a call back and let's see if we are a good fit...


email please use

chat now just call 07889 812 612