opinion: How to Move Off the Mainframe: A Mainframe Perspective

If you're thinking or planning to move applications off the mainframe, the chances are that the last people you'll tell are your mainframe technical staff.

Mainframers can be passionate about their platform. You'll be concerned that they'll be against you from the start. That they'll lecture to anyone they can corner about why the project will surely fail, and how everything must stay on the mainframe for the organisation's survival. You'll be afraid that they'll be surly and difficult in project meetings, abrupt with people commissioning the new platform, and do anything they can to slow the project down. And you may very well be right.

The tragedy is that mainframe staff have so much to contribute to mainframe migration projects. They will know all about the applications and systems being migrated: what they are, what they do, how often they run, and what data they access.

But far more importantly, mainframe technical people have the expertise and experience of running enterprise applications for years. They understand the issues, and how important these applications are. They know how to keep them running with the best performance, reliability and integrity. They understand change management procedures, capacity planning, monitoring and tuning, and disaster recovery issues. They've dealt with end-user problems, audit requirements, security administration, hardware and software upgrades, end-user training and a whole range of other issues. They are enterprise computing experts.

So wouldn't it be good if you could get a mainframer's opinion about a migration project? An impartial opinion that just looks at the issues from someone who's only aim is to see the project succeed? That's what this article is all about.

Every migration project is different, so I'm not going to try and produce a detailed project plan that will work for everything. Instead, I'll put forward some broad steps that I would like to see if I was managing a migration project. Think of it as 'back of the envelope' ideas.

Step 1: Find Out What You Have

An obvious step that is far too often forgotten. There's no way to migrate systems anywhere without knowing exactly what you're migrating. Before even starting the project, you need to know:

• What every application running on the mainframe does – every one.
• How they access data - IMS or DB2 databases? Which databases?
  How they connect to each other - Websphere AS calling an IMS transaction?
• How applications are developed, tested and maintained.
• If non-mainframe systems connect to applications, and if so, how. Do they use CICS Transaction Gateway, Websphere MQ, or something else?
• What reports and other output are produced, and how are they distributed?
• Transaction rates and database sizes. It's easy to concentrate on functionality, and forget about load and performance information like:
• Average and peak transaction rates, and how they're changing over the long term.
• Location and size of regular transaction peaks.
• Database sizes, and how these sizes are changing over the long term.
• Business Continuity plans and backups.
• What batch processing is done. What happens every night, at week-end, and at month-end? Many focus on online processing and overlook batch.
• What monitoring is done – what information is produced, and what is done with it.
• How resources are secured, and who administers that security.
  Also, how long is security information kept?

Step 2: Make Sure You Really Want To Do It

You knew this was coming didn't you? But the question is valid. Why do you want to move from the mainframe? There are many possible reasons, but moving applications from a mainframe is always going to be a large and costly project. So the reasons to do it should be good.

If the decision is based on figures (such as cost or performance), double-check that these figures are correct. If the decision is based on vendor information and proposals, get a second opinion. If there are other reasons, double-check that these are valid.

If after that you still want to do it, then do it.

Step 3: Plan, Plan, Plan

There are two ways to move systems:

1. The Big Bang Approach: everything is migrated at the same time.
2. The Staged Approach: the migration is divided into pieces, and one piece is moved at a time.

The Big Bang approach is overwhelmingly the most popular, but also has the highest risk. This is why I prefer the staged approach, which can be thought of as an Agile approach. Dividing a problem into smaller pieces is favoured by computer programmers worldwide, and it works. Smaller problems are easier to solve, smaller projects easier to implement. It could work like this:

Suppose we had a CICS/COBOL application that accessed DB2 tables. We could migrate the applications but leave the DB2 data on the mainframe (and use something like DB2 DRDA to access the DB2 tables). Once the applications have settled down, the DB2 tables could be migrated.

I'd be even happier if the new applications could co-exist with the old. Suppose we could leave the CICS/COBOL application running, and start a pilot project on the target platform. Then as things worked, move more and more users across until the CICS/COBOL application is no longer used.

There's no doubt that the staged approached takes more work, and is probably more expensive. But I believe that the advantages usually outweigh the costs.

When planning the migration, I'd like to see six spreadsheets:

1. A list of every function of every mainframe application, and how it will be implemented on the target system.
2. A list of every mainframe database, and details of which database on the target system will hold that data. I'd like to see how it will be moved across, and what data manipulation or conversion steps are needed.
3. A list of every mainframe batch job: what it does, if it needs to be done on the target system, and if so, how.
4. A list of every report, letter or other output item that is produced, and what will produce it on the target system.
5. A list of all relevant mainframe software, how it is used by the applications, and what will do this on the target system.
6. A list of everything stored on tape, including any retention requirements (for compliance or other reasons), and what's going to happen to it.

Of course there are so many other things to consider when planning. Things like:

• Backups and backup retention.
• Disaster Recovery strategies and procedures.
• End user support.
• Application maintenance and problem determination.
• Training of users and technical staff on the new application.
• Accounting.
• Audit and Security.
• Compliance.
• Storage and migration of archival data.
• Migrating security rules and reporting.
• Testing and Cutover plans.

Step 4: Tell Everyone

Including your mainframe people. When implementing any major change, you need to give everyone as much notice as possible. Users will have to be trained in the new application, as will any staff developing or supporting the new application, and operations staff. This is a good time to canvass for more technical opinions, and make sure you're not forgetting anything.

Step 5: Test

Once the new application is ready, the testing phase is so critical. Not only should there be testing of functionality, but:

• Performance, including performance under load. This has to be the most common problem when migrating mainframe applications to other platforms. So testing the target system with a full transaction load using a transaction generating tool is so important. What's more, most workloads increase over time. So I'd like to see the target system run with acceptable response times for at least 120% of the peak mainframe load. Not the average load, but the peak.
• Backup and restore procedures. I've seen a migration project that didn't include a backup strategy – only to realise later their mistake. Backups includes both database and full disk backups. I'd also like to see restores and forward-recoveries tested, possibly as part of a full disaster recovery test.
• Cutover and backout procedures, to iron out any problems during cutover, and guarantee that the things can be backed out if there are problems.

Step 6: Cutover the Application

Not much to say here, except that I would allow a generous change window to cutover the application. As a rule of thumb, I like my change window to be twice the time I think it would take – giving time to backout the change if needed.

Step 7: Don't Turn Out the Lights Yet

Before pulling the mainframe apart and shipping it out the door, I'd like to see some guarantees that all the mainframe data has been migrated across. This could include things like archival data, data and backups that are stored on tape, and old SMF records. In fact it may be necessary to keep the mainframe around for a while.

Conclusion

There's no doubt that some systems run better on distributed systems, others on mainframes. And there are hundreds of potential reasons to move off the mainframe. However there are so many examples of migration projects that have had major problems, incurred lengthy outages, and even failed outright. Getting a mainframe technical opinion right from the beginning of a migration project is so important. Many organisations may be hesitant to use their local mainframe staff. In this case an external, impartial mainframe consultant is an excellent option.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.