SAN capacity planning before a migration means measuring what a storage estate actually holds and does (consumed and effective capacity, growth, and peak performance) and reclaiming waste before anything is copied. Migrations are usually scoped from allocated capacity, the number on the array's front page, which is the number least connected to what the new environment must deliver.
Allocated is not consumed, consumed is not active, and none of the three describe performance. A migration sized on allocated capacity typically buys too much of the wrong thing: enough terabytes, not enough throughput, and a set of inherited inefficiencies that move across intact and reappear on newer equipment.
How Much Data Is Actually Stored?
Three numbers, in the terms the SNIA storage networking primer uses, describe a storage estate and they are frequently far apart.
Allocated capacity is what has been provisioned to hosts. With thin provisioning it can exceed physical capacity substantially and says little about anything.
Consumed capacity is what hosts have actually written. This is the number that must land on the target, and on most estates it is considerably smaller than allocated.
Effective capacity accounts for deduplication and compression. Data reduction ratios differ between platforms — an estate achieving 3:1 on one array may achieve less on another with different algorithms or block sizes. Sizing a target on the source's reduction ratio is an assumption worth testing with the vendor against a real sample rather than a published figure.
Growth rate matters as much as the current figure. Twelve to twenty-four months of historical consumption tells you the trend, and the target should be sized for the end of its service life rather than for cutover day.
Which Performance Metrics Should You Measure?
Peak IOPS, throughput, tail latency, and read/write mix, because capacity is the easy dimension. Performance is what determines whether applications behave after the migration, and it is routinely omitted from sizing.
Collect IOPS at peak rather than average. Storage demand is spiky, and an array sized for the mean will disappoint during month-end processing, overnight batch windows, and whatever else concentrates load.
Collect throughput separately, because IOPS and megabytes per second are different constraints. A workload doing large sequential reads saturates bandwidth at modest IOPS; a transactional workload does the reverse.
Record latency at the same percentiles the applications care about. Average latency conceals the tail, and the tail is what users experience.
Capture the read and write mix, and the degree to which the working set is random or sequential. These determine how caching and tiering behave on the target, and a platform that performs well on one profile can perform poorly on another.
Sample over a full business cycle. A week of data misses month-end; a month misses quarter-end.
What Should Be Reclaimed Before Migrating?
Orphaned volumes, stale snapshots, over-provisioned allocations, and expired data. A migration is the one moment when reclaiming capacity is straightforward, because everything is being examined anyway.
Orphaned volumes — provisioned, no longer attached to any host — accumulate in every estate. So do snapshots retained long past their policy, clones from projects that ended, and volumes belonging to decommissioned systems that were never reclaimed. Identifying them is a reconciliation exercise against the host inventory, which pairs naturally with reconciling the wider asset record.
Over-provisioned volumes are the larger prize. Applications routinely sit on allocations many times their consumption because the original request was a guess and nobody revisited it.
Data that should not be on primary storage at all — archives, stale project data, anything under a retention policy that has expired — can be moved to a cheaper tier or deleted, subject to any legal hold that applies. Deleting data during a migration requires the same authority as deleting it at any other time.
Reclaiming before migrating reduces what has to be copied, shortens the cutover window, and reduces what has to be bought. It is the highest-return work in the whole project.
Plan the Transfer Itself
The copy is a logistics problem with a duration that has to fit the business's tolerance.
Calculate transfer time from consumed capacity and the bandwidth available between source and target, then adjust for the change rate — data that keeps changing during a long copy has to be re-synchronized, and for active datasets that tail can be significant.
Choose the method against the tolerance for disruption. Array-based replication is efficient and generally requires compatible platforms. Host-based migration works across any platforms and consumes host resources. Appliance-based virtualization inserts a layer that enables non-disruptive movement and has to be installed and later removed.
Where the network cannot move the volume in an acceptable window, physical seeding — copying to portable media and shipping it — is a legitimate option, and it becomes a chain of custody problem governed by the same controls as any data-bearing transport and by the storage protection guidance in NIST SP 800-209.
For estates large enough that the copy itself becomes the project, storage infrastructure services cover the physical side (racking, cabling, and installing the target arrays), while your IT team owns the sizing and the transfer. Fabric capacity needs checking alongside the arrays. A migration that saturates inter-switch links degrades production while it runs, which makes it part of the same design question as path redundancy across the fabric.
Validate Against the Baseline You Took
The performance data collected during planning has a second use: proving the migration succeeded.
Compare post-migration latency, IOPS, and throughput against the pre-migration baseline for the same workloads at the same points in the cycle. Without that comparison, "it feels slower" is unanswerable, and it is a claim that surfaces after every storage migration.
Verify the copied data independently of the migration tool's own reporting, with checksums or application-level consistency checks on a meaningful sample.
Keep the source available and unchanged until validation is complete and your IT team's regular protection jobs have run a full cycle against the target. The cost of retaining old hardware for an extra few weeks is trivial against the cost of discovering a problem after the fallback is gone.