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
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:
I have no idea how any system could be migrated without this information.
- What every application running on the mainframe does every
- 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
- 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:
- The Big Bang Approach: everything is migrated at the same time.
- 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:
I can't see any other way to guarantee that functionality or data won't be lost
during the migration.
- A list of every function of every mainframe application, and how it will
be implemented on the target system.
- 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.
- A list of every mainframe batch job: what it does, if it needs to be done
on the target system, and if so, how.
- A list of every report, letter or other output item that is produced, and
what will produce it on the target system.
- A list of all relevant mainframe software, how it is used by the applications,
and what will do this on the target system.
- 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
- 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.
- Audit and Security.
- 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
- 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.
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.