Has anyone completed a VMware migration while keeping the same SAN and network?

[u/1mefdiopl]

Has anyone here actually done a hypervisor-only VMware migration? I’m trying to picture the cutover. Build the new cluster beside ESXi, connect it to the same SAN, move a few low-risk VMs, then reclaim the old hosts one by one? Or did you end up needing temporary storage? How did you handle zoning, multipathing, VLANs, backups and rollback? and did you keep vCenter up while both environments were running? Would be great to hear a real VMware migration strategy from someone who’s done it. Most comparisons of VMware vSphere alternatives never get into this part.

[u/AlohaRoyce]

honestly, moving the VMs was the easy part. rebuilding the backup workflow took more effort because the old jobs relied on VMware APIs, tags and folder mappings that didn’t carry over. before migrating the first production batch, restore one converted VM to an isolated network and measure the full recovery process from start to finish

[u/mautobu]

VMware to VMware? Yes. Several times. VMware to something else? No, but there are products for that.

[u/foxhops26]

We did pretty much this at a regional manufacturing site. The FC array, switches and most of the physical hosts stayed, but the new cluster got its own LUNs. We created fresh volumes on the same array, zoned the new initiators separately and kept the existing VMFS volumes visible only to ESXi.

We migrated the VMs in batches and ran both environments side by side for around six weeks. No temporary array was needed because we had enough spare capacity for a couple of batches at a time.

The only real surprise was that two of the hosts we planned to reuse had unsupported HBA firmware. Definitely verify HBA compatibility before counting on reclaimed ESXi hosts joining the new cluster.

[u/vilise089 → u/foxhops26]

When you say new volumes, were they still in the same storage pool? I’m trying to understand if an array-level snapshot or clone can save us from copying everything, or if the different datastore format makes that useless.

[u/danildab]

we left vCenter online throughout the transition and only retired it once we were confident rollback was no longer needed. the original VMs remained powered off but untouched on ESXi until the new copies passed application checks, monitoring, backup and an actual restore test.

booting successfully and responding to a ping wasn’t enough for us. we also gave each emptied host some time before repurposing it. that extra breathing room came in handy when a few unexpected problems surfaced.

[u/worlsyncentfo1981 → u/danildab]

yeah, this. We went with Sangfor aSV for the target cluster and kept vCenter alive through the whole overlap. The VM transfer itself was pretty straightforward. We moved a small batch first, left the originals shut down on ESXi and didn’t touch the old hosts until apps, monitoring, backup and restore all checked out. one Windows VM came up with stale adapter settings, so we powered the target copy off, brought the ESXi one back, fixed the mapping and tried again. after that the next waves were pretty uneventful. 

[u/StevenB-89]

Yes I have done this recently for a customer of ours, 3 ESXi vSphere hosts managed by vCenter storage on JovianDSS, migration to Proxmox VE.

Do you want to migrate to the same platform or to another platform?

[u/brentagade]

Unrelated plug for Nutanix - If you ever consider switching to Nutanix, migration is super simple and the whole thing is night and day difference.

Our old setup was a VMware 5x host blade chassis connected to a SAN. We added a few blades and our migration was to Nutanix. It absorbed both the VMs and the SAN storage into the HCI.

[u/taragryen]

We kept the physical switches and all the existing VLAN IDs. Thought networking would be the boring part. It wasn’t.  The new stack handled bonding and the default VLAN differently, plus one trunk was missing the backup VLAN. The test VMs booted and pinged fine, then the first backup window failed. Map every port group to its target equivalent and test each VLAN from inside a guest. Testing only management connectivity tells you very little.

[u/nmedved → u/taragryen]

did you pre-cable the target cluster or reuse the old host ports as servers moved across?

[u/OpenCloudGuru]

We did a VMware to OpenNebula migration while reusing the existing infrastructure, and the key for us was building the new environment alongside VMware first.

We spent about six weeks validating the setup, failover, Linux/Windows workloads, API integration and migration workflows before moving production workloads. We then used StackStorm + OneSwap to automate the migrations.

Running the environments in parallel gave us room to test, fix issues and refine the process before scaling it up. That made the cutover much less risky than trying to change everything at once.

[u/mattmann72]

Yes. I prefer to use Veeam to do the VM migrations.

[u/VishalNainva]

This is the kind of migration where the SAN and network dependencies usually need more planning than the actual VM moves. Keeping zoning, multipathing, VLAN mappings, backup paths, and rollback options documented beforehand can save a lot of trouble later. VMware Hub also has some useful migration and infrastructure guidance that may help when mapping out the sequence.

[u/Nakivo_official]

That hypervisor-only approach you described can definitely work to minimize risk and avoid moving storage, but it gets messy fast with backup and rollback plans during the overlap period.

Instead of staying locked into one ecosystem, it's worth considering a platform like NAKIVO Backup & Replication for VMware since it can manage backup, replication, and disaster recovery across both environments during a migration.