Migrate from VMware vSphere to Proxmox VE: what the move involves
If a Broadcom renewal, a per-core quote or a data residency requirement has put vSphere on the table, the first thing to know is that Proxmox VE can take most VMs through its built-in ESXi and vCenter import wizard, but vSAN-backed disks, VMs with snapshots and host-level features need a separate plan. Proxmox's import wizard arrived in Proxmox VE 8.2, and the wiki documents that the ESXi import was tested from ESXi 6.5 to 8.0. Treat that tested range as the starting point for your own compatibility check, not as a guarantee for your build. The move is usually run by an internal platform team, often with an implementation partner for the storage design, the cutover plan and the runbooks. The internal team carries the knowledge of the applications, their dependencies and their change windows, which no partner can supply. The partner or a specialist team typically carries the heavier technical lifts: cluster and network design, Ceph sizing if you go that way, import testing and documentation. Ask any bidder to split its scope into discovery, pilot, waves and handover so you can see where the effort and the risk sit.
Perpetual ESXi hosts and vCenter keep running after Support and Subscription expires, according to Broadcom's knowledge base, so you do not face an immediate outage at renewal. What lapses is access to new patches and major version upgrades. That gap is the real driver of timing: a host that cannot receive security fixes becomes a compliance finding long before it becomes a technical failure. Set the migration deadline from your patch and audit requirements, and confirm with Broadcom exactly which entitlements your current contract covers. For the migration itself, the risk concentrates in three places: the VMs that cannot be imported directly, the ones that depend on vMotion or HA behavior, and the storage cutover. Inventory those first. Build the wave plan around them, starting with low-impact VMs to validate the import, mapping each application owner to a change window, and keeping rollback options until each wave passes its checks. Confirm current Proxmox VE and Ceph support windows with the vendors before you fix the date.
Which vSphere capabilities map cleanly to Proxmox VE
This table maps the main vSphere capabilities that teams rely on to their nearest Proxmox VE equivalents and labels each as clean, needs rework or gap. Read the status column first, then check the notes on rework items against your own runbooks. DRS-style automatic balancing is not a like-for-like feature in Proxmox VE, so confirm its current behavior against the release notes for your target version before you plan waves.
| Capability | Proxmox VE equivalent | Status and what to check |
|---|---|---|
| vMotion (live migration) | Live migration of running KVM guests between cluster nodes, using shared or replicated storage | Clean for guests on shared storage such as Ceph RBD or NFS. Test with your largest VMs and their network throughput. |
| High availability | HA manager with watchdog-based fencing, needing at least three cluster nodes and shared storage | Needs rework. Plan the node count, quorum, redundant hardware and watchdog configuration before cutover. |
| DRS-style placement | Manual placement or scripted rebalancing; no direct equivalent to automatic DRS balancing | Gap. Not a like-for-like feature. Confirm current automatic load balancing support against the Proxmox VE release notes for your version. |
| vSAN datastores | Ceph RBD for shared block storage, or ZFS storage replication for local disks | Needs rework. Ceph requires dedicated drives, network design and sizing. vSAN-backed disks cannot be imported directly. |
| Distributed virtual switching | Proxmox SDN zones with VLAN and VXLAN-based networking, configured per cluster | Needs rework. Map port groups and teaming policies to bridges and bonds, then validate the SDN model against your network design. |
| Backup and restore | Proxmox Backup Server with scheduled jobs, deduplication and restore from the web interface | Needs rework. Backup jobs must be rebuilt, and retention and restore testing must be repeated on the new platform. |
| vCenter roles and permissions | Proxmox VE user management with roles, groups and permission paths in the cluster | Needs rework. Recreate roles from your current model and confirm that audit and access review evidence meets your policy. |
| Templates and content libraries | VM templates and cloud-init images managed in the cluster web interface and API | Clean for Linux templates. Windows templates and VMware Tools dependencies need separate validation. |
| Management interface and automation | Cluster web interface and REST API, with command-line tools on each node | Clean for day-to-day operations. Rebuild scripts and monitoring integrations that call the vSphere API. |
Where the Proxmox VE import wizard stops
The import wizard added in Proxmox VE 8.2 reads VMs directly from ESXi and vCenter and maps most of their original configuration, but it has documented limits that decide which VMs can move through it unchanged. The ESXi import was tested from ESXi 6.5 to 8.0, so confirm the exact ESXi and vCenter versions in your estate before planning the first wave. Any host running a version outside that tested range should be treated as a pilot candidate, with a test VM imported and booted before the wider schedule is set. Also check which hosts are on which build, since mixed versions in one cluster are common during long-running estates.
Two data-path limits need an inventory decision. VMDK disks on vSAN datastores cannot be imported through the wizard, so every VM backed by vSAN must be identified and handled by another path, such as OVF export, qm disk import for copied VMDK files, or a planned move with the storage plan described for vSAN. Second, VMs with snapshots import more slowly. Consolidate snapshots on each VM before the import, confirm that the consolidation finished cleanly, and remove old snapshot chains that are kept only for convenience, because a long import window on a large disk can push a cutover past its planned slot.
Do not assume that encryption, vTPM state, or other advanced VM features carry over. The wizard maps the common configuration, but encrypted VMs, virtual TPM settings, and device passthrough need to be tested in your own environment with a representative VM from each class. Record what the imported VM looks like in the Proxmox VE web interface, boot it, and check the guest OS, drivers, and network before accepting it. Where a feature does not carry over cleanly, document the workaround and add it to the cutover runbook so the wave owner knows the exception before the change window opens. The Migrate to Proxmox VE wiki page lists the current alternative paths and should be read alongside your own test results.
Which exports and fallbacks move VM data
Proxmox VE documents four routes for getting VM data out of VMware: the built-in ESXi and vCenter import wizard, OVF import, VMDK disk import and Clonezilla. Each path suits different source conditions, so the choice depends on what each VM runs on and how it is stored. Pick the path per VM class before the first wave, not after a failed import.
Built-in ESXi and vCenter import wizard
The import wizard in Proxmox VE 8.2 and later connects directly to ESXi or vCenter and maps most of the original VM configuration to a Proxmox VE guest. Start here for VMs on local or supported network datastores. Check that the source ESXi version falls within the tested range (6.5 to 8.0 per the Proxmox wiki), that no disks sit on vSAN, and that the VMs you plan to import have no snapshots, since those import more slowly. Confirm the import behavior in your own environment with a pilot VM before scheduling bulk moves.
OVF import with qm importovf
Use qm importovf when the VM already exists as an OVF or OVA export, for example from an earlier vSphere export. It creates a new guest from the descriptor and imports the attached disks into the chosen storage. This path is useful when the wizard cannot reach the source host or when a VM must be preserved as an exported package for a fixed period. Keep the exported package checksummed and stored on a controlled share, and verify the imported disk sizes and boot order before powering on.
Disk import with qm disk import
Use qm disk import to attach a VMDK file to an existing Proxmox VE guest when you have the disk but not the full VM definition. This is the usual route for disks copied from a datastore, or for rebuilding a guest where the CPU, memory and network settings are defined by hand. Record the source file, the target storage and the chosen disk controller for each VM, since the VM will not carry VMware-specific settings across. Test that the guest boots with the expected driver stack, particularly for Windows VMs that rely on VMware Tools.
Clonezilla as a fallback
Clonezilla is the documented alternative when the other paths fail, such as for a disk layout that the import tooling cannot handle. It copies disk images block by block, so the guest is rebuilt around the imported image rather than translated from the VMware definition. It suits fixed maintenance windows because the source VM must be offline during the copy. Plan the guest boot changes, driver updates and network configuration as separate steps, and keep the source VM untouched until the restored copy passes its acceptance checks.
Integrations must be rebuilt
Backup jobs, monitoring agents, identity bindings and network definitions do not move with the VM disk. Recreate backup schedules in Proxmox Backup Server or your chosen tool, re-point monitoring and log forwarding, and rebind service accounts and directory integrations to the new platform. Map VMware port groups to Proxmox VE bridges and VLANs before the first wave. Treat these rebuilds as their own checklist with owners and sign-off, because an imported VM that boots but is no longer backed up or monitored is a common post-cutover gap.
How a wave-based cutover runs step by step
This sequence moves vSphere workloads to Proxmox VE in controlled groups, with each stage producing evidence that the next stage depends on, so the ESXi estate can be retired without an unplanned outage.
Build a validated VM inventory
Your infrastructure team lists every VM with its host, datastore, disk types (VMDK, RDM or vSAN-backed), snapshot chains, network port groups, guest OS version and VMware Tools state. Flag any VM whose disks sit on vSAN, since Proxmox documents that vSAN-backed disks cannot be imported, and any VM with snapshots, which imports more slowly. Map application owners and upstream or downstream dependencies to each VM. The output is an inventory signed off by application owners, with each VM tagged for an import path: the built-in import wizard, OVF or qm disk import, or a rebuild.
Run a pilot on non-critical VMs
Stand up a Proxmox VE test cluster on hardware that matches the production design, and import a small set of non-critical Linux and Windows VMs through the import wizard. Verify boot, network connectivity, storage performance, guest drivers and the VM configuration the wizard produced. Record every fallback you needed, such as a manual disk import or a Clonezilla path. The output is a pilot report that lists each VM's outcome and a rollback test showing you can return a VM to its ESXi host within your change window.
Map networks and storage for parallel running
Define how VLANs and port groups on vSphere correspond to Proxmox bridges or SDN zones, and confirm which storage backend holds each workload, whether Ceph, an existing SAN over iSCSI or NFS, or local ZFS. Keep both platforms reachable during the transition so migrated services can talk to services still on ESXi. Validate firewall rules and DNS, and confirm backup targets for both sides. The output is a signed network and storage mapping document plus a test that a migrated VM reaches its dependencies on the old network segment.
Cut over VMs in dependency-grouped waves
Group VMs by dependency rather than by team, so a database, its application tier and its load balancer move together. For each wave, shut down or quiesce the VMs, import the disks, attach them to the mapped networks, start them in dependency order and run application-level checks. Keep the ESXi copy powered off but intact until the wave passes. Because Proxmox has no vMotion equivalent for live moves between hypervisors, schedule each wave with a defined outage window agreed with the business owner. The output is a wave completion record per group with test results and an approval to proceed.
Rebuild HA, backup and placement on Proxmox
Once the first waves run, configure the Proxmox cluster for production. Proxmox high availability needs at least three nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing, so confirm each requirement before you mark a workload as HA-protected. Replace vSphere placement rules with manual placement or the scheduling options your Proxmox version supports, and recreate backup jobs with Proxmox Backup Server or your chosen tool. The output is a tested HA failover result and a restore test for a sample VM from each wave.
Finish the final waves and sign off
Migrate the remaining groups, including the workloads that needed rebuilds or special handling, and remove their dependencies on ESXi-only services. Reconcile the inventory against what runs on Proxmox so that every VM is accounted for, either migrated, retired or deliberately kept on vSphere. Hand operations to the platform team with runbooks for patching and incident response. The output is a reconciled inventory with zero unaccounted VMs and an operations handover signed by the owners of each application.
Decommission ESXi hosts after retention
Keep the ESXi hosts, vCenter and the last copies of VM disks for a retention period that your audit, legal and recovery policies set, then wipe the hosts and remove vCenter. Before shutdown, confirm that any remaining perpetual-licensed hosts are no longer in production and that the data-retention copies can be read on your storage. Record the decommission in your asset register and update the license inventory. The output is a decommission record with the date, the retained backup set location and confirmation that no production service depends on ESXi.
Storage and high availability choices on Proxmox VE
Ceph gives Proxmox VE a distributed, replicated block store across nodes, which is the usual basis for live migration and HA without a separate SAN. It is licensed under LGPL and comes from the project with no paid edition, so the cost sits in hardware, network and the staff who run it. Ceph's hardware guidance asks for a dedicated drive per OSD and, on HDD-based OSDs, the WAL and DB placed on shared SSDs.
- Drive layout: Use one dedicated drive per OSD. On HDD-based OSDs, move the WAL and DB onto shared SSDs as the hardware recommendations describe.
- Metadata media: Put metadata on enterprise-class SSDs, not consumer drives, because metadata latency affects the whole pool.
- Network: Bond links and spread the bond across two switches so one switch failure does not isolate storage.
- Memory: Size RAM for peak recovery load, not idle use, and benchmark on your own hardware before purchase, since no two clusters behave alike.
- Deployment tool: Use cephadm for Proxmox-style clusters. If you later run Kubernetes, the cephadm documentation points to Rook as the Kubernetes-native path.
Before buying, confirm the Ceph release line you will install. Squid's estimated end of life is October 31, 2026 and Tentacle's is June 1, 2027, so a new deployment should normally start on Tentacle to avoid an upgrade within months.
If you already own a SAN, Proxmox VE can attach it over iSCSI or NFS as shared storage for guests. This keeps the array and its replication, snapshots and support contract in place while you change the hypervisor layer. The trade-off is that the array becomes a shared dependency, so its own redundancy decides how resilient the cluster is.
- iSCSI: Works for block storage shared across all nodes. Confirm multipath settings and that every node sees the same LUNs.
- NFS: Simpler to attach and inspect, and it suits VM disks on file-based storage. Check locking and performance behavior with your NAS vendor.
- Array redundancy: Two controllers, redundant paths and redundant power are required for the shared storage to support HA.
- Migration path: Existing VMDK data can be moved onto the SAN-backed storage in waves, using the import wizard or disk import as described in the migration guide.
- Vendor support: Ask the SAN vendor whether its support covers a KVM hypervisor and whether firmware or driver versions need to change.
Before you commit, ask the SAN vendor in writing which Proxmox VE release and kernel combinations it supports and whether the array's snapshots can be used for backup consistency.
Local storage on ZFS or LVM is the simplest option. Each node keeps its VM disks on its own drives, which avoids a shared storage system but means that live migration and HA need a different design. ZFS also supports storage replication between nodes, which fits smaller clusters and some disaster recovery designs, but it does not replace shared storage for automatic recovery of guests.
- ZFS: Gives checksums, snapshots and replication between nodes. Plan RAM for ZFS caching and use a mirror or RAIDZ layout that matches your failure tolerance.
- LVM: Uses less overhead and is familiar to Linux administrators, but offers fewer data integrity features than ZFS.
- Replication limits: Replicated copies lag the source by the replication interval, so recovery point objectives must be set with that lag in mind.
- Backup: Pair local storage with Proxmox Backup Server so restores do not depend on the failed node.
- Scope: Local storage suits workloads that tolerate a short outage and a defined data loss window, not guests that need automatic failover.
Before committing, confirm with your own test cluster the replication interval, restore times and the recovery point you can document for each application owner.
Proxmox VE high availability restarts guests on another node after a node fails, but it only works safely when the cluster meets its prerequisites. The design must provide quorum, shared storage for guests, redundant hardware and a way to fence a failed node. Without fencing, a node that is only partly unreachable can keep writing to the same disks while its guests restart elsewhere.
- Quorum: Run at least three cluster nodes for reliable quorum. Two-node designs need a separate quorum approach and are not a standard HA pattern.
- Shared storage: Guests that must restart elsewhere need storage that every candidate node can reach, such as Ceph, a SAN or NFS.
- Redundant hardware: Use redundant power supplies, network paths and storage paths so that a single component failure does not look like a node failure.
- Watchdog fencing: Watchdog-based fencing resets a failed node before its guests are recovered elsewhere. Confirm that your hardware or virtual watchdog works before relying on it.
- Testing: Pull power on a test node during a pilot wave and time the recovery. Record the result as evidence for the change board.
Before go-live, ask the Proxmox VE documentation and your hardware vendor to confirm the watchdog and quorum behavior for your exact server models.
Running ESXi and Proxmox VE side by side during the move
Keep both platforms live by giving each its own management network from the start. Place the ESXi hosts and vCenter on their existing management VLAN, and place the Proxmox VE cluster on a separate management subnet with its own gateway, DNS and time sources. This keeps a fault or a change on one side from taking the other's control plane down, and it lets you run both sets of tools during the parallel period. Keep the shared storage paths, such as the existing SAN or NFS exports, mapped to both sides only for the datastores that a wave actually moves, and document which LUNs or exports each host can see. Before the first wave, confirm the ESXi and vCenter licence and support status in writing, because the ESXi hosts stay under their current licence until the last wave is validated.
Define rollback criteria per wave before any VM moves. For each wave, write down the conditions that trigger a return to ESXi: failed boot or driver problems in the guest after conversion, network reachability to dependent services, backup job success on the new side, and application owner sign-off on performance. Set a fixed observation window per wave and record who can call the rollback. Keep the source VM powered off but intact on ESXi until that window closes, rather than deleting it at cutover, so the rollback path stays a power-on action. The Proxmox wiki's import notes on snapshots and vSAN-backed disks are the first things to check when a wave fails, and the Migrate to Proxmox VE page is the reference to re-read when that happens.
Plan the subscription and repository posture now, not after go-live. Proxmox VE subscriptions are priced per occupied physical CPU socket per year, so ask the vendor or a reseller to confirm how sockets are counted on your hardware before you size the cluster. All features are included in every tier, and the tiers differ in support entitlement and access to the enterprise repository. The no-subscription repository suits testing and non-production use, while the enterprise repository is recommended for production. Run the pilot and the early waves on the no-subscription repository only in a lab, and switch production nodes to the enterprise repository with a valid key before the first production wave. Confirm the exact support tier and response times in the current pricing page, since they are the figures that will be quoted to you.
What usually goes wrong and how to prevent it
Most failed or delayed moves from vSphere to Proxmox VE trace back to a few predictable gaps: storage that cannot be imported, disks and snapshots that slow the work, guest settings that break after cutover, and an HA design that cannot survive a real node failure. Each card below names one risk, why it matters for this migration, and the check that catches it before a production wave.
vSAN-backed disks found late
Proxmox documents that vSAN-backed disks cannot be imported with the ESXi import wizard. Teams often discover this only when a wave starts, after the schedule is set. Before any wave, inventory every VM's datastore, flag every disk on vSAN, and plan those VMs on a separate path such as a copy to NFS or a shared datastore, or an OVF export followed by qm importovf. Confirm the path with a test VM from each class.
Snapshot chains slowing imports
Proxmox notes that VMs with snapshots import more slowly. Snapshot chains also make the source disk state harder to reason about. Consolidate snapshots on the source VM during a maintenance window, confirm the consolidation finished, and only then start the import. Record the import duration for a sample of VMs so the wave plan uses measured times, not guesses.
Windows licensing and VMware Tools after cutover
Moving hardware identifiers can trigger Windows activation prompts, and VMware Tools must be removed while guest drivers for KVM are installed. Leaving VMware Tools in place can cause services to misbehave. Before each Windows wave, confirm activation method with the license owner, plan the Tools removal and VirtIO driver install in the test clone, and check that the guest network and disk come up as expected.
Network and VLAN mapping errors
The import wizard maps most configuration, but bridge names, VLAN tags and MTU settings on the destination may not match the vSphere port groups. A VM that boots with the wrong VLAN can appear healthy while it is isolated from its dependencies. Document every port group, its VLAN ID and MTU, map each one to a Linux bridge or SDN zone on the Proxmox side, and test reachability from each VM before cutover.
HA without three nodes or watchdog fencing
Proxmox HA needs at least three cluster nodes for reliable quorum, shared storage for guests, and watchdog-based fencing so a failed node is reset before its guests restart elsewhere. Two-node clusters or HA rules without fencing can leave a VM running on two hosts or never recover. Confirm node count, shared storage, and watchdog behavior with a forced power-off test before counting on HA for production workloads.
Skipped rollback tests
Teams often plan the forward cutover in detail and never test the way back. If a migrated VM fails under load, the source VM must still be intact and bootable, with its disks and network unchanged. For each wave, keep the vSphere source powered off but intact until the business owner signs off, rehearse a rollback on one VM, and write down who decides to roll back and how long that decision window lasts.
What drives cost and duration of the migration
This table lists the factors that change what a move from vSphere to Proxmox VE costs and how long it takes, and what each one means for your plan. Read each row against your own estate: the VM inventory, storage design, team skills and the subscription tier you choose will set most of the total. Software licensing is usually the smallest line; the largest ones tend to be storage, labor and cutover risk.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| VM count and disk size | Each VM needs export or import, validation and a rollback plan, and large VMDK files lengthen copy time on every wave. | Inventory VMs by disk size and OS, and move small, low-risk guests first to build a repeatable runbook. |
| vSAN dependence | vSAN-backed disks cannot be imported directly, so each affected VM needs a different path such as OVF export or disk conversion to a Proxmox-visible store. | Count vSAN-backed VMs early; plan a storage target that can hold them before the first wave. |
| Snapshots and encryption state | VMs with snapshots import more slowly, and encrypted VMs need key handling confirmed before data can move, which adds per-VM review time. | Consolidate snapshots and confirm key custody with the security team before scheduling each wave. |
| Storage build: Ceph hardware or existing SAN | Ceph needs dedicated drives per OSD, enterprise SSDs for metadata and bonded network links across two switches, so new hardware carries capital cost. Reusing a SAN lowers hardware spend but depends on the SAN vendor's Proxmox support path. | Ask the storage vendor to confirm Proxmox compatibility in writing, and benchmark Ceph on your hardware before purchase. |
| Staff skills in Linux, Ceph and KVM | Operators who know ESXi and vCenter need training on Linux administration, Ceph health and KVM tuning, and that time is paid in salary or training fees. | Pair experienced Linux staff with vSphere admins during pilot waves and document each runbook as it is proven. |
| Number of waves and change windows | More waves mean more cutover events, more coexistence time with two platforms and more approvals, all recurring across the program. | Group VMs by application dependency and maintenance window, and keep waves few enough that each has a clear owner. |
| Proxmox VE subscription tier and response times | Per-socket subscriptions are paid per year: Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros (Proxmox VE pricing page). Higher tiers add support tickets and faster response, and all tiers include the same features. | Match the tier to production criticality and the support hours you need; test in the no-subscription repository is possible, but production should use the enterprise repository. |
| One-time versus recurring costs | One-time costs include migration labor, hardware, training and pilot work. Recurring costs include subscriptions, support, storage maintenance, backup capacity and staff time for patching. | Ask each quote to split one-time and annual figures, and to state which items repeat each renewal year. |
How the move differs by estate size and starting point
A small estate usually has a few ESXi hosts, a shared SAN presented over iSCSI or Fibre Channel, and a vCenter that manages everything from one place. The main constraint here is storage continuity: Proxmox VE can attach iSCSI and NFS storage, but you must confirm how your SAN volumes will be presented to the Proxmox hosts and whether your array vendor supports the target configuration. Because the cluster is small, the import wizard often covers most of the work, and the real effort goes into networking, backup jobs and verifying guest tools after each conversion.
- Storage presentation: Confirm that each SAN LUN can be mapped to every Proxmox node that must see it, and plan a test LUN before moving production disks.
- Import path: Use the integrated import wizard for the bulk of VMs, and keep OVF or disk import as the fallback for guests that do not import cleanly.
- Networking: Recreate port groups as Linux bridges or VLAN-aware bridges and map each VM's network before the first wave.
- Backup jobs: Rebuild backup schedules on the new platform, because vCenter backup jobs do not carry over.
- Cluster size: A few hosts may not meet the three-node minimum for reliable high availability, so decide early whether you need it.
Ask your storage vendor and your Proxmox support partner to confirm the SAN and multipath details in writing before you schedule the first wave.
A larger estate typically needs more than a like-for-like move. It usually has many hosts, several clusters, and a requirement for high availability that survives a node failure without manual intervention. The main constraint is the design of the storage layer and the cluster itself: Ceph gives you distributed storage across nodes, but it needs its own sizing, networking and operations discipline, and high availability needs at least three nodes, shared storage for guests, and watchdog-based fencing. Plan the storage and HA design before any VM moves, because changing them later means moving data again.
- Three-node minimum: Build the HA cluster with at least three nodes, redundant hardware and a watchdog so failed nodes are fenced before guests restart elsewhere.
- Ceph layout: Size OSDs, network links and memory for peak use, and benchmark your hardware before you buy, as the Ceph hardware guidance recommends.
- Live migration equivalent: Test how your teams replace vMotion-style moves, including planned host evacuations, and document the runbook.
- Placement rules: Map DRS-style placement needs to Proxmox HA groups and resource settings, and confirm which workloads need anti-affinity.
- Wave planning: Group VMs by application and dependency, then move non-critical waves first to validate the HA design.
See the Ceph and HA sections above before finalizing the design, and confirm the Ceph release you will run and its support window with your own change plan.
Some teams cannot move everything at once. If workloads sit on vSAN datastores, the import wizard cannot read those disks, so the migration has to bridge the gap. The main constraint is continuity: vSAN-backed VMs must keep running on vSphere until a replacement storage layer is ready, and the old and new platforms will coexist for some time. Treat the vSAN exit as its own project, with a timeline that finishes before your vSphere support obligations end.
- Inventory first: List every VM and disk that sits on vSAN, along with snapshots, because snapshotted VMs import more slowly.
- Stage the storage: Build the destination storage, such as Ceph, before moving vSAN-backed guests, so the copy does not happen twice.
- Use the fallback paths: Plan OVF export, qm disk import for VMDK files, or Clonezilla for VMs that cannot be imported directly from vSAN.
- Run both platforms: Keep vCenter and Proxmox management separate during the overlap and set rules for which system owns each VM.
- Support window: Confirm with Broadcom the support status of your current hosts and vCenter, because patch and upgrade access depends on an active contract.
Before committing a date, confirm with your storage and virtualization owners which vSAN disks can be moved live and which need a planned outage.
Questions buyers ask before moving from vSphere to Proxmox VE
What drives the total cost of moving from vSphere to Proxmox VE?
The main drivers are the labor to plan and execute the move, the hardware and storage you need for the target cluster, backup tooling, and the staff time to run the new platform. On the Proxmox side, the software is free to use, and the optional subscription is priced per occupied physical CPU socket per year, with tiers from 120 euros (Community, no support tickets) to 1,100 euros (Premium, unlimited tickets and a 2-hour response), according to the Proxmox VE pricing page. All tiers include the same features, so the choice is about support entitlement and access to the enterprise repository. On the VMware side, the cost you are comparing against is the subscription you would renew, so ask for a written per-core quote from Broadcom or your reseller. Ask any implementation partner for a fixed-scope quote built from your inventory, not a standard rate.
How long does a vSphere to Proxmox VE migration take?
The duration depends on the number of VMs, their disk sizes, how many run snapshots, whether any sit on vSAN, and how many change windows your business allows. Proxmox documents that VMs with snapshots import more slowly and that vSAN-backed disks cannot be imported through the wizard, so those VMs add time and need a different path. Storage design also matters: if you build Ceph on new hardware, the hardware and benchmarking phase can take longer than the VM moves themselves. Plan in waves, starting with low-risk test systems, and ask any partner to tie the timeline to a written inventory and a test-cluster result rather than to a generic estimate.
Can our internal team migrate to Proxmox VE without outside help?
Many teams can run a small migration with existing Linux and virtualization skills, provided they have time to learn the Proxmox cluster, storage and high availability model before production work starts. The harder parts are usually the ones outside the wizard: mapping networks, rebuilding backup jobs, validating application behavior after import, and designing shared storage. Be honest about your capacity during the migration window, because operations teams often carry both the old and new platforms at once. If skills or time are short, a fixed-scope engagement can cover planning, implementation, hardening and documentation while your staff keep ownership of the result.
What does the migration need from our team before work starts?
You will need an accurate inventory of VMs, their operating systems, disks, snapshots, network segments and dependencies, plus a list of which VMs have vSAN-backed disks. Test hardware is important: a small Proxmox cluster that mirrors your production network and storage lets you rehearse imports, check guest drivers and time the cutover before touching live systems. You will also need agreed change windows for each wave, named owners for each application, and a rollback plan. For high availability, Proxmox needs at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing, so confirm those are in the budget before you schedule production waves.
Can perpetual ESXi hosts keep running after our support ends?
Broadcom's knowledge base states that ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, but downloads of new patches and major version upgrades require an active support contract. That means the hosts keep working, while your patching and security exposure grows over time. Use that period to run the migration in waves rather than as a single cutover. Confirm the current terms for your specific licenses and contracts with Broadcom or your reseller, since the rules depend on your agreement and version.
Does Proxmox VE offer vMotion-style live migration and DRS-style placement?
Proxmox VE is a cluster platform that supports moving running guests between nodes when shared storage is in place, and its high availability stack restarts guests on surviving nodes after a failure. Those features are not a one-to-one match for vMotion and DRS, though, and automated load balancing placement works differently. Check the current Proxmox documentation for live migration requirements, CPU compatibility and network needs, and test them with your own workloads. Plan placement rules and maintenance procedures explicitly, because you will not get the same automatic behavior by default.
What should we check about storage before moving VMs off vSAN?
Start by listing which VMs use vSAN-backed disks, since the Proxmox import wizard cannot import them directly. Decide where the data will live next. Options include Ceph built on new hardware, existing SAN storage over iSCSI or NFS, or local ZFS for some workloads. For Ceph, the hardware recommendations call for a dedicated drive per OSD, enterprise-class SSDs for metadata, and bonded network links across two switches, and they advise sizing memory for peak use and benchmarking before buying. Confirm the storage design with your own benchmarks and failure tests before the first production wave.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from VMware vSphere to Proxmox VE, we start with a written scope that inventories your hosts, VMs and storage, then run the migration in agreed waves with rollback points.
How we scope
- Inventory ESXi hosts, vCenter objects, VM disks and any vSAN-backed storage that the import wizard cannot read
- Map networks, VLANs, storage datastores and backup jobs to Proxmox VE bridges, storage pools and backup targets
- Agree in writing which VM groups move in each wave, with cutover windows and rollback criteria
How we build
- Stand up the Proxmox VE cluster, quorum nodes and storage, including Ceph or an existing SAN where the scope includes it
- Test the import wizard on representative VMs, then document the OVF or qm disk import fallbacks for VMs that fail
- Configure high availability, fencing and backups, and record each configuration decision for your change records
How we hand over
- Deliver a runbook for each wave covering shutdown order, guest checks, network validation and rollback steps
- Provide documentation of the cluster design, storage layout, access roles and backup restore procedures
- Walk your operations team through day-to-day tasks so they can run the platform after the engagement ends
How we support
- Support after handover is available as a retainer covering patching, upgrades and incident response
- Continuous security testing of the Proxmox VE management interface and exposed services can be added to a retainer
- Confirm with Proxmox Server Solutions which subscription tier your support model requires before production cutover
