What to Consider when Evaluating a Mainframe Migration

On June 28^th, Walter Sweat of GT Software and Raul Menendez of CBS Corporation joined CMG for a webinar called “What to Consider when Evaluating a Mainframe Migration” which was sponsored by GT Software. The session discussed re-platforming, performance and security. Afterwards, Walter and Raul fielded Q&A from our audience and the questions they didn’t get to answer during the session are below.

What are the biggest dangers in doing a mainframe migration?

It has been our experience that there are two consistently important areas to consider – how long testing will take, and making sure to know what is in your inventory before you start a migration. People need to recognize that planning for testing – coming up with the proper use cases – is vitally important.  And having quantifiable information about performance on the mainframe which you can compare with the migrated environment is critical.  And having a complete snapshot of your mainframe inventory and the interactions allows you to choose which application and data areas make sense to migrate first.  The more inter-related applications are, the harder it is to migrate and test in unison, so being able to identify any silo-ed applications makes the process much smoother

How long does a mainframe migration take?

That obviously depends on the makeup of your mainframe.  If you have a consistent and smaller footprint of tools (COBOL, VSAM, DB2, JCL, etc), the migration will obviously go much smoother and more quickly.  If your inventory has lots of different languages and third party tools involved, that will increase the time of migration.  But we have seen small batch migrations with just COBOL and VSAM be accomplished in less than 3 months.  Conversely, for migrations where there is tons of assembler code and a multitude of different tools like IDMS, IMS, PACBASE, DL1, etc in place, we have seen migrations take several years.  Again, that is why it is so important to have an accurate accounting of what you have in your inventory before you start a migration.

Should we consider doing the migration work ourselves or have someone do it for us?

About half of our customers here at GT Software have done the migration themselves and half have used a Systems Integrator.  The biggest decision is if you have the time and resources to do the migration and keep doing your day-to-day work. One advantage to doing the work yourself is that when you first go in production, your team is already aware of all of the new tools and development and support processes.

What is the user experience like after the migration?

For our NeoSuite of products, it is almost 100% the same.  For CICS users, we keep the same look and feel for the screens, and for batch, your developers and operators are still working with the same JCL they always worked with.

How hard is it for experienced mainframe developers to get used to working in the new environment?

From our experience in training our customers, not hard at all.  We have some customers who have staff who have been doing development work on their mainframe application for 30 or even 40 years and even those experienced developers have quickly adapted to doing development with Visual Studio.

With this migration will IMS DC part be existing anymore or needed?

Our NeoKicks product actually only works with CICS.  For IMS/DC customers, we work with partners who convert IMS to CICS so that the resultant code runs in NeoKicks.  That obviously adds more effort into a conversion but it is doable.

How do you translate mainframe MIPS/memory/etc. to distribute system resources?

We have consistently used a factor of 100 MIPS equates to a single core.  Since we leverage IIS and the investment that Microsoft has put into it, we have seen extremely well performing applications, even on commodity type hardware.

After mainframe migrations, what happens to the mainframe support staff and programmers?

The COBOL programmers will still be working with COBOL, so you don’t have to worry about losing their rich history and understanding of your applications.  For mainframe system programmers, those skills don’t necessarily translate to the roles that will keep a Windows Server environment running at the same level of reliability as the mainframe. But by having staff who understands IIS, MSMQ, Active Directory we have seen customers have that same level of reliability after migration.  If you move to SQL Server from DB2, the same thing applies – you want database administrators who understand SQL Server as well as your mainframe database administrators understand DB2.

I understand how to transfer VSAM data but how would we move CA-Datacom/DB or DB2 tables SQL Server?

We work with partners who have tools in place to convert Datacom and DB2 to SQL Server.  With Datacom, there is also associated code changes that have to be made, but with DB2, there can be very few code changes that are required, so that only the process of using tooling to do the database conversion is required.