Migrating 200+ VMs to Proxmox Isn't a Compute Problem — It's a Networking One

On paper, moving hundreds of virtual machines from VMware to Proxmox sounds like a compute story. Storage throughput. CPU compatibility. Disk formats. Import tools. Checklists. Progress bars. In practice, that's not what keeps people up at night. What actually causes the cold sweat is networking. Not the clean, diagrammed version that lives in a Visio file from 2019, but the real one. The messy one. The one with hardcoded IPs, forgotten firewall rules, MAC-based licenses, silent database dependencies, and traffic flows nobody remembers setting up. When you're moving 200-plus VMs off VMware ESXi, the hypervisor switch is rarely what breaks things. It's everything wrapped around it. ## The import works. The apps don't. Almost everyone who's done this at scale says some version of the same thing: the Proxmox import wizard does its job. Disks come over. Machines boot. CPUs spin. Memory looks fine. Then something subtle fails. An application starts but can't talk to its database. A reporting job runs but never finishes. A legacy service doesn't error out — it just quietly stops doing useful work. Monitoring lights up hours later, or worse, a user notices days after the migration window has closed. That's the danger zone. Silent breakage is harder than loud failure. Loud failure gives you a place to start. And nearly every one of those failures traces back to networking. ## Hardcoded reality always wins In theory, everything should be abstracted. DNS instead of IPs. Service discovery instead of static configs. Firewall rules documented and intentional. In reality, plenty of environments grew organically over a decade or more. Someone hardcoded an IP because it was "temporary." Someone linked an app directly to a database because it was faster. Someone set up a hairpin firewall rule to solve one weird problem and then forgot about it. Those choices don't show up when you export a VM. They only show up when traffic stops flowing the way it used to. That's why so many experienced admins aren't talking about CPU flags or disk formats when asked how to migrate at scale. They're talking about traffic monitoring, VLANs, ARP tables, and MAC addresses. ## If you don't see the traffic, you don't know the app One of the most common pieces of advice from people who've already done large migrations is blunt: the network does not lie. Before you move anything, you want to see who's talking to whom. Not who you think should be talking — who actually is. That usually means some combination of: - Firewall logs of allowed traffic - NetFlow or IPFIX exports into a traffic analysis tool - Port mirroring on switches or virtual bridges - Targeted packet captures for especially suspicious systems It's not glamorous work. It's also not optional at scale. You're looking for patterns that never made it into documentation. An app server quietly chatting with a file server over an old subnet. A batch job that only runs once a week. A legacy database that everything still depends on even though nobody admits it. This is where migrations stop being about virtualization and start being about archaeology. ## Monitoring isn't just for after the move A lot of teams already rely heavily on monitoring tools like Zabbix or similar systems. What changes during a migration is how much trust you put in them. At scale, monitoring becomes your safety net. The thinking shifts from "did this VM boot?" to "did all its dependencies come back green?" Several admins describe the same workflow: migrate one VM or a small group, wait for monitoring to settle, then move on. If something breaks, add a new check. Rinse. Repeat. That approach doesn't prevent every issue, but it keeps problems contained. You learn early which applications are fragile and which ones don't care what hypervisor they're running on. And yes, this takes time. People who've moved 300-plus VMs talk in weeks, not days. Anyone promising a clean weekend cutover is either very lucky or very wrong. ## IPs, VLANs, and the illusion of sameness One of the simplest ways to reduce risk is also one of the most boring: keep IP addresses the same. When VMs come up with the same IP, same VLAN, and same gateway, an entire category of problems just disappears. DNS doesn't need to change. Firewall rules don't need rewriting. Applications don't suddenly find themselves talking to the wrong thing. But "keeping things the same" only works if your physical and virtual networking is actually aligned. If your top-of-rack switches don't have the right VLANs trunked, the VM can boot perfectly and still be isolated. If tagging changes between environments, traffic can vanish silently. If ARP tables don't update cleanly, you get ghost connectivity issues that feel random until you remember they exist. This is where migrations expose weak spots in network design. Not because Proxmox is different, but because change forces reality to surface. ## MAC addresses: small detail, big fallout MAC addresses are one of those details you don't think about until a vendor ties licensing to them. Plenty of Linux workloads handle MAC changes gracefully, or can be configured to keep the old one. Windows VMs are less forgiving when the virtual hardware changes underneath them. Sometimes they'll happily adapt. Sometimes they'll re-enumerate devices and make a mess. And then there's Oracle. Or any other software that treats MAC or UUID changes as a licensing event. This isn't really a Proxmox problem. It's a reminder that virtualization abstracts hardware, but licensing vendors never got that memo. ## Why "just migrate slowly" is real advice "Migrate one by one" sounds obvious until you're staring at a spreadsheet with 200 rows and a business asking how long this will take. The people who've done this successfully tend to agree on one thing: batching intelligently beats rushing blindly. You move a small set. You validate. You fix what breaks. You update documentation that should've existed already. Then you move the next set with fewer surprises. It's not fast. It is predictable. And predictability is what keeps migrations from turning into all-hands fire drills. ## This isn't really about Proxmox Here's the part that surprises newcomers: none of this is unique to Proxmox. You'd hear the same stories moving to KVM, Hyper-V, or a public cloud. The hypervisor swap just removes the safety blanket of familiarity. Suddenly, assumptions get tested. Proxmox is often the messenger, not the culprit. What it does well is force teams to confront how their systems actually communicate. Which is uncomfortable. And useful. ## The real takeaway If you're planning a large ESXi-to-Proxmox migration and you're spending most of your time thinking about compute and storage, you're probably underestimating the hardest part. The work lives in the network. In the undocumented flows. In the dependencies nobody owns anymore. In the monitoring alerts that tell you something is wrong but not why. Treat this like a networking project with a virtualization component, not the other way around. Do that, and the import wizard really will be the easy part.