Each Legacy Modernization project is unique. There are skills and techniques that apply universally, but the best tools and methods for carefully replacing legacy systems will differ wildly in every environment. Choosing the right approach to the problem will ensure you come out the other side of the project with a working solution that is robust and future-proof.
Your Goals
Legacy Modernization projects often start with too narrow a focus. The pain and expense of maintaining one particular application that's on ancient hardware is often the trigger for funding a modernization project, but the absolute first and best advice we can offer is don't jump into the project with too narrow a focus. Think globally about your entire IT ecosystem.
You may not have the budget to revamp everything, but taking a holistic approach to capturing and understanding your current-state is absolutely critical to establishing a roadmap to a world where you're always prepared. Steven Covey's Seven Habits of Highly Effective People includes a habit of "being proactive." This is a place where IT departments frequently fail. If things are falling apart, you're constantly in "emergency recovery" mode and literally never have the free time to fix things enough to get ahead of the problem. That's a path to disaster.
So even if you're desperate to get off of your old systems, start with a thorough Discovery project. This will help protect you from unexpected surprises when it's actually time to implement your new approach.
High-Level Approaches to Legacy Application Modernization
Gartner outlines seven possible approaches to legacy modernization:
- Encapsulate. Leverage and extend an application’s features and value, encapsulate data and functions in the application and make them available as services via an application programming interface (API). Implementation specifics and knowledge are hidden behind the interface.
- Rehost. Redeploy an application component to another physical, virtual or cloud infrastructure without recompiling, altering the application code, or modifying features and functions.
- Replatform. Migrate an application component to a new runtime platform. Make minimal changes to code to adapt to the new platform, but don’t change the code structure or the features and functions it provides.
- Refactor. Restructure and optimize existing code without changing its external behavior to remove technical debt and to improve the component’s features and structure.
- Rearchitect. Materially alter the application code so you can shift it to a new application architecture and fully exploit new and better capabilities of the application platform.
- Rebuild. Rebuild or rewrite the application component from scratch while preserving its scope and specifications.
- Replace. Eliminate the former application component altogether and replace it, taking new requirements and needs into account.
When choosing between these, it is important to consider the integration, cost and risk drivers that are behind your legacy modernization efforts.
Encapsulate
If the legacy system is maintainable in its current form, but integration with new and existing systems is the problem, encapsulation could be the way forward. Some modern API frameworks offer tools for making this process relatively straightforward. A complete, secure and well documented API can be generated quickly. A future post in this series will cover this in more detail.
Move & Improve
If the primary concern of your modernization project is the cost of maintaining legacy mainframe hardware, then rehosting is worthy of consideration.
Here is where new abstraction techniques developed in the past two decades really change the playing field. What if you could move your old legacy application onto a "virtual" mainframe running on modern infrastructure? That's a real possibility. Instead of trying to maintain decades old equipment, you could run your exact original code but now have it on a virtual machine, perhaps even in a container, so that you're free to move your application across different platforms without being tied to a particular big box. A variety of mainframe systems are now available as portable, scalable VMs on modern, well maintained, secure operating systems.
Lift & Shift
If hardware maintenance cost is your primary driver but rehosting is unavailable or too expensive, then replatforming or "Lift & Shift"could be the next best option.
The Lift & Shift method involves migrating the old mainframe code from the mainframe and recompiling it to run on a different platform. If successful, this gives you identically functioning code but on newer platforms (perhaps even in the cloud?) It does require you to have access to the original documentation and all the source code. There may be a need to retool some of the functions to match the requirements of the destination hardware. In other words, while you're not starting from scratch you're still going to need expertise in the old languages and operating systems you're trying to depart from.
Refactor Or ReArchitect
If the basic capabilities of the legacy application still match the business needs, and the platform is maintainable for the foreseeable future, you may choose to refactor or rearchitect it.
Rip & Replace
However, if the legacy application is written in an out of date language and the risk is shortage of skilled resources, rebuilding or replacing may be the only options worth considering. This means completely replacing the legacy system with a new, modern application to duplicate (or improve) its original functions. It is potentially the most powerful approach to modernization, but because you're literally completely replacing the old system with something built from the ground up it also has the highest degree of risk associated with it. However, it also has some of the greatest reward because you can get off the monolithic approach to application development and turn your old batch-driven monolithic code into an open, API rich platform where real-time data access is possible.
Shake & Break?
Don't leave functional testing, load testing and user acceptance testing out of your modernization plan! You can't assume that just because you've cloned your old legacy app and put it on a virtual machine, or recompiled it to a new platform that it's just going to work like the old version did. Changes always mean the risk of something breaking or performing poorly so put time and resources for testing into your roadmap to modernization.
General Recommendations
We also have some high level suggestions that are applicable to most legacy modernization projects.
Hardware
Get off of physical boxes. Virtualization, Containerization and Cloud solutions have quite literally transformed the way that IT is done in many companies. These are not just buzz-words. They're technologies that allow you to get more performance, higher availability, easier scalability, and astonishing portability in your IT systems. Remember when upgrading servers meant hours of down-time and your IT people pulling overtime? Much of that way of life has been removed through carefully managed systems in this new cloud ecosystem. You can get there too.
Software
Get off proprietary, closed architecture and get onto API-centric open-sourced applications. Chances are your old legacy systems were created on big monolithic machines, and developed in large waterfall-style development projects. The future is in carefully managed, secure systems that are enabled with APIs that allow your systems to all talk to each other. The goal is to be in a world where software improvements happen all the time, not just every few years in painful slogs through high-profile monster projects. Agile isn't just a way to develop software, it's an adjective your IT department should strive to embody.
API First
Adopting an "API First" strategy can make a modernization project more manageable by breaking it into logical chunks. At the same time it moves your organization towards a future-proofed microservices architecture. API First can mean wrapping some existing systems with "facade" APIs to insulate new applications from changes in the back-end. APIs act like contracts between layers of your application, allowing you to replace components independently.
Conclusion
Your answer to Legacy Modernization will be unique. That's good. Your challenges are your own and nobody should be coming in trying to tell you how their solution fits every client. That's a red-flag. Success will require a thorough understanding of the current world and a clear vision of the future you want to achieve.
Once you select your approach, you'll need to plan your modernization project, and move into envisioning your desired outcome. Look out for articles on those topics soon.
