Should I Stay or Should I Go? Understand Your Options to Make the Best Decision About Mainframe Migration
by Doug Brown
February 8, 2010
Migrate! Modernize! Save money! Be more agile! These messages and many more are probably landing on your desk daily. Is it time to consider moving off the mainframe to another platform, or should you ignore these demands and continue forward secure in the knowledge that IBM is going to look after you? Unfortunately there’s no formula that is going to generate the right answer to that question for everybody, but this article aims to provide you with guidelines so that you are better able to say “Yes, it’s time I looked into migration more seriously” or “No, the mainframe is where we should stay for the foreseeable future,” or for many, “Maybe, some areas really could benefit from migration, but others really need to stay.”
You need to decide what is best for your organization and there may be no perfect answer. There are many good integration options on the mainframe just as there are many great modernization options off the mainframe in environments like .NET. It all depends on where you are now, where you want to go, and how quickly you want to get there – only you know the answers but here are some guidelines to help you choose your route.
Factors That Encourage Staying; Factors That Encourage Going
No factor truly says “stay” or “go” as the degree of need or desire can change one company’s showstopper into another company’s slight bump in the road to be overcome. Figure 1 provides a list of criteria that may push you one way or the other. In general if you check more items in the “Stay” column or more items in the “Go” column, that’s probably what you should do, but you’ll gain more accurate guidance if you first weight each category according to its importance to your decision. For example, if your company’s IT budget is now less than your mainframe expenses, your decision on the financial category may override all other factors. Of course, if this is your situation, you won’t be reading this article as the decision has been made for you, but hopefully you get the point! You may also want to do this analysis for different applications if you find yourself saying, “I’d answer one way for application A, but another for application B,” – perhaps a mixed solution is the right way forward for you.
Looks Like We Are on the “Go” Side – What Now?
From the checklist in Figure 1 you should have an idea of your priorities and the areas that might present the most challenge when you come to migrate. Plan to talk to a few vendors with migration-assisting products and services, but put yourself in the driver’s seat by creating your own checklist of criteria you need to be satisfied such as particular mainframe technologies or functions that must be supported, financial savings thresholds that must be met and timeframes for completing the migration. Whether you gather answers verbally or in written responses you’ll find that your forethought makes it easier to compare the different vendors/options and determine the combination of products and services that will deliver a successful migration strategy to you.
Interesting article with a list of good insights in figure 1. I didn’t see anything related to scale though, at least not directly. What we’ve seen happen is that as scaling of server farms grow, so do the not so obvious costs such as power, floor space, software licensing and support requirements (internal or outsourced). What is the breaking point? 100 servers? 1000 servers? 10000 servers? Not sure. Thoughts?
Jim, I am not sure why you mention 1,000s of servers. I just authored a paper about a sizing project in which we re-hosted an application that consumed a 617 MIPS z/OS box over to a single HP Server with eight quad core AMD processors (32 CPUs total). It ran faster than it ever did on the System z box, while only consuming about 16 of the 32 CPUs, leaving lots of headroom. Even if one wanted to distribute this across a set of blades, for reasons of parallel redundancy, separate test boxes, etc., it’d only be a handful, like 4 or maybe 6.






Excellent article, especially the list in figure 1.
In our experience it is best to separate migration in platform steps. For instance first the operating system, after that the applications to .Net, and after that the database. That is, in our opinion, the only way to test the system. You must have a stable foundation somewhere.
Another important aspect:Application Migration should concentrate on maintainability, and on standardization on the code produced.