Migrating Boot-From-SAN Servers from PowerMax to Hitachi

A practitioner's look at Universal Volume Manager migrations, and why they're a safer way to retire an old storage array.

Every few years, enterprise IT teams face the same project: an aging storage array needs to be retired, and a new one needs to take its place. On paper that sounds simple — buy the new box, copy the data over, done. In practice, when the servers involved boot their operating system directly from that storage (what's called “boot-from-SAN”), the margin for error shrinks considerably. Get a boot LUN migration wrong and you're not looking at a degraded application; you're looking at a server that won't come back up.

We recently worked through this exact scenario, retiring a Dell EMC PowerMax array in favor of a Hitachi Virtual Storage Platform, for a set of AIX servers booting from SAN. Although we are using PowerMax and AIX in this example the steps are similar for almost all arrays and operating system types. Rather than walk through every command we ran, this post is meant to give the readers a sense of how a migration like this actually unfolds, and why it's structured the way it is. We've left out host names, addresses, and other environment-specific details — the goal here is the approach, not the recipe.

Here's the process at a glance before we walk through each phase:

The Core Idea: Virtualize Before You Move

The tool that makes this kind of migration possible is called Universal Volume Manager, or UVM. It's a feature available on all Hitachi storage arrays that lets the new array “virtualize” storage sitting behind it on an old array — in this case, the PowerMax. Once a volume is virtualized, the Hitachi array can present that same data to a host as if it were its own, even though the bits are still physically sitting on the old system.

That distinction matters because it breaks a storage migration into two separate events that don't have to happen at the same time:

• Cutting the host over — pointing the server at the new array instead of the old one.
• Moving the data — physically relocating the bytes from the old array onto the new array's own disks.

Traditionally those two things happen together, which is what makes migrations stressful: a long outage window while you wait for data to copy before anyone can safely say the host is back online. With UVM, the host cutover can be quick, because the host isn't waiting on the data to physically move — it's just waiting on a path change. The data migration then happens quietly in the background, with the host already up and running.

Before Anything Touches a Server

Migrations like this start well before any commands are typed. The Hitachi array needs the right licensing in place — Universal Volume Manager itself, a volume migration feature, a local replication feature to actually drive the background copy, and pool-related licensing if the destination volumes are thin-provisioned. On the SAN side, a handful of front-end ports on the old array get dedicated and zoned directly to ports on the new array, essentially building a private pathway between the two systems that production hosts never touch.

Just as important is the paperwork — or in modern terms, the spreadsheet. Every host being migrated gets fully documented: its adapters, its boot LUN, every data LUN it owns, sizes, and how all of that maps to where it's going to land on the new array. Nothing gets executed until that inventory is complete and reviewed. Rushing this step is where mistakes are made.

Proving the Connection Before You Trust It

Before any real production data crosses the new pathway between arrays, the team proves the path works using a small throwaway volume — essentially a test LUN with nothing important on it. That volume gets presented from the old array to the new one, virtualized, and verified end-to-end. Only once that dry run succeeds does the same process get repeated, lun by lun, for a host's actual production volumes.

It's a simple idea — test with something disposable before you test with something that matters — but it's the difference between finding a zoning mistake on a throwaway LUN versus finding it on a customer's live filesystem, costing precious time during the small windows usually allocated for migrations.

Handling the Boot Disk Separately

Boot-from-SAN adds a wrinkle that ordinary data migrations don't have to deal with. There are a couple of valid ways to handle an AIX (or any server type) boot LUN in this scenario, but a common and conservative approach is to leave the existing boot LUN alone and instead provision a brand-new boot volume directly on the Hitachi array. The AIX administrator copies the operating system image over to that new disk, points the server's bootlist at it, and reboots onto the new storage.

The advantage of this approach is rollback. The original boot LUN on the old array stays untouched and available until the team is fully satisfied the server is healthy on its new boot disk. If something looks wrong after the reboot, there's a known-good fallback sitting right there — no emergency data recovery required.

Bringing the Data Along

With the boot disk handled, attention turns to everything else the server owns — its application and data volumes. Each of those gets virtualized behind the Hitachi array the same way the test volume was: mapped over from the old array, discovered, and represented internally as a new virtual volume that the host can eventually see.

This is also where naming and ID discipline matters most. With potentially dozens of volumes in flight for a single server, keeping consistent, traceable labels between the old array's device IDs and the new array's volume IDs is what keeps the migration auditable — and keeps anyone from accidentally reclaiming the wrong disk six months later.

Cutover: The Short, Nerve-Wracking Part

Once a host's volumes are virtualized and ready, the actual cutover is intentionally brief. The server is brought down, its zoning to the old array is removed, and its volumes — now represented on the new array — are mapped back to it. The server boots up, discovers its storage on the new platform, cleans up any leftover references to the old devices, and brings its application volumes back online.

From there, the operating system team validates the server, and the application teams validate their software on top of it. Only once everyone is satisfied does responsibility shift fully back to the storage team — because the job isn't finished yet. The data is still, physically, sitting on the old array. At this point the Hitachi array is operating like a proxy receiving the commands from the host and responding with the data from the old array.

The Quiet Part: Migrating the Data in the Background

With the host now running happily on the new array (even though its data is still technically “routed” from the old one), the storage team kicks off a background replication process to physically copy every virtualized volume onto native storage on the new array. This runs as a standard array-to-array copy job, and it can take anywhere from hours to a couple of days depending on the amount of data involved. The host performance is not impacted and production can continue.

The host never notices. It's still reading and writing through the new array the entire time; the array itself is simply relocating the underlying blocks behind the scenes. Once each volume's copy reaches 100%, the array automatically swaps the volume's identity so the newly-copied, natively-owned volume becomes the volume of record — no second outage required. The only thing the hosts will see is improved performance on the newer architecture.

Cleaning Up

After the background copy finishes and gets verified, there's housekeeping left to do: the temporary migration volumes and their associated scaffolding get torn down, and the connection to the old array's volumes are formally disconnected and removed. One extra step is worth mentioning — because every block gets physically copied during this kind of migration, including all the empty space, freshly migrated volumes often report as fully used even when they're mostly empty. Running a space-reclamation pass afterward corrects that and gives an accurate picture of real usage going forward.

Multiply this whole sequence by every server being migrated, and that's the project: prove the path, virtualize the volumes, handle the boot disk carefully, cut over quickly, migrate quietly in the background, then clean up.

Why Go to the Trouble

Why not just schedule a long weekend outage and copy everything the old-fashioned way. The reason teams use UVM-based migrations instead comes down to risk and downtime. Separating “the host is on the new array” from “all the data has physically moved” means outage windows measured in minutes rather than the hours or days a straight copy-and-cutover would require, and it leaves a real, working fallback path available for as long as the team wants it. For boot-from-SAN systems, where a mistake means a server that won't start, that safety margin is worth the extra planning.

If your organization is staring down an aging storage platform and weighing how to retire it without a white-knuckle weekend, this kind of migration approach is worth having in the conversation. We have help teams plan and execute thousands of hosts using this method — reach out if you'd like to talk through what it would look like in your environment.

‍