Migrating 1,500 VMs From VMware vSAN to Proxmox: What Goes Wrong

When "migration" stops being a buzzword and starts feeling like risk

Migrating a handful of VMs is one thing, and staring down a number like 1,500 is another. At that scale the project turns into a gamble with real consequences. The plan sounds clean on paper: move everything off VMware vSAN and land safely in Proxmox. Almost immediately, though, the cracks show.

The first issue hits fast, because there's no clean bridge out of vSAN. One engineer summed it up bluntly: "Option #1 won't work… migration job will fail." That forces an awkward reality. Instead of migrating directly, you're staging, hopping, and juggling storage layers just to get data out, and every extra step adds time, risk, and the chance that something breaks mid-flight.

Automation looks like the answer at first

Everyone agrees that you can't do this manually, not even close. That's where the CI/CD dream kicks in, with GitLab runners, Ansible playbooks and Terraform provisioning. It all sounds like a clean pipeline: export, convert, import, done.

Technically, it works. One voice confidently laid it out: "Terraform for provisioning infra & Ansible on top for migration." That's the ideal.

Then reality creeps in. Automation amplifies complexity, because now every mistake scales across hundreds of machines. One bad playbook or one wrong assumption about drivers or networking, and you're firefighting across dozens or hundreds of VMs at once instead of fixing one.

The discussion also contains a telling admission: people have done large-scale automation before, even at 8,000 servers. That doesn't make it easy. It just proves it's survivable.

The Windows problem nobody wants to own

If Linux is the easy part of this story, Windows is where things get messy fast, practically more than conceptually: drivers, boot issues, and blue screens waiting to happen.

Some engineers have built workflows that feel almost ritualistic at this point. Install VirtIO drivers before migration. Remove VMware Tools at the last possible moment. Boot once with SATA just to "wake up" the driver, then switch to VirtIO. It isn't elegant, but it works.

"I do one boot with the system disk as SATA… then switch," one person explained. Another went deeper, using tools like devcon to inject drivers before the hardware even exists.

Here the tone shifts from architecture to survival tactics. Everyone has a slightly different method, and none of them feels bulletproof, just tested enough to trust.

Speed vs downtime: pick one

One of the hardest facts about this whole process is that you don't get everything. Out of speed, low downtime and simplicity, you'll sacrifice at least one.

Some lean on backup tools like Veeam because "normal import is too slow." Others accept the downtime hit because it's more predictable. There's frustration here, especially around the lack of true replication into Proxmox.

"We've done backup & restore… but downtime is more than we want." That's the trade-off in plain terms: faster methods often mean more risk, and safer methods cost you uptime.

When you're dealing with hundreds or thousands of systems, downtime turns political as well as technical, because someone is always waiting for those systems to come back online.

The hidden layer: storage is the real bottleneck

What emerges from all of this is that storage, more than compute or automation, is the real constraint. vSAN doesn't play nicely with direct migration paths, which forces workarounds: intermediate NFS shares, temporary storage systems, even spinning up something like TrueNAS just to move data around.

At this scale, moving data becomes the dominant problem, ahead of configuring VMs or scripting workflows. The hard part is moving bits from one place to another without breaking them. That's where many plans slow down, even well-designed ones, because the underlying systems weren't built to cooperate in the first place.

Three mindsets, one massive decision

Looking across all the perspectives, three distinct mindsets emerge.

First come the optimists. They believe in automation, pipelines and clean architecture, and with the right tools this is just a large but manageable project.

Second are the pragmatists. They've done migrations before and know it's messy, full of edge cases, and held together by scripts and workarounds. They care about what works more than what's elegant.

Third are the cautious ones, worried about downtime, data integrity and the sheer blast radius of mistakes. For them, every step is a risk calculation.

None of them is wrong, because a migration like this is strategic as well as technical. Moving the VMs means changing the foundation everything runs on, and once you start there's no clean way to pause halfway. Few people say that out loud, but you can feel it in every comment.