VMware Migration: The 2026 Multi-Hypervisor Playbook

Leaving VMware is two projects, not one. The migration project is bounded — it has a start date, an end date, and a finite scope of workloads. The protection project is unbounded — it starts before the migration, runs through it, and continues for as long as the new platform exists. Most content on this topic treats those two projects as the same thing. They aren’t.

This page is built for the second conversation — the one after you have decided to leave VMware, where you are picking between OpenStack, Proxmox, Nutanix AHV, OpenShift Virtualization, Hyper-V, and KVM, and you want a plan that addresses both projects honestly.

What this playbook covers

• Why VMware migration is on every IT roadmap in 2026
• The two phases of a VMware exit
• The four real questions to answer before you migrate
• Choosing your target platform — six options compared
• The migration step — what Storware does, what you do with platform-native tools
• The protection step — Storware across the post-VMware landscape
• European data sovereignty: GDPR, NIS2, DORA, CLOUD Act
• Step-by-step VMware to OpenStack migration workflow
• FAQ

Why VMware migration is on every IT roadmap in 2026

This is well-documented territory, so we’ll keep the framing tight. Three forces are driving the wave:

Subscription-only licensing. Broadcom eliminated perpetual VMware licensing in early 2024. All new purchases and renewals are subscription-based on one-, three-, or five-year terms. The product catalogue collapsed from over 160 SKUs to four primary bundles — VMware Cloud Foundation (VCF), vSphere Foundation (VVF), vSphere Standard, and vSphere Enterprise Plus.

The 72-core minimum. Effective April 10, 2025, Broadcom raised the minimum licence purchase to 72 cores per product or order line, up from 16. For organisations running smaller servers, edge sites, or compact deployments, this means paying for capacity that does not physically exist. Reported price increases range from 150–1,500% depending on the customer profile, with the worst impact on mid-market shops previously running vSphere Essentials Plus (now discontinued).

Renewal-cycle pressure. Gartner has indicated that Broadcom could lose more than one-third of VMware customers and workloads to alternative platforms within three years. Many of those decisions are happening against fixed renewal dates — meaning teams must execute migration plans within a defined window or commit to another subscription term.

The result: VMware migration is no longer a five-year strategic conversation. It’s a 12-to-24-month execution conversation, and the question has shifted from whether to where and how.

The two phases of a VMware exit

The most common framing error in VMware migration content — including most vendor content — is treating the migration as the whole project. It isn’t. The migration is the first phase. The protection layer that runs alongside the new platform is the second, and it lasts longer.

Phase 1: The migration

Bounded. Defined scope. Finite duration. Workloads move from VMware to a chosen target platform. The mechanics involve disk format conversion, driver injection, network re-mapping, and validation. Tools used in this phase include platform-native importers (Proxmox’s built-in importer, Nutanix Move, Hyper-V’s migration utilities), open-source command-line tools (virt-v2v, qemu-img), and vendor-specific products. The output is a fully-functioning target environment.

What Storware does in this phase: Storware Backup and Recovery includes a built-in V2V capability that uses your existing VMware backups as the migration source specifically for VMware-to-OpenStack migrations. This is the path where Storware delivers end-to-end. For other target platforms, customers use platform-native tooling — and we’ll explain when that’s the right choice further down.

Phase 2: The protection layer

Unbounded. The protection project starts before the migration (because you’re backing up VMware today), runs through the migration window (because gaps in coverage during a project window are unacceptable), and continues for as long as the new platform exists. Whatever you migrate to needs enterprise-grade backup, ransomware protection, disaster recovery, and — increasingly — sovereignty-aligned data handling.

What Storware does in this phase: Storware Backup and Recovery protects 15+ virtualization platforms under a single universal licence. The supported targets cover every realistic post-VMware destination: Proxmox VE, Nutanix AHV, OpenShift Virtualization, Microsoft Hyper-V, KVM (Oracle Linux KVM, Red Hat ecosystem), OpenStack (Red Hat OpenStack Platform, Canonical, Virtuozzo Hybrid Infrastructure, OpenMetal, Platform9), and a long tail including VergeOS, XCP-ng, Citrix Hypervisor, Scale Computing, and others.

