Storage Migration: Planning the Part That Goes Wrong
Storage migrations are planned around the copy and go wrong everywhere else. The data movement is usually the predictable part; the cutover, the dependencies and the things nobody documented are where the outage comes from.
Find out what actually uses the storage
The step that determines whether the cutover is uneventful.
A volume rarely has one consumer. There are usually mounts on machines nobody remembers, scheduled jobs writing reports, backup jobs pointed at paths, monitoring checks, and applications with the location hard-coded in a configuration file.
Two ways to find them. Check what has the volume mounted or connected from the storage side, which finds current consumers. And look for the path in configurations and scripts, which finds the intermittent ones — the monthly job that will fail three weeks after you thought the migration was finished.
The technique from our decommissioning guide applies here too: where practical, make the old location temporarily unavailable and see what complains.
Size the destination properly
Migrations frequently arrive short because raw capacity was matched instead of usable.
Start from usable capacity required, add growth headroom for the life of the new array, apply the RAID multiplier for the level you have chosen, add hot spares, then convert to decimal for ordering. Our capacity guide covers the arithmetic and our planning guide covers forecasting the growth part.
A migration is also the natural moment to reconsider the design rather than copying it. RAID 5 that was defensible on 2TB drives is inadvisable on modern capacities — our RAID guide covers why rebuild windows change the answer.
And check what is actually being moved. Migrations frequently carry across old snapshots, unrotated logs, duplicate copies and data whose retention expired years ago. Reviewing that before sizing sometimes reduces the requirement substantially.
Tier the data rather than moving it wholesale
The opportunity most migrations miss.
Most estates have a small amount of data accessed constantly and a large amount accessed rarely. Moving all of it onto the same new storage means paying performance prices for archive data.
Splitting hot data onto flash and cold data onto nearline capacity storage is almost always cheaper and faster than either extreme. Our SSD versus HDD guide covers where each belongs.
One rule that constrains this: tier between RAID groups, not within them. A group runs at its slowest member, so mixing drive types inside one group gives the worst of both.
Compatibility on the destination
Three checks before ordering drives for the new array.
Array drives frequently differ from server drives, even from the same manufacturer, with different part numbers and firmware. Fitting a server drive into a storage array may produce one the array refuses. Our storage architecture guide covers this.
Carrier and form factor must match the enclosure. Our compatibility guide lists this by platform.
Controller and firmware compatibility with the operating systems that will connect. Check the compatibility list for the OS version you will run, not the one currently installed — our HCL guide covers why this is where projects stall.
Run both in parallel
The single most valuable practice, and the one budgets cut first.
Keeping the old storage available and populated after cutover means a problem is resolved by switching back rather than by restoring from backup. That difference is measured in hours versus days.
Keep it for long enough to cover the intermittent consumers — at least one full cycle of monthly jobs, and ideally a period covering quarter-end or whatever your longest cycle is.
Do not decommission until you are confident nothing is still reaching for the old location. Then follow the sanitisation steps before the old drives leave your control.
Cutover
Three practical points.
Verify the copy rather than trusting completion. A job reporting success is not the same as data being correct and complete. Check counts, sizes and a sample of content, and confirm permissions and ownership survived — those are frequently what break rather than the data itself.
Expect the final synchronisation to take longer than estimated. Changes accumulate during the bulk copy, and the final delta on a busy system is rarely small.
Have a documented way back. Written down, tested if possible, and decided in advance — including who makes the call and at what point.
Before you start
Verify backups restore, because a migration is a period of concentrated risk to data. Confirm what consumes the storage, including intermittent jobs. Size the destination from usable capacity with growth. Check drive and controller compatibility for the platform and OS version. Plan parallel running through at least one full monthly cycle. And write down the rollback.
Send us the destination platform and required usable capacity and we will confirm drive compatibility and quantities.
Common questions
What causes most migration problems?
Undiscovered consumers rather than the copy. Mounts on forgotten machines, scheduled jobs, backup paths, monitoring checks and hard-coded locations in configuration files — particularly the intermittent ones that fail weeks later.
Should I match the old array’s capacity?
Size from usable capacity required plus growth, not from the old array’s raw figure. It is also the natural moment to reconsider the RAID design and to review what is actually being carried across — old snapshots and expired data frequently reduce the requirement.
How long should I keep the old storage?
Long enough to cover intermittent consumers — at least one full cycle of monthly jobs, ideally through quarter-end. Parallel running means a problem is resolved by switching back rather than restoring from backup, which is hours versus days.
Can I use server drives in a storage array?
Frequently not, even from the same manufacturer. Array drives often carry different part numbers and firmware, and the array may refuse a server drive. Order against the part number of a drive already fitted.
What should I verify after the copy?
Counts, sizes and a sample of content, plus permissions and ownership — those frequently break where the data itself does not. A job reporting success is not the same as data being correct and complete.
Send us the destination platform and required usable capacity and we will confirm drive compatibility and quantities.
