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.


I think you backed into this one, then pulled away from it. Sometimes an application needs new functionality, but the existing application will not take an extension for it. The only way to add something to meet the new requirements would be to replace the legacy application with a new one.

Tony Hopkinson
Tony Hopkinson

The food of the myopic. The legacy application to attack is the one that is costing you the most, not just operationally. You want the one that keeps getting in the way. The if it worked like that, the but for this one. Whole cloth, or evolutionary, start hacking away at it. Wrap it up then start pulling functions out it, make it start to fit in the current strategy. Legacy systems by their very nature are very resistant to change, avoid showstoppers by iterating towards a final solution, small steps realising greater and greater benefits and more to the point you can shift towards current goals as they move. It isn't the fruit that's valuable, it's the facility to grow more...

Wombat Ron
Wombat Ron

Redundancy is not just about apps. In many instances the business process or activity that the app supports is either unnecessary or redundant. Mapping current business processes to legacy apps should be an essential part of the auditing process.


Good points! At least COBOL and many other legacy systems have companies supporting the old language. But the VB6 compiler is completely out of support. One of the immediate ROI of a VB6 migration to .Net is using a modern compiler like Visual Studio. There are no good migration tools for VB6 to Java. But, ArtinSoft provides an excellent migrator to VB.Net and C#. Lots of good case studies. I was involved in a 5 million line migration of VB6 to C# for Citigroup. It was done with ArtinSoft in 1 year! I like the idea of putting the app in the cloud. After an app is migrated from VB6 to WinForms, someone can use the product from Gizmox to run it as an Ajax or Silverlight application. One point to make: IF you have a choice, make sure the migrator you use doesn't require your new application to include a runtime library. Sometimes you can't avoid it, but often you can!


I could just see if I started talking about a rendundant application here using that word where people might worry about their jobs.

Justin James
Justin James

I know a lot of companies (including my employer) still converting apps from VB6. I am stunned at how much that language penetrated enterprises. I think someone could make a lot of money by licensing VB6 from Microsoft and continuing development with it. Ditto for FoxPro. J.Ja


My last job before leaving the states was a ?VB6 application? that started in VB3 or earlier. It has all these OCXs and other controls that were obsolete with native additions to VB6. I shudder to think how difficult it would be to migrate what I first inherited to .Net.

Editor's Picks