This is the structurally important point: the platform you choose to protect the new environment will be in your stack longer than the migration tools you choose to get there. Decide phase two first; let it inform phase one.

The four real questions to answer before you migrate

Migration content tends to over-index on how — vMotion mechanics, VMDK conversion, command-line tooling. Those questions matter, but they’re downstream. Before any of that, four upstream questions decide the shape of the project.

Question 1: What is the workload profile?

Stateless web tiers, legacy Windows monoliths, latency-sensitive transactional databases, and HPC clusters all want different target platforms. A migration plan that treats all VMs as equivalent will either over-engineer the simple workloads or underprovision the difficult ones.

Inventory your VMs in three buckets: lift-and-shift candidates (most general-purpose Linux and Windows VMs), refactor candidates (applications close to end-of-life that could be containerised during the move), and special-handling cases (anything with hardware passthrough, vGPU, NSX-specific networking, or vSAN-only storage features).

Question 2: What does the operations team already know?

The cheapest target platform on paper is rarely the cheapest after factoring in re-skilling, hiring, and the productivity cost of a steep learning curve. A VMware administrator can be productive on Hyper-V in weeks and on Proxmox in months; OpenStack and OpenShift Virtualization are typically a year-plus investment unless you bring in external expertise.

Question 3: What are the compliance and sovereignty constraints?

For European organisations, GDPR is the floor. NIS2 (effective October 2024) raises the bar for incident reporting and supply-chain security. DORA (effective January 2025) imposes specific operational resilience requirements on financial services. The CLOUD Act creates a documented conflict between US-headquartered vendors and EU data-residency obligations.

None of this is hypothetical. It changes which target platforms are viable and which data protection vendor you can credibly run alongside them.

Question 4: What is the renewal timeline?

The 20% late-renewal penalty Broadcom applied in 2025 means that customers who miss their renewal anniversary face a worse position than either renewing or completing migration before the date. Your migration timeline is dictated by your renewal date, not by your project plan.

Choosing your target platform

Six target platforms cover the realistic options for most VMware customers. Each has a different fit profile. The table below shows operational complexity, licence cost, the migration tooling typically used, and Storware’s scope for each — both phases of the exit, separately.

Six target platforms for VMware migration. The “Storware V2V” column shows where Storware delivers the migration end-to-end (OpenStack only). The “Storware backup & recovery” column shows where Storware protects the target environment in steady state — every platform on the list.

A word on what isn’t on this list. VMware Cloud on AWS, Azure VMware Solution, and Google Cloud VMware Engine are not migration targets — they’re re-host strategies that keep you on VMware. They can be useful tactical moves but don’t solve the underlying licensing question.

The migration step — what Storware does, what you do with platform-native tools

Storware does one migration path end-to-end: VMware to OpenStack and OpenStack-based platforms. For every other target, the right approach is to use platform-native tooling. Here’s the practical breakdown.

VMware to OpenStack: backup-as-migration

This is the path where Storware’s architecture matters most. Storware Backup and Recovery 7.1 introduced cross-hypervisor restoration as a first-class feature: backups taken from VMware can be restored directly to an OpenStack target. The mechanics:

• Connect VMware vCenter as a Virtualization Provider in the Storware WebUI. Agentless via the vCenter API.
• Run normal Storware backups against your VMware estate — deduplicated, AES-encrypted, optionally air-gapped via IsoLayer, optionally WORM-immutable.
• Connect the target OpenStack instance (RHOSP, Canonical, VHI, OpenMetal, Platform9, community) as a Virtualization Provider via Keystone.
• Restore VMs from the backup catalogue to the OpenStack target. Storware handles disk format conversion, driver injection, and instance creation transparently. This is the migration step — mechanically identical to a normal restore.
• Validate, repeat, decommission. Original VMware VMs and their backups remain available throughout. Rollback is a restore back to VMware.

The architectural advantage: one platform, one licence, no separate migration tool. The backup is the migration source. Coverage is uninterrupted before, during, and after the move.

VMware to Proxmox VE: Proxmox’s built-in importer

Proxmox VE includes a native VMware ESXi import facility. Connect to vCenter, select source VMs, choose target storage and network, run the import. The tool handles format conversion (VMDK to qcow2 or raw). Suitable for most lift-and-shift workloads. After migration, Storware Backup and Recovery protects the Proxmox environment with the same universal licence that protected VMware before the move.

VMware to Nutanix AHV: Nutanix Move

Nutanix Move is the vendor-supplied migration tool, free for Nutanix customers. It performs warm migration with Changed Block Tracking, supports cutover scheduling, and integrates with Prism. Storware protects the AHV environment after migration via the Prism Element API — agentless, application-consistent where required.

VMware to OpenShift Virtualization: Red Hat MTV

Red Hat’s Migration Toolkit for Virtualization (MTV) is built into the OpenShift Virtualization platform. It uses virt-v2v under the hood and orchestrates batched migrations from vCenter to OpenShift Virtualization. Storware protects OpenShift Virtualization after migration — note this is the virtualization extension to OpenShift, distinct from OpenShift Containers, and we treat the two separately in product scope.

VMware to Hyper-V: Microsoft tooling and disk conversion

For Hyper-V targets, Microsoft Virtual Machine Converter and disk2vhd are the standard tools. After migration, Storware protects Hyper-V environments via an agent-based architecture — Hyper-V’s API model requires this, and Storware applies precise agent-based handling specifically for Hyper-V, file-level OS Agent backups, and application-consistent backups. Everything else in the Storware platform remains agentless.

VMware to KVM (Oracle Linux KVM, Red Hat ecosystem): virt-v2v

For KVM-based targets, virt-v2v is the established open-source tool. It handles ESXi-to-KVM conversion including driver injection for Linux and Windows guests. Storware protects KVM environments agentlessly after migration.

The pattern. For five of the six target platforms, the migration tool is whatever the target platform ships natively or via its ecosystem. Adding a third-party migration product is rarely the right architectural choice — the native tooling is well-supported, free or low-cost, and tightly integrated with the target. Where Storware adds architectural value is in phase two: protecting whichever platform you land on, with the same product and licence you used for VMware.

The protection step — Storware across the post-VMware landscape

This is the steady-state argument. Whatever target platform you choose, Storware Backup and Recovery protects it — under one universal licence that also covers the VMware estate during migration.

Concrete coverage, with the architectural model for each:

• OpenStack (Red Hat OpenStack Platform, Canonical OpenStack, Virtuozzo Hybrid Infrastructure, OpenMetal, Platform9, community deployments) — agentless via Keystone. Storware is the only data protection company invited to co-author the official VMware-to-OpenStack Migration Guide and is an OpenInfra Foundation member.
• Proxmox VE — agentless. Native Proxmox API integration. Storware’s feature set on Proxmox includes the same IsoLayer air-gap, WORM immutability, AES encryption, RBAC, and multi-tenancy as on every other platform.
• Nutanix AHV — agentless via Prism Element API. Storware also supports Nutanix Volume Groups as a secondary backup destination.
• OpenShift Virtualization — agentless. Distinct product scope from OpenShift Containers.
• Microsoft Hyper-V — agent-based (Hyper-V architecture requires this). Storware applies precise agent-based handling for Hyper-V, file-level OS Agent backups, and application-consistent backups; everything else remains agentless.
• KVM (Oracle Linux KVM, Red Hat ecosystem, Canonical ecosystem) — agentless.
• Long tail — VergeOS, XCP-ng, Citrix Hypervisor, Scale Computing, and others. Same universal licence; full product feature parity.

Across all of these, the same Storware features apply: policy-driven scheduling, agentless backups where possible, IsoLayer air-gap protection, WORM immutability for ransomware resilience, AES encryption, multi-factor authentication via Keycloak, role-based access control, multi-tenancy for MSP and service-provider deployments, Recovery Plans, Instant Restore, and a documented RESTful API.

Backup destinations are equally flexible: local filesystems, object storage (S3-compatible and major hyperscalers), Storware Cloud (N-able, Vawlt, Seagate Lyve Cloud tiers), tape, and external providers. Storware Backup Appliance (SBA) models — 1010E/1010, 1020 (100TB), 2050 (250TB), 2100 (500TB) — are available for organisations that prefer a turnkey hardware option.

The longer architectural write-up lives on the V2V Migration solution page for the OpenStack-specific path, and on the Storware Backup and Recovery product page for the full multi-hypervisor protection story.

European data sovereignty: GDPR, NIS2, DORA, and the CLOUD Act

For European organisations migrating off VMware, the choice of data protection vendor is also a sovereignty decision. Three regulatory threads matter:

GDPR requires that personal data is processed under EU jurisdiction or under an equivalent regime. For backup data specifically, this includes the metadata catalogue — not just the workload payload. A vendor whose control plane is operated under US jurisdiction creates a measurable compliance question.

NIS2 (in force across EU member states from October 2024) requires that essential and important entities have demonstrable supply-chain security, including for cloud and managed service providers. The directive specifically requires that suppliers can be held to EU-equivalent standards.

DORA (applicable from January 2025) requires financial-services entities to maintain operational resilience including against ICT third-party risk. The regulation gives competent authorities direct oversight of critical ICT third-party providers — which includes backup and data protection vendors.

Layered on top of all three is the CLOUD Act conflict: US-based vendors can be legally compelled to produce data held anywhere in the world, including in EU regions. This creates a documented tension with GDPR Article 48 and is the subject of ongoing legal commentary.

Storware is headquartered in Warsaw, Poland. The control plane, support, and engineering are EU-based. The platform is GDPR-aligned by design and used by EU public-sector and regulated-industry customers under both NIS2 and DORA constraints. For organisations whose VMware exit is also a US-vendor exit, that combination matters.

A deeper treatment of these regulations and their interaction with VMware migration appears in our European VMware Exit whitepaper (available from the resources library).

Step-by-step: VMware to OpenStack migration with Storware

The workflow below walks through a VMware vSphere to OpenStack migration using Storware Backup and Recovery. This is the migration path Storware delivers end-to-end. For other target platforms, follow the platform-native tooling described in section 5; this workflow applies specifically to OpenStack and OpenStack-based platforms. Full documentation is at docs.storware.eu.

Step 1: Inventory and assess

Catalogue every VMware VM in scope. Capture vCPU, vRAM, attached storage, network configuration, OS, and any special characteristics (hardware passthrough, vGPU, NSX-specific networking). Classify each VM into lift-and-shift, refactor, or special-handling buckets. The output is a migration backlog with realistic batch sizing.

Step 2: Connect VMware as a Virtualization Provider

In the Storware Backup and Recovery WebUI, add vCenter as a Virtualization Provider using service-account credentials with at least the read and snapshot privileges defined in the documentation. Storware discovers all VMs automatically; no agent is installed inside guests.

Step 3: Run a full backup of the migration cohort

Create a policy-driven backup schedule covering the VMs in the current migration batch. Enable application-consistent quiescing where required (the OS Agent handles this for transactional workloads). Confirm successful completion and verify catalogue integrity.

Step 4: Connect the target OpenStack as a Virtualization Provider

Add the target OpenStack instance as a Virtualization Provider. Storware supports Red Hat OpenStack Platform, Canonical OpenStack, Virtuozzo Hybrid Infrastructure, OpenMetal, Platform9, and community deployments. Authentication uses the standard Keystone identity service.

Step 5: Restore the backup to the OpenStack target as a V2V migration

For each VM in the cohort, initiate a restore. Select the source backup, choose the target OpenStack Virtualization Provider, configure the target network mapping and storage placement (Cinder volumes for OpenStack), and run the restore. Storware handles disk format conversion, driver injection, and the OpenStack instance creation transparently.

Step 6: Validate

Power on each migrated VM, verify network connectivity, validate application function, and confirm that backups of the new OpenStack instances run successfully. The migrated workload is now protected by the same Storware policy — no gap.

Step 7: Cut over and decommission

Once validation is complete for the batch, update DNS, load balancers, and dependent integrations to point at the OpenStack instances. Power down the corresponding VMware VMs. Retain the original VMware backups for the agreed rollback window before decommissioning.

For a recorded walkthrough of this workflow, see the Storware YouTube channel: youtube.com/@Storware.

Next step: scope your VMware exit against your own environment

Storware solution architects run scoped assessments against live VMware environments. The output is a written assessment with target-platform recommendations, batch sizing, realistic project duration for the migration phase, and a protection strategy for the steady state — covering whichever target platforms you choose.

Book a migration assessment

Frequently asked questions

Which target platforms does Storware support for V2V migration from VMware?

Storware delivers V2V migration directly for VMware to OpenStack and OpenStack-based platforms — Red Hat OpenStack Platform, Canonical OpenStack, Virtuozzo Hybrid Infrastructure, OpenMetal, Platform9, and community deployments. For other target platforms, customers typically use platform-native migration tooling (Proxmox’s built-in importer, Nutanix Move, Red Hat MTV for OpenShift Virtualization, Microsoft Virtual Machine Converter for Hyper-V, virt-v2v for KVM). Storware Backup and Recovery protects all of those target platforms after migration.

Which target platforms does Storware support for backup and recovery?

OpenStack (all major distributions), Proxmox VE, Nutanix AHV, OpenShift Virtualization, Microsoft Hyper-V, KVM (Oracle Linux KVM, Red Hat ecosystem, Canonical ecosystem), VergeOS, XCP-ng, Citrix Hypervisor, Scale Computing, and others — 15+ platforms under one universal licence, alongside VMware vSphere.

Which VMware versions does Storware support?

VMware vSphere with ESXi 7.0 and 8.0. Both are supported as backup sources and as V2V migration sources (for the OpenStack path).

Do I need to install agents on my VMs?

For VMware, OpenStack, KVM, Nutanix AHV, Proxmox VE, XCP-ng, OpenShift Virtualization, and most other platforms, Storware operates agentlessly through hypervisor APIs. Agent-based handling applies specifically to Hyper-V (where Microsoft’s architecture requires it), file-level OS Agent backups, and application-consistent backups for transactional workloads.

What happens to my data protection during the migration project?

Storware protects both the VMware source and the target environment with the same universal licence. There is no protection gap — VMs are backed up before migration, and the same platform continues protecting them on the target after migration completes.

If I migrate to Proxmox or Nutanix AHV with platform-native tooling, what do I lose by not using a Storware-led migration?

Nothing meaningful, because the platform-native tooling for those targets is well-supported and tightly integrated. What you gain by using Storware in the steady state is uninterrupted protection coverage across both source and target during the project window, plus a single backup product and licence that protects the new environment for as long as it exists.

Why does Storware deliver V2V for OpenStack but not for other targets?

Because OpenStack is the platform where backup-as-migration architecture is most useful. OpenStack adoption typically involves larger estates, multi-tenant deployments, and longer project windows — exactly the conditions where a separate migration tool creates the most operational overhead. For target platforms with mature, free, vendor-supplied migration tools (Nutanix Move, Proxmox’s importer, Red Hat MTV, Microsoft VMM Converter), adding a third-party migration product is rarely the right architectural choice.

How does Storware compare to standalone migration tools like Trilio?

Trilio is primarily a migration product positioned around the bounded project window. Storware is a multi-hypervisor data protection platform that happens to include V2V migration to OpenStack as a feature. The architectural question is whether you want a tool optimised for the migration window (the Trilio model) or a tool optimised for the multi-year steady state that follows (the Storware model). For OpenStack-bound estates the two overlap; for everything else, the protection-layer argument is where Storware competes.

Is Storware affected by the CLOUD Act?

No. Storware is headquartered in Warsaw, Poland, with EU-based engineering, support, and control-plane operations. The platform is outside the US extraterritorial jurisdiction that the CLOUD Act creates for US-headquartered vendors.

How long does a typical VMware-to-OpenStack migration take with Storware?

Project duration depends on VM count, workload complexity, and target OpenStack distribution. A typical 100-VM cohort can complete validation in two to four weeks once policies and Virtualization Providers are configured. Larger estates are batched. Storware solution architects can scope realistic timelines against a specific environment.

Related reading

• V2V Migration solution page — the OpenStack-specific migration path in detail
• Storware Backup and Recovery product page — full multi-hypervisor protection scope
• Storware Backup and Recovery 7.1 release notes — introduction of cross-hypervisor restoration
• What is V2V migration? — primer
• Book a migration assessment