Tags
MAINFRAMES, TIME, migration, approach, down, lift, and, shift, resource, advantages, disadvantages
We can see that 2 approaches are discussed much when we think about Mainframe Migration.
Lift and shift Approach
Lift and shift is an approach, one among many, for migrating your apps to the cloud. It means moving an application and its associated data to a cloud platform—without redesigning the app.
Top Down Approach
In the Top Down approach, an overview of the system is formulated, without going into detail for any part of it. Each part of the system is then refined by designing it in more detail. Each new part may then be refined again, defining it in yet more detail until the entire specification is detailed enough to validate the model.
Which Approach to Take
Each approach has its own positive and Negatives. I think correct approach needs to be taken depending on the current Mainframe application situation.
We have some mainframe applications that have been developed long years back and has been patched up with new changes/issue corrections. Business/Team that has initially developed the application might not be still available in the company and there are few applications where we do not have much documentation available. In these scenarios, optimal approach would be “Lift and Shift” as we can pull all the application rules from the existing code and create the necessary documentation to create the new application.
In the other picture, if we have an application that is recently built with all the interested parties in the company. Or we have correct documentation setup from most of the project time. Or if business/Team is confident of writing down the rules for each process in the application, then the “Top Down” Approach will be optimal.
Advantages and Disadvantages
As said initially, both the approaches have advantages and disadvantages and should be considered before finalizing on an approach.
In my experience, I think, “Lift and Shift” approach will need more time/resources among the two. Reason being that we must use the current mainframe resources to unload all the rules from the Mainframe code and create documentation. Convert this documentation into requirements form. And use these to develop the new code in the migrated technology. One more observation to note is that the new code in a way (has to/will) resemble the old code, making it not the best performance-oriented code. This happens as we look at individual process level for development and not at a project level to combine multiple aspects where possible. So, this will involve an additional step for the new developer to work on it, to improve the code performance.
In the “Top Down” approach, we need to ensure that we are not missing any rules that have been implemented on the Mainframe side. Multiple parallel runs and extensive testing needs to be done to ensure we are not missing any. If business users know about what they are expecting and are not worried about differences between Old and New code testing results, then that should save a ton of time. I am primarily mentioning the batch jobs testing as most of the UI testing would be straight forward. Best advantage about this approach is that the developers can build the high-performance code on the first go as this is directly built from new requirements.
Conclusion
I know this on a very high level when deciding if a current mainframe application can be migrated. Also, we discussed only 2 of the multiple approaches that can be used for Mainframe migration. Anyways, I think this post will be helpful in some way. Finally, I would say, yes, Mainframe migration can be done and is substantially considered in various companies, to move out of Mainframe, to take advantage of current technologies.
—————————————————————————————————————–
If you would like to Earn Free Stocks, Credit card Points and Bank account Bonuses, Please visit My Finance Blog
You may also like to look at:
F1 for Mainframe 