6 Strategies to Improve Legacy
Application Modernization Outcomes.

Usha Raikar


6 Strategies to Improve Legacy Application Modernization Outcomes

Legacy modernization projects come with some unique challenges; this article outlines proven strategies to minimise risk and maximise successful outcomes for Legacy modernization projects. Legacy systems are workhorses, they run complex business systems, support thousands of users & may span millions of lines of code. Legacy systems are like seasoned marathon runners, yet surgery must be done on them whilst in a race & users expect the runner to be faster, brighter & sharper at the end of the modernization project.

Strategy #1: Ensure the Solution Fitment Solves the Problem

  • Choosing a Commercial off the shelf product to replace a legacy application that does not map correctly to it or requires too much customization.
  • Choosing an automated tool whose output codes do not match an organization’s standards of code maintainability or end state architecture.
  • Choosing to re-write manually an entire legacy application in a new architecture & modern technology stack. While this may look tempting at the start, the urge to correct some wrongs in the legacy application or add some features will delay project schedules.

A zip code verification component written years ago in the legacy application might be replaced with very robust address validation tools today. Certain Claim automation modules written in legacy applications could be replaced with commercial Claim engines with some customisation. Automated migration tools could be used to improve manual migration effort. A blended approach would benefit many legacy modernizations, but this needs a detailed view of what feature sets are available in the legacy application and what is supported via new products and toolsets in the market today.

The balance of cost, time & feature sets must be evaluated regularly & strong project management will keep these balanced.

Strategy#2: Execute a Robust Due Diligence

The Planning of a project deserves a lot of attention which it may not get. When conducting the Due Diligence for a Legacy Modernization project, it is important to review all the languages & tools that the application is comprised of.

  • If the applications are running on a mainframe, then all batch & online programs must be scoped.
  • All the interfaces used in the application must be mapped. When the application is modernized, these interfaces must be upgraded to use versions compatible with the new platform stack.
  • If the screens are going to be modernized, then the target framework to be used should be decided based on 2 criteria – how will training be imparted to users & the effect of changed screens on operations. Be careful of introducing any workflow changes at this point; though it may seem tempting to revamp certain workflows, it may introduce additional complexities into the project.
  • If the database is going to be changed, then the legacy data schema usage must be thoroughly understood. When migrating off the mainframe, EBCDIC to ASCII data transformation must be fully assessed.
  • Assess the reporting requirements of the current system. Most legacy applications would be formatting data to fit a printer’s coordinates, after migration, these requirements may no longer fit with newer reporting tools.

Strategy #3: Scope Correctly

Just counting the lines of code is not enough to assess the complexity. Lines of code by itself is only one metric of complexity. Legacy database schema & their data structures can add to the complexity of an application. On older systems, non-relational databases that are hierarchical or network might have been used, e.g. IBM’s IMS DB, CA’s IDMS, etc. In some older programming environments, the front-end would have a lot of functional logic embedded, e.g. D/3 Database Management System from Raining Data. Transaction management, load balancing & multi-user capability on older systems should be evaluated thoroughly.

Where possible, engage a team that is conversant with the old technology. Evaluate if any of the original programmers are available for support, even if for a limited period. Well-informed reliable programmers will make this difficult journey much smoother.

Strategy #4: Assess the Complexity of the Interfaces

Many legacy applications run in large organizations, connecting to banks/ stock exchanges/ other outside interfaces. Changing the receiving end from one technology to another for one interface is itself a mini project, bundling all of these onto a full-blown legacy modernization needs proper planning.

First assess all the interfaces used in the application. Use automated code assessment tools to scan legacy source codes. This will allow you to understand what libraries or components are used in the application.

Then map whether these are unidirectional or bidirectional interfaces. For each of the interfaces, you will need to assess whether newer versions are available from the vendors. If newer versions are available, whether these are compatible with the target technology stack needs to be assessed.

Once the equivalent interfaces have been identified, their implementation effort needs to be planned in tandem with the other modernization effort, so the right interfaces are migrated at the right time. The migrated system might need code changes to work with the new interfaces effectively, ensure enough effort & planning is dedicated to this task.

Strategy #5: Engage the Users from Early-on

Understanding & managing user expectations from Day1 is important. Engage them early on & this will help during Implementation. A legacy modernization project is not just about technology, but also about making users comfortable & confident about the new systems being implemented.

  • If the target system is an Internet or cloud enabled system, then the user experience will be very different from a legacy application that might be on a mainframe or a Windows based system. User training will be required to get everybody accustomed to the target platform.
  • If the users are middle aged or older, then they might need practice working on browser-based systems. Ensure your training plan caters to a more mature user base, where necessary.
  • Legacy applications usually have extensive keyboard shortcuts; this allows users to very quickly navigate and operate the legacy application. After migration, the same shortcuts may not be available on the new system. Mapping keyboard shortcuts itself is a non-trivial task in some modernization projects. Be aware of this challenge & ensure enough thought & planning has been dedicated to see how users can adapt to the new systems after migration.

Strategy #6: Test-drive with a POC

Mapping from a decades old system to a modern technology stack can have many points of failure. This risk can be reduced by test-driving the technology decisions with a Proof of Concept.

Choose an independent module from the legacy application to modernize & test out all parts of the target technology chosen. Statistically, a 2% sampling will provide a 98% confidence in the end solution. Check if the target database chosen supports all the operations required in the system. Check if the screens & the user interfaces can cater to shortcut keys or any other interface related expectations that users might have.

Where possible, go live with the POC with a limited user audience so you get real feedback on how your migrated system will be used & accepted by the users. Evaluate if all the components, frameworks & tools chosen work together well. There have been projects in our experience where after the POC, some technology components were changed or upgraded to improve project outcomes; be flexible in using the best suited components for the target system.

We are innovators. We build automation tools. We support them with people & processes.

On-premise systems have been the backbone of businesses for decades. But technology & more importantly, the pace of change in technology has affected the way businesses run. We thrive on building bridges from older technologies to new ones. We use a judicious mix of forward & reverse engineering techniques to manage modernization; we make them predictable and risk-averse.