Introduction

A storage migration can present the new SAN fabric while hosts still discover or prefer paths through the old one. New LUNs appear on some servers but not others, multipath shows the previous fabric as active, or storage access breaks only after the old switches are removed because zoning, aliases, HBA target visibility, and multipath policy often remain tied to the earlier fabric.

Treat this as a storage-path problem instead of a generic host or disk outage. Start by checking which WWPNs, zones, and active paths an affected host actually sees in the live fabric, because migrations often validate the new array and switches separately while production hosts continue logging into older targets.

Symptoms

  • A Fibre Channel host still sees or prefers the old SAN fabric after migration
  • Multipath continues showing active paths through the retired fabric or array ports
  • One host or HBA uses the new fabric while another still discovers the previous one
  • Storage access fails only after the old SAN switches or zones are removed
  • The new fabric is online, but host path selection still depends on the old path
  • The issue started after moving Fibre Channel switches, arrays, or zoning policy

Common Causes

  • Zoning still includes the old fabric targets or aliases for one host group
  • Switch aliases, zonesets, or active configuration were updated on one fabric but not the other
  • HBAs still log in to the old target WWPNs because discovery or masking was not fully moved
  • MPIO or PowerPath policy still prefers the previous target paths
  • Automation or SAN templates keep reactivating old zoning definitions
  • Validation confirmed the new fabric was visible but did not verify which paths hosts actually logged into and preferred

Step-by-Step Fix

  1. Capture one affected host and record the active WWPNs, zones, target ports, and multipath state it actually uses, because the runtime storage path determines which fabric carries production I/O.
  2. Compare that active path set with the intended post-migration SAN design, because one stale zoneset or alias can keep important hosts tied to the retired fabric.
  3. Review switch zoning, aliases, active zonesets, HBA target visibility, LUN masking, and multipath policy for references to the old fabric, because Fibre Channel access depends on switch and host path configuration together.
  4. Check each host cluster, HBA pair, and fabric separately if behavior differs, because migrations often fix one path set while another still sees the previous fabric.
  5. Update the authoritative SAN configuration so affected hosts log in to and prefer the intended fabric and target ports, because cabling the new SAN alone does not retarget existing host discovery and path policy.
  6. Rescan storage on an affected host and confirm the intended fabric handles the active paths and LUN visibility, because seeing disks at the OS layer does not prove the right fabric is carrying I/O.
  7. Verify the old fabric no longer carries active host sessions or preferred multipath traffic from migrated systems, because split storage paths can remain hidden while both fabrics stay online.
  8. Review HBA firmware, path-claim rules, and LUN masking if hosts still fail to switch, because the destination can be correct while host path policy still favors the old fabric.
  9. Document which team owns zoning, host HBA policy, and migration validation so future SAN cutovers verify the actual active fabric per host before retiring the previous environment.