How to export your data from VMware vSphere

How to export your data from VMware vSphere before the contract ends

If your vSphere renewal is moving to Broadcom's per-core subscriptions and you need to know what can leave the platform, start with the virtual machine itself. Since vSphere 6.5, the vSphere Client no longer exports a VM directly as a single OVA file. Instead, you export it as an OVF template from the right-click menu, and Broadcom Knowledge Base article 373304 describes using the OVF Tool command-line utility to convert the exported OVF files into one OVA file. That covers VM disks and their virtual hardware configuration. It does not cover vSphere-side records such as vSAN objects, vCenter roles and permissions, or distributed switch settings, so inventory those separately and plan how each will be rebuilt on the target platform.

Exporting is one path, not the only one. Proxmox VE 8.2 added an import wizard that reads VMs directly from ESXi and vCenter and maps most of the original configuration, and Proxmox documents OVF import (qm importovf), qm disk import for VMDK files and Clonezilla as fallbacks. XCP-ng users can use the V2V tool in Xen Orchestra, which warm-migrates VMs from ESXi 7 and later. Before choosing, confirm your ESXi and vCenter versions against each tool's supported list, and check whether any VMs sit on vSAN-backed disks, which Proxmox documents cannot be imported directly. Keep a copy of exported OVA files on storage you control, because they become your fallback if a direct import fails partway through a wave.

Which vSphere data can be exported and by what method

This table lists each category of vSphere data, the export or import method that handles it, the format produced, and the limits documented for that path. Read each row against your own estate: the limits determine which VMs need a different route, such as a rebuild or an extra conversion step. Confirm version support with your target platform before you schedule any wave.

Data type	Export method	Format	Limits
VM disks and configuration	OVF template export from the vSphere Client, right-click menu	OVF template with VMDK disk files	Since vSphere 6.5 the client no longer exports a VM directly as a single OVA file
Single-file VM package	OVF Tool command-line utility converts the exported OVF into one OVA	Single OVA file	Requires OVF Tool on an administration host; the OVF Tool route applies from vSphere 6.5 onward
VM disks for Proxmox VE	Integrated import wizard reads VMs directly from ESXi or vCenter	Proxmox VE VM configuration with imported disks	Tested from ESXi 6.5 to 8.0; vSAN-backed disks cannot be imported directly; VMs with snapshots import more slowly
VM disks for Proxmox VE (fallback)	qm disk import for VMDK files, or OVF import with qm importovf	VMDK or OVF files on the Proxmox host	Use when the wizard does not fit; confirm the disk format and VM settings after each import
VM disks for XCP-ng	Xen Orchestra V2V warm migration over the ESXi API	Disks written to the XCP-ng storage repository	Requires ESXi 7 or later; ESXi 6.x is not supported by current Xen Orchestra versions for V2V
VMs on vSAN datastores	Direct import is not possible for vSAN-backed disks; export or copy through another path	Depends on the chosen path	Confirm the route with the target platform before planning; vSAN disks need an alternate copy step
Snapshots and running VMs	Remove or consolidate snapshots before export, then shut down or use warm migration where supported	Depends on the chosen path	Snapshot-heavy VMs take longer to import; confirm the handling of running VMs for each target platform

What does not export cleanly and how to work around it

An OVF or OVA export moves virtual disks and basic VM settings, but it does not carry everything that makes a vSphere estate work. The cards below cover the items that need a separate decision, a rebuild or a confirmation with the target platform before the first wave starts.

vSAN-backed disks

Proxmox VE documents that vSAN-backed disks cannot be imported through its ESXi import wizard, so VMs on vSAN need a different path. Plan to export or copy those disks through a supported route, such as OVF import or disk import from VMDK files, and test one VM end to end. Confirm with the target platform which disk formats and export methods it accepts for vSAN datastores before you schedule the wave.

vCenter inventory, roles and alarms

Folders, tags, custom attributes, roles, permissions and alarm definitions live in vCenter and are not part of a VM export. Record them from the vSphere Client or your own configuration records before the cutover, then recreate the equivalent access model and monitoring rules on the target. Treat this as a documented rebuild, since the target uses its own permission model.

Distributed switch and NSX configuration

Exported VMs keep their virtual NIC definitions, but the distributed switch, port groups, VLAN mappings and any NSX segments, firewall rules or routing do not travel with the disk. Document each port group and its VLAN, then map it to a bridge, VLAN or SDN zone on the target. Check that every network name in the import mapping points to a real destination before you power on a migrated VM.

Encryption and key management

Encrypted VMs depend on the key provider in your vCenter, so an exported disk may not be readable on the target without the matching keys. Inventory which VMs use VM encryption, where their keys are held and whether the key provider can be reached after the source is retired. Ask the target platform to confirm which encrypted formats it can import before you plan the export order.

Perpetual licenses and support entitlements

Perpetual license keys and Support and Subscription entitlements are not portable and cannot be exported as data. Broadcom's knowledge base states that perpetual ESXi hosts and vCenter keep running after SnS expires, but patch downloads and major version upgrades require an active support contract. Keep the source running during the export window only as long as you can still apply the security patches it needs.

The export sequence and how to verify each VM

This sequence turns each vSphere virtual machine into a checksummed OVF or OVA package that you have proven can be imported on the target. Each step ends with a check, so no VM leaves the source estate without a verified copy.

Inventory every VM and its disks
Export a list of every VM in the estate with its guest OS, virtual disk count, disk sizes, datastore locations, attached networks and any snapshots. Your virtualization or platform team owns this list, and it becomes the wave plan for the migration. The step is complete when every VM has a row in the inventory and someone other than the author has reviewed it against vCenter.
Confirm which disks sit on vSAN
Check the datastore of each virtual disk and mark any VM whose disks are on vSAN. Proxmox documents that vSAN-backed disks cannot be imported with its ESXi import path, so these VMs need a different route, such as a file copy through an alternative export method or a planned rebuild. The output is a separate list of vSAN-backed VMs with an owner and a chosen route for each.
Remove or consolidate snapshots
Delete or consolidate snapshots on every VM you plan to export, after confirming with the application owner that the current state is the one to keep. VMs with snapshots import more slowly on the Proxmox path, and an unconsolidated snapshot chain makes the disk files harder to reason about. The check is that each VM shows no snapshots in the vSphere Client and that its disk count matches the inventory.
Export each VM as an OVF template
In the vSphere Client, right-click the powered-off VM and choose the OVF template export option, then write the output to a dedicated export volume. Since vSphere 6.5 the client no longer exports a VM directly as a single OVA file, so this OVF template is the first artifact. The step is complete when the export folder contains the OVF descriptor, the manifest and one or more VMDK files for every disk listed in the inventory.
Convert to a single OVA where needed
Where a target or a transfer process expects one file, use the OVF Tool command-line utility to convert the exported OVF into a single OVA package, as described in Broadcom Knowledge Base article 373304. Run this on a host with the tool installed and keep the original OVF folder until the import is verified. The output is one OVA per VM, and the step is complete when each OVA opens and lists the same disk count as the source.
Store exports on checksummed storage
Move the packages to storage that you control, such as an NFS share or object store in your own data center, and generate a checksum for every OVF, OVA and VMDK file. Record the checksums, file sizes and VM names in a manifest file kept alongside the packages and in your change records. The check is a second checksum run after the copy that matches the manifest for every file, with any mismatch re-exported before the source VM is retired.
Re-import a test copy on the target
Import one package per wave onto the target platform, such as Proxmox VE or XCP-ng, as a test copy with a different name and an isolated network. Confirm the disk count and sizes match the manifest, network mapping points to the intended bridges or VLANs, and the guest boots. For Windows guests, check that VMware Tools is removed or disabled and that the network and storage drivers for the new hypervisor load. Record the result for each VM and do not cut over any VM that has not passed this test.

When direct import into Proxmox VE or XCP-ng replaces exporting

Direct import replaces exporting whenever the source and destination support it, because it skips the intermediate OVF or OVA copy and the second transfer that follows. Proxmox VE 8.2 added an integrated import wizard that reads VMs straight from ESXi and vCenter and maps most of the original configuration. Proxmox documents that this path was tested from ESXi 6.5 to 8.0, so confirm your source version against that range before you plan a wave. On the XCP-ng side, Xen Orchestra's V2V tool performs a warm migration: it replicates data while the source VM keeps running, then syncs changed blocks after shutdown. It reads disks from VMFS, NFS or vSAN datastores and needs HTTP access to the ESXi API. The XCP-ng documentation states that ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V.

Direct import has limits that decide the path for each VM. Proxmox documents that vSAN-backed disks cannot be imported and that VMs with snapshots import more slowly, so consolidate snapshots and confirm storage placement in the inventory before the cutover window. Check each VM's disk backing, snapshot chain and guest operating system during the pilot, and record which VMs fail. Those VMs stay on the export path. Keep the OVF or OVA export as the fallback, and for Proxmox VE use the documented alternatives: qm importovf for OVF import, and qm disk import for VMDK files that you have already copied to the cluster. Proxmox also lists Clonezilla as an alternative for specific cases. Test each fallback on a non-production VM before you rely on it.

Your planning step is an inventory sort, not a tool choice. Split VMs into three groups: those the wizard or V2V can read directly, those that need snapshot cleanup or a storage move first, and those that need an exported file because the source or destination cannot read them. Ask your migration partner or vendor to confirm the supported source versions, snapshot limits and vSAN behavior in writing for your exact builds, since the documented limits can change between releases. Keep exports available until each group has passed a boot test and a data check on the new platform.

Export or direct import, depending on the target platform

Proxmox VE 8.2 added an integrated import wizard that reads VMs directly from ESXi and vCenter and maps most of the original configuration, so for many VMs no intermediate file is needed. Proxmox documents that the ESXi import was tested from ESXi 6.5 to 8.0, which is the version range to confirm against your hosts before you start. The import route has limits that shape the plan: vSAN-backed disks cannot be imported, and VMs with snapshots import more slowly. Proxmox also lists alternative paths for cases the wizard does not cover, including OVF import with qm importovf, disk import of VMDK files with qm disk import, and Clonezilla.

Import wizard: Connects to ESXi or vCenter and maps network, disk and basic hardware settings to a new Proxmox VM.
Tested source range: ESXi 6.5 to 8.0 according to Proxmox's documented testing, so confirm your build against it.
vSAN exclusion: Disks on vSAN datastores cannot be imported, so plan a copy to a supported datastore first.
Snapshot cost: Consolidate snapshots before the import, because VMs with snapshots take longer.
Fallback path: Keep an OVA or OVF copy when a VM uses features the wizard does not map, then import it with qm importovf or convert disks with qm disk import.

Before the first wave, check the Proxmox migration guide against your ESXi build and confirm the storage type of every disk.

Questions buyers ask before exporting vSphere data

How much effort does a full vSphere export take?

The effort depends mainly on how many VMs you have, how large their disks are, and how many carry snapshots. Each VM must be exported as an OVF template from the vSphere Client or exported through the vSphere tooling, and then the files must be copied to a location your destination can read. Large disks and slow links stretch the copy time, and VMs with snapshots take longer to import into Proxmox VE according to the Proxmox documentation. Ask any partner to estimate effort from a VM inventory that lists disk sizes, snapshot counts, operating systems and network paths, rather than from the VM count alone.

What storage do we need for exported VMs?

You need free capacity for the exported files plus the copies on the destination, so the working space is at least the size of the VM disks you export at any one time. Exports written to a single OVA file also need room for the intermediate OVF files while the OVF Tool converts them, as described in Broadcom Knowledge Base article 373304. Plan staging space on a share that both vSphere and your migration host can reach, and confirm its throughput, because network speed drives how long each export runs.

Can our own team export the VMs without outside help?

Yes, a team with vSphere administration skills can perform OVF exports and OVA packaging using the vSphere Client and the OVF Tool, provided it has the right permissions. The harder work is inventorying dependencies, checking guest operating systems, testing restores on the destination and documenting the results. Teams with a small number of VMs and a clear test plan often handle this internally. Teams with many VMs, encrypted disks, vSAN-backed storage or tight downtime windows often ask for outside planning support, which DeployOpen provides under a written, fixed scope.

Do we need a Broadcom support contract to export VMs?

Exporting VMs with the vSphere Client and the OVF Tool does not depend on an active support contract according to the documentation for these steps, but the vendor's terms change what you can do with the environment afterwards. Broadcom's knowledge base states that ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, while downloads of new patches and major version upgrades require an active support contract. Confirm your entitlement status with Broadcom and your licensing terms before you plan the export window.

How do we handle VMs that cannot be imported directly?

Some VMs fall outside the direct import path, for example those on vSAN-backed disks, which Proxmox documents as not importable through its wizard. For these, use the documented fallbacks: OVF import with qm importovf, qm disk import for VMDK files, or Clonezilla for disk-level copies. Each fallback needs its own test, including boot checks, driver changes and network mapping. Classify your VMs before the first wave so that exceptions are known early, and record the method chosen for each one in the runbook.

Should we export all VMs or import them directly into the target?

Direct import replaces the export step for supported VMs. Proxmox VE 8.2 added an import wizard that connects to ESXi and vCenter and maps most of the original configuration, and Xen Orchestra's V2V tool warm-migrates VMs from ESXi 7 and later. Keep a full OVF or OVA export as a fallback for VMs that these paths reject, for archival copies, or for other destinations. Test the direct path on one non-critical VM before you rely on it for a wave.

What should we ask for in a written scope before exporting?

Ask for a written scope that lists the VMs in each wave, the export method per VM, the staging storage and its capacity, the network path and bandwidth between the source and destination, the access you need on vSphere and the destination, the downtime windows, the test and rollback steps, and the evidence you will receive, such as checksums and restore test results. Ask who is responsible for each item, what is excluded, and how changes are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote that follows from that scope.

What to plan before the vSphere contract renews or ends

Exporting VMs is the mechanical part of leaving vSphere. The decisions that make it go well are made earlier: which subscription you hold, when support lapses, and what you need to keep running while data moves. The cards below cover those decisions in the order most teams reach them.

Confirm your subscription type

Broadcom sells vSphere now only inside VMware vSphere Foundation (VVF) or VMware Cloud Foundation (VCF), priced per core. Check the order form or the Broadcom portal to see which product, edition and core count you hold, and whether your renewal already moved you to a subscription. Those terms set what you can keep running and what a renewal will cost, so record them before you export anything.

Record each host's support end date

Support and Subscription (SnS) dates often differ between hosts, clusters and vCenter instances, and they drive your patch and upgrade plan. Build a table with each ESXi host, vCenter, vSAN and NSX entitlement, its end date and its owner. Ask Broadcom or your reseller to confirm the dates in writing, since the export schedule should finish before the first lapse.

Export a test VM early

Pick one non-critical Linux VM and one Windows VM, then export both as OVF templates and convert them with OVF Tool into single OVA files. Import them into your target platform and boot them. Problems with disk formats, network names, UEFI firmware or VMware Tools usually appear in this first run, so the test shows you what the remaining waves will need.

Plan for patch access

Perpetual licenses keep ESXi hosts and vCenter running after SnS expires, but new patches and major version upgrades need an active support contract. Note which hosts will run unpatched during the migration window, and decide whether that exposure is acceptable for each one. Keep your exports and target builds current so that a security fix on the source does not block the schedule.

Keep licensed backups and VM records

Exports capture disks and virtual hardware, but not everything a VM depends on. Keep a backup of each VM taken before the export, and save the settings that the export does not carry: network port group names, VM tags, storage policies, resource pools, snapshot history and backup job definitions. Store this record with the exported files, so you can rebuild a VM if an import fails or a licensed backup product is no longer renewed.

Order the cutover by criticality

Move low-risk test and development VMs first, then internal services, and move business-critical systems last. Keep the source VM powered off but intact until the target copy has passed functional tests and a restore test. Define a rollback path for each wave, such as keeping the vSphere copy as a cold standby, and agree the decision point with the application owners before the wave starts.

How to verify an export is complete and usable

An exported OVF or OVA set is only useful if you can prove it is complete and that it boots somewhere else. Treat verification as a separate step with its own record, not as a side effect of the export. Start by generating a checksum for every OVF descriptor, every VMDK disk and every OVA file as soon as it is written, and store the checksum list next to the export, not on the same volume as the only copy. Recompute the checksums after any copy, transfer to a backup target or move into the destination storage. A mismatch means the file must be exported again, not repaired by hand.

A checksum proves the bytes did not change, but not that the VM works. Restore or import the export onto a non-production target, such as a spare Proxmox VE node or an XCP-ng test pool, using the same path you plan to use in production. Then check the guest itself: it boots, the operating system reaches its login or service state, the application answers its health check, and the disk layout and attached devices match the source inventory. Review network and storage mapping before the first power-on, because a VM that boots onto the wrong VLAN or datastore can look healthy while being unreachable or writing to the wrong place. Confirm the import tool's version and supported ESXi version against the vendor documentation, since limits such as unsupported vSAN-backed disks or older ESXi releases change the result. The Proxmox wiki on migrating to Proxmox VE lists the import limits to check against your estate.

Keep a written record for each VM: source host and vSphere version, export method, file names and checksums, test target, boot and application results, mapping decisions and the person who approved the cutover. This record serves two purposes. It is the rollback reference if a migrated VM fails, and it is evidence that supports compliance readiness work, such as showing that change and backup controls were followed. DeployOpen can help define the checklist, run the restore tests and organize the evidence. It does not issue audit reports or attestations; the independent auditor or certification body you engage decides whether your controls meet the applicable framework, so confirm with them early which records they will expect.

How DeployOpen scopes and delivers a vSphere data exit

DeployOpen plans and implements the export of vSphere virtual machines inside your own infrastructure, from inventory and format choices through to verified copies on your storage. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory of VMs, disks, snapshots, encryption and vSAN-backed storage that affects the export path
Choice between OVF templates, single OVA packaging with OVF Tool, or direct import into the target platform
Written list of deliverables, target storage locations, verification steps and the handover documents

How we build

Export runbooks and OVF Tool scripts configured for your vCenter and ESXi versions
Test exports of representative Linux and Windows VMs, with checksums and restore checks on the destination
Secure transfer paths and storage layout inside your data center or cloud accounts, with access limited to your team

How we hand over

Documented export procedure, including the commands, parameters and known limits used for each VM class
Export logs, checksum records and a per-VM register showing what was copied, when and whether it verified
Walkthrough with your operations team so the export can be repeated or audited without DeployOpen present

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the written scope closes
Support can cover re-running exports for late changes, new VMs or failed transfers listed in the register
Ask in the quote which items are included in fixed scope and which would be billed as retainer work

How to export your data from VMware vSphere