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
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.
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.
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.
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.