Storage array relocation is the physical move of controllers, disk shelves and drives from one facility to another, planned around three facts: the hardware is heavy, it holds data that cannot be recreated, and it must be shut down in the vendor's documented order. Your storage team owns the data and the shutdown; the move crew owns the hardware.
Why are storage arrays harder to move than servers?
A storage array combines the three things that make relocation difficult. It is physically heavy and awkward, concentrated in a footprint that resists ordinary handling. It holds state that cannot be recreated. And it depends on a controlled shutdown sequence that, done incorrectly, risks the consistency of everything on it.
Servers can be rebuilt. The data on the array is the thing the entire environment exists to hold, and it is the one component of a migration where the failure is not recoverable by trying again.
| Task | Owner |
|---|---|
| Verified, restorable copy of the data on separate media | Your storage team |
| Host quiesce, cache flush, controller and shelf shutdown | Your storage team or the array vendor |
| Zoning, masking, WWN and host mapping export | Your storage team |
| Drive slot mapping and physical labeling | Move crew, checked by your storage team |
| De-install, crating, lifting, transport, re-racking | Move crew |
| Cable labeling at both ends and re-cabling to the record | Move crew |
| Array health checks, host connectivity, data validation | Your storage team or the array vendor |
What does your IT team need to finish before the array moves?
A current, verified, restorable copy of the data on separate media, ideally in a separate location.
The array may not survive the move: controllers fail, disks that have run for years do not always restart, and transport is a stress event. The copy is what makes that outcome survivable rather than catastrophic.
Verify by restoring something, not by reading a job log. A job that reports success and data that can actually be restored are different claims, and the gap between them is discovered at the worst possible time.
If data volume makes a full copy impractical within the window, escalate that before the move rather than working around it quietly.
What is the correct shutdown order for a storage array?
The vendor's documented order, followed exactly by your storage team or the vendor's engineer. Arrays hold uncommitted data in write cache; a clean shutdown flushes it, and an abrupt power loss does not, with consequences from a lengthy consistency check to actual data loss.
The general shape is: quiesce host I/O, unmount or disconnect hosts, flush cache, then shut down the controllers, then the disk shelves. Confirm each step completed before proceeding, and confirm cache has flushed before power is removed. It is the single check most worth confirming. The move crew should not unplug anything until the owner signs off (see shutdown and power-on sequencing).
Check cache batteries: old ones may be near end of life, and an array sitting unpowered in transit can exhaust them. Some vendors recommend replacing cache batteries before a move; at minimum, know their state.
Should drives travel in the array or separately?
It is vendor-specific, and the vendor's transport guidance is the authoritative answer.
Most modern arrays are designed to be transported with drives installed, provided the equipment is properly restrained and the shock limits are respected. Removing drives introduces its own risk: connector wear, static exposure, and the possibility of reinstallation in the wrong slot. Handle removed drives under ESD controls such as those in the ESD Association standards, packed in anti-static materials (see anti-static packing for IT equipment).
Where drives are removed, slot mapping is critical. Many arrays tolerate drives returning to different positions and some emphatically do not,. Map every drive to its bay, label physically, and reinstall exactly.
How do you handle the weight and shock limits?
With a mechanical lift, a low center of gravity, and transport that respects the vendor's shock and orientation limits. A populated disk shelf is heavy, and a fully loaded array with multiple shelves is beyond manual handling entirely.
Load racks bottom-up with the heaviest components lowest. Storage placed mid-rack for cabling convenience raises the center of gravity and makes the cabinet unstable to move.
Respect shock and vibration limits. Spinning disks are more vulnerable in transit than most equipment, and the limits in the vendor documentation are not conservative padding. Air-ride transport, proper restraint, crates designed against recognized packaging test procedures such as those from ISTA, and shock indicators on the crate are all proportionate for a loaded array.
Keep the array upright and oriented as specified; equipment that cannot be laid down fails in ways that are not immediately obvious. This physical handling is the core of a storage array relocation.
How do you protect fabric and host connectivity?
Export it before disconnecting anything, and label every cable at both ends. Zoning, masking, multipath configuration, and host mappings all determine whether hosts can see their storage after the move.
Your storage team exports the fabric configuration (zoning from the switches, masking from the array) and records WWNs and their mappings. The move crew labels every fibre channel connection at both ends and re-cables to that record. A mis-cabled array at the destination may present the wrong LUNs to the wrong hosts, which is a worse outcome than presenting nothing at all.
Where the destination fabric differs, your team should design the new zoning during planning, not at two in the morning on move day. See migrating SAN fabrics with path redundancy.
How do you bring the array back up?
Power on in reverse order: disk shelves first, allowing them to spin up and be recognized, then controllers.
Let the array finish its startup consistency checks before hosts connect and production I/O arrives.
Your storage team or the vendor then verifies at the array level first: all disks present and healthy, all volumes online, no degraded RAID groups, cache functioning and batteries charged. Then host connectivity, multipathing on all paths rather than just the active one, and finally the applications themselves.
Confirm the data. Application-level validation against known values is the only check that actually answers the question the entire exercise was about, and it belongs in the plan as an explicit step with a named owner on your team rather than as an assumption that green status lights imply correct data.