Migrating applications from aging programming environments (e.g., Cobol, Pacbase, etc.) to modern Cloud-ready technologies (Java EE, .NET…) is a challenging task both at functional and technical levels. Unlike classical software projects -usually initiated from scratch- modernization projects start with millions of lines of code to be explored, understood and transformed.
In fact, legacy applications are often huge (from a hundred thousand up to millions of lines of code), complex (the result of years of development and maintenance to comply with new business rules or technical upgrades) and heterogeneous (different programming languages interacting with each other). Consequently, a lot of project managers facing such challenges could be puzzled and raise questions on how to start the modernization? How to organize their teams with a defined measurable scope? How can they achieve all the quality requirements? Which architecture to adopt, keeping in mind the future functional evolution of the system? How to accelerate quality testing for their new release?
If you are able to answer all these questions, because you already have been involved in a project of this type, you may be tempted to stop reading this article! But maybe if I tell you that you could manage all this kind of issues thru automated, for sure, you will continue reading, at least I hope!
Actually my recipe to succeed in modernization projects can be summarized with 3 simple steps: Explore & Understand, Build, and Execute.
Step 1: Explore & Understand
Your deep understanding of the legacy assets to transform is one of these key steps to building a successful modernization strategy. Without having a clear understanding of your legacy source code you’ll have no credibility with your customers and actually it’s about science and expertise, nothing else! Thus, before you even do anything, bury yourself in your assets, examine all inputs, extract added value details out of the overwhelming amount of information… What kind of details? How deep must your understanding be? Can this phase be automated?
Still I’m an honest guy, let me be clear: analyzing millions of lines of code written in various legacy languages is a long and tedious task. Cobol, Pacbase, PL1, etc. are not point-and-click technologies. There is quite a bit(!) of science and to be concrete what I mean is that you have to identify the application architecture, identify entry points (start of transactions, batch chains…), identify direct and indirect dependencies through data, calls, identify main programs, isolated programs, dead code, static and dynamic calls, etc. Unless you get hands-on experience with each of those parts in concrete use-case context, the climb will be steep. Ok I admit it, my aforementioned assumptions may be somewhat terrifying but keep reading, not only am I about to provide you with a simple methodology to follow, but I’m also going to share with you some great news.
Step 2: Build
You’re not quite done yet, but you’re close! As soon as you have got a deep understanding of your assets portfolio (NOT an overview), you have to transform this into tangible outcomes in order to build the most suitable modernization strategy for your project. At this stage, you have all the elements at your disposal to:
- Make sure your portfolio is complete (no missing programs),
- Decompose your application into independent or interconnected modules,
- Compute software engineering metrics (volume, complexity and essential complexity),
- Solve deployment dependencies (data common to programs in different modules, coupling the data),
- Classify programs by pathology: no pathology or benign, hard to test, hard to maintain, to be redesigned,
- Get data (files and tables) for each program,
This step must also be able to come up with a validation recipe, i.e. the modernized system must provide the same outputs as the legacy system for all execution paths. You need to perform an impact analysis for comprehensive coverage of test cases (non-regression) or for functional analysis of your programs. In other words, do not underestimate the importance of preparing the test datasets for all transformed business logic.
After this stage, you are now ready to build a first-class consistent and detailed migration plan to a modern platform.
Step 3: Execute
Last but not least consists of actually executing your strategy and initiating your modernization project. Good news, thanks to the previous steps, this one will be carried out without a huge hassle. In fact, your previous efforts will relieve your software engineers (who may be absolutely not familiar with modernization projects and legacy programming languages) of this burden.
If you have mastered the steps above, you can now apply your preferred project management tools and methodologies (Agile, XP, UP…). Let me just tell you that your next modernization project will for sure be a huge success (and it will certainly exempt you from needing to explain to your boss why you deserve a raise)!
Before I thank you for reading this post, let me tell you that it’s possible to automate most of the steps I detailed!! Want to know more? Take a look at: