‘The Easy Bit Is Moving the Data’: Mainframe Storage Migration in the Real World
Chris Harvey, senior technical delivery manager at Vertali, explains why uneventful migrations rarely happen by accident
Storage migrations can often sound far simpler than they really are. On paper, you’re moving data from one set of hardware to another. In practice, you’re working around live systems, critical workloads, dependencies built up over years and change windows that seem to get shorter every time somebody looks at them. You know what I’m talking about.
So whenever I talk to a client about a migration, I tend to spend far more time discussing what happens before the move than the move itself.
The actual copying of the data is often the straightforward part. The real work is understanding exactly what you have, how it’s being used, what has to move with what, which volumes need special treatment and, crucially, when you can make the change without creating unnecessary risk.
A recent airline project is a good case study. This was not a quiet environment. The airline operates around 3,500 flights a week, with 250 aircraft serving 80 countries, so opportunities to make production changes were limited. For the high-impact volumes, we were often working with a 90-minute window.
Step 1: Planning and Design
The migration began, as these projects should, with planning and design. After all, an aircraft doesn’t set off without a planned route, a clear manifest, backup procedures and a plan for the unexpected. Back to the job in hand: We worked through the existing environment, volume types and activity, IODF changes, UCB mappings, timelines and migration windows.
Most volumes could be dealt with through the standard process, but there are always exceptions: system datasets, page datasets, coupling facility datasets and other volumes where you need to stop and think rather than simply include them in a bulk move.
That’s the part people sometimes underestimate. A migration tool can be very good at moving data, but it can’t compensate for a poor understanding of the environment.
Step 2: Install and Test
Once the design is sound, the character of the project changes. You can install and test the migration software, initialize the target volumes, prove the process on a small number of volumes, and then move through the estate in a controlled sequence: systems programmer environments first, then development, pre-production and, finally, production.
On the airline project, the development environment alone involved more than 2,500 volumes. We deliberately started with lower-use, smaller volumes to prove the process before moving into heavier-utilized volumes.
The important point isn’t simply that the data moved quickly; it’s that by the time we reached the difficult production work, we already knew exactly how the process behaved.
And that mattered when we came to one especially interesting part of the system.
Step 3: Dealing With Reality
The airline had ~21 MOD-54 volumes carrying application logging. Check-ins and other activity were flowing through the application continuously, and those logging volumes were filling at a rate of roughly one every two and a half minutes. The I/O rates were substantial. The quietest practical window was 2 a.m. on a Wednesday, and we were given 90 minutes.
We completed the migration in around 30 minutes, which left another hour for verification while the applications continued to operate, the volumes continued to fill and the switch to the new hardware took place underneath them.
From the users’ point of view, nothing happened. And that is exactly what you want from a storage migration: no drama, no tears before bedtime, just controlled and predictable invisibility.
The technology helps because the switch can happen dynamically. Once the data is synchronized, the UCB swap redirects I/O from source to target and the volume identities are switched. Applications don’t need to be stopped simply because the storage underneath them is changing, and the catalog doesn’t need to be rewritten as part of the process.
Technology and Experience Matter
We’re finding that the biggest gains increasingly come from combining experience-based preparation with proven migration technology. For example, one useful development in version 6.1 of Transverse, the 21CS technology that we use, is Migration Planning Assistance. It doesn’t change the underlying migration engine; instead, it automates much of the discovery and preparation around it.
Good automation, in this context, removes repetitive work rather than replacing judgement.
The discovery process can identify systems, sysplexes and associated volumes, validate what’s actually present rather than what somebody thinks is present, and then generate much of the JCL required for scans, migration sessions, syscom allocation, fallback and reporting. Multiple sessions can be controlled centrally, failed volumes can be isolated and retried, and the preparation for backing out is built before anybody needs it.
After all, nobody writes their best fallback procedure when a live migration has just developed a problem. If you might need to back out, the best time to prepare for that is when everything is calm. A bit like repairing your roof when the sun is shining.
Step 4: Scan and Validate
The same applies to scanning and validation. Run the scans first. Find the awkward volume before the migration window starts. Understand where a Db2 reorg or another activity may interfere. Decide which datasets are better handled outside the normal online process.
A good migration plan is really a collection of decisions made early enough that they don’t become incidents later. In other words, solving today’s issues before they become tomorrow’s problems.
This is why I’m also wary when storage migration is discussed in terms of speed. Speed is useful, especially when your production window is measured in minutes, but it isn’t the objective on its own. The objective is to move the right data, to the right place, with the right controls, and leave the business blithely unaware. What migration?
If you can do that in 30 minutes, excellent. If it takes longer because that’s the safer way to do it, that’s fine. The real measure of success isn’t how impressive the migration looked from the outside. It’s how uneventful it felt to everyone who depended on those systems while it was happening.
And in my experience, uneventful migrations very rarely happen by accident.