Four steps to determining which legacy applications to modernize

Micro Focus Senior Solutions Engineer Craig Marble offers developers tips on how to determine what legacy apps should be modernized and how to prioritize that process.


What to do with legacy systems is a topic that has come up a number of times in this blog and in talking to other developers.

Legacy means different things to different people; for instance, it could mean anything from a 40-year-old COBOL application to a classic ASP Web page from 10 years ago. But one thing is certain: Nearly every shop has a few of these systems lingering around and periodically ask, "Which applications are worth updating?"

I recently spoke with Craig Marble, a Senior Solutions Engineer at Micro Focus with a long history of working with legacy applications, about how to determine what applications should be modernized and how to prioritize that process.

By modernization, we mean taking an application and doing things such as:

  • Making it fit in with your SOA strategy (if you have one).
  • Adapting it to run as a cloud application (internally or externally).
  • Exposing some of its functionality as Web services.
  • Replacing some green screens in the plant with a Web front end.
  • Taking an application and moving it to an entirely different platform with a lower TOC.

The end goal should be lower costs (so there is ROI on the effort itself) and increased IT agility. Craig says that modernization is usually better than a full rewrite or a rip/replace, and that this is even more true the larger the application. I believe it; other than very small applications, rewrites or replacements have a tendency to not implement algorithms quite the same or be functionally equivalent without an extremely intense and exhaustive analysis process and testing period.

Step 1: Take an inventory

Craig suggests starting the process by taking an inventory of your applications. This inventory is not just the application name and how many people are using it — the inventory also needs to include things such as what resources the application uses, who uses them, what their purpose is, the size of the codebase, the complexity of the code, what kind of tests currently exist, how complete and rigorous the tests are, and so on. In other words, a full accounting of the applications. Some tools can make this process much easier and more accurate, and Craig recommends his company's Enterprise View product.

Step 2: Look for redundancies

Along the way, look for redundancies; perhaps two applications are similar enough that you could migrate the data from one to another and shut it down, or maybe add functionality to one application and stop using the other. You may even discover that only a few people are using an expensive application, and you can increase the ROI on that application by increasing its usage through training and awareness.

Step 3: Assess the business value of each app

After performing the application inventory, you should try to assess the business value of each application. There are many ways to assess an app's business value, and everyone will want to boost the perceived value of their favorite projects. The IT department needs to work closely with business analysts and operational managers to get a fair and honest assessment of business value, or else you will be wasting your time.

Step 4: Sort the applications

Now you should sort the applications first by the cost of the modernization efforts and the business value; in other words, aim for the juiciest, low-hanging fruit first.

In some instances, you might want to focus first on the IT department if that allows the IT department to be more efficient with the rest of the modernization efforts. You may end up deciding that the cost to modernize is not going to be paid back by the benefits, or that the risks are too high. But it's better to find these things out before you invest time in the project than when you are halfway through and discover a showstopper or that another department has a better application that does the same thing as what you are trying to accomplish.


Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.


Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!


Justin James is the Lead Architect for Conigent.

Editor's Picks

Free Newsletters, In your Inbox