A SAN fabric migration is one of the few infrastructure changes where the storage stays where it is and the network around it moves. That inversion is what makes it dangerous. Arrays keep serving, hosts keep issuing I/O, and the only thing changing is the path between them — so mistakes surface as application failures rather than as a scheduled outage.
Most fabric migrations are designed around redundancy: two independent fabrics, so one can be worked on while the other carries production. The design is sound. What breaks it is the assumption that the redundancy is actually there on the day.
How Do You Verify Path Redundancy Before Migrating?
Map every host's paths before anything is touched, because dual-fabric designs degrade quietly. Servers get added in a hurry, a second HBA fails and is never replaced, a multipath policy gets set to fixed during troubleshooting and never set back. None of it causes a problem while both fabrics are healthy, which is exactly why nobody notices.
Build a path map before anything is touched:
- Every host, every HBA WWPN, and which fabric each one logs into
- Active path count per LUN and the multipath policy in effect
- Array port distribution — which controller and port group serves each host
- Anything single-attached, dual-attached to the same fabric, or running all I/O down one path
Hosts with fewer than two paths across two genuinely independent fabrics are not protected by the A/B plan. Fix them beforehand or schedule them into their own outage window. Discovering them mid-cutover converts a routine change into an incident.
Capture the Configuration as a Baseline
Export before you change anything
- The full zone set: active configuration, defined configuration, aliases, and zone membership
- Switch configuration, including domain IDs, port names, speed and fill-word settings, trunking and ISL configuration
- Firmware versions and licensing state on every switch
- Name server and device connectivity output as a point-in-time record of what was logged in
Export the zone set in a format you can diff. After cutover, "did anything change?" should be answered by a file comparison, not by recollection.
Zoning Style Determines Your Options
Port-based zoning binds access to a physical switch port. Move the device to a different port and the zone is wrong. WWPN zoning follows the device regardless of where it plugs in.
If the environment uses port-based zoning and ports are changing, the zoning has to be rewritten as part of the move. Convert to WWPN zoning as a separate, earlier change with its own validation rather than folding it into cutover night.
Why Do Fabric Merges Fail?
Usually on configuration details the two sides disagree on. When new switches join an existing fabric, the merge either succeeds or the link segments. Segmentation is not always obvious — the ISL comes up, the switches disagree, and the link isolates itself while everything else looks normal.
Common causes:
- Duplicate domain IDs between the joining switches and the existing fabric
- Zoning database conflicts, particularly identical zone or alias names with different membership
- Default zoning policy mismatch, where one side denies by default and the other permits
- Incompatible firmware levels or interop mode settings
- Mismatched fabric timeout values (R_A_TOV, E_D_TOV)
Resolve all of these on paper before any ISL is cabled. A merge conflict discovered at 2 a.m. is resolved by disconnecting the link, which puts you back where you started with hours burned.
Should You Migrate Both Fabrics at Once?
No. Work fabric A to completion. Validate. Soak. Then work fabric B.
The soak period should cover at least one full nightly batch cycle and one business-hours peak — 24 hours is a reasonable floor. Marginal problems do not appear under light load.
While fabric A is being worked, the entire environment is effectively single-pathed. That has consequences beyond the fabric team:
- Freeze unrelated host and array maintenance for the duration
- Suspend firmware updates and controller failovers
- Make sure the operations team knows a single failure now has no backstop
Never touch both fabrics in the same window, no matter how small the change looks.
Cutover Mechanics
Pre-stage destination switches completely — firmware, configuration, licenses, and optics installed and verified — before move night. Confirm optic compatibility and negotiated speeds, and check that cable lengths stay inside the loss budget for the link type.
Label both ends of every cable before unplugging anything, and let the port map drive re-cabling rather than working from what looks right. Move host and array ports in matched groups, and verify name server registration and zone membership after each group rather than saving all verification for the end. Finding a problem after three ports is a small problem; finding it after forty is a long night.
Validation That Means Something
Per host
- Path count restored to the pre-move value
- Paths in the expected active/optimized state, not standby
- Multipath policy unchanged
- Clean host logs — no repeated login failures or path flapping
- Array-side host mapping and LUN masking intact
Per fabric
- Active zone set matching the exported baseline byte for byte
- No segmented ISLs
- Port error counters clean: CRC errors, encoding errors, link resets
- Throughput and latency compared against a pre-move baseline under real load
Error counters deserve particular attention. Clear them after cabling, then check again after 24 hours. A dirty connector or a marginal optic produces a slow trickle of CRC errors that looks like nothing on day one and like a storage outage on day ten.
How Does Distance Change a SAN Migration?
If the destination adds physical distance — a campus link, a metro span, a new DWDM path — buffer-to-buffer credits become a design input rather than a default. Credits sized for a 10-meter link will not sustain line rate over 10 kilometers. The failure mode is not a dropped link; it is throughput that collapses under load while every status light stays green.
Calculate credits for the actual distance and link speed, and validate with a sustained load test rather than a connectivity check.
Handover
Close the project with a final zone set export, an updated port map, the refreshed path map, and the 24-hour error baseline, and push the changes into the DCIM and CMDB the same day. A fabric that works but is undocumented has not eliminated risk — it has transferred it to whoever troubleshoots it next.