A hypervisor migration moves every workload, every backup job and every privileged management account at once, and security controls built up over years on vSphere do not travel with the virtual disks. Licensing changes after Broadcom's acquisition of VMware, and the end of general support for vSphere 7, have pushed many organisations to plan an exit to Hyper-V, KVM, Nutanix AHV, Proxmox VE or public cloud. The conversion tools move VMs well; they do not recreate role-based access, distributed firewall rules, encryption key custody, logging or backup integration. This guide is for infrastructure, security and resilience leads running or approving a VMware exit. It covers the timeline, what is affected, how to inventory identities and controls, the migration options, testing and rollback, and how to decommission vCenter and ESXi safely. Platforms are listed alphabetically; order is never a ranking.
This is an independent guide from NHI Mgmt Group, based on VMware by Broadcom's public documentation as of November 2026. It is not sponsored or reviewed by VMware by Broadcom. Product features change, so confirm settings against VMware by Broadcom's current documentation.
Key takeaways
- Inventory controls, not just VMs. List every vCenter role, SSO identity source, service account, NSX or distributed firewall rule, encryption policy and backup job before you convert anything.
- Rebuild the management plane first. The target platform's admin identity, MFA, RBAC and logging must be ready before the first production VM lands, because the new console becomes the most powerful system in the estate.
- Encryption keys do not convert. vSphere VM encryption and vTPM state cannot be carried across; plan decryption, re-encryption on the target and BitLocker or LUKS recovery keys in advance.
- Backups break silently. Backup products that use VMware's VADP and changed block tracking need new jobs on the target. Test a restore on the new platform before decommissioning the old one.
- Decommission is a security task. vCenter holds credentials, certificates and integration accounts for half the data centre. Retire it deliberately and remove every trust it held.
What is changing and why
Broadcom completed its acquisition of VMware on 22 November 2023. Broadcom then announced that it had ended sales of perpetual licences and Support and Subscription renewals for perpetual offerings, that all offerings would be sold only as subscriptions or term licences, and that the portfolio would centre on VMware Cloud Foundation and VMware vSphere Foundation (with vSphere Standard and Essentials Plus remaining for smaller needs). Broadcom said customers with active support contracts could keep using perpetual licences. These commercial changes, not a product retirement, are the main reason organisations are evaluating alternatives.
The security point is that a migration is a high-risk change carried out under cost pressure. Conversion tools need high privileges on both platforms, controls are rebuilt by hand, and for weeks or months two platforms run side by side. The live Hypervisor and Virtualisation Security Guide covers securing a hypervisor; this guide covers keeping security intact while you change one.
Official timeline and current status
| Date | Event (as stated by the source) | Source |
|---|---|---|
| 22 November 2023 | Broadcom completes its acquisition of VMware | Broadcom investor news release |
| After the acquisition (Broadcom gives no date on the page; "effective dates will vary") | End of sale of perpetual licences and of SnS renewals for perpetual offerings; subscription or term licences only | Broadcom business transformation announcement |
| 2 October 2025 | End of general support for ESXi 7.x, vCenter Server 7.x and vSAN 7.x | Broadcom knowledge article 415405 |
Checked on 8 November 2026. If you are still on vSphere 7, you are past end of general support; see the VMware vSphere 7 End of General Support guide for the stay-and-upgrade path. Licensing terms are contractual and change: confirm yours with Broadcom or your reseller rather than relying on public summaries. Some target tools are also moving targets: Microsoft's VM Conversion extension for Windows Admin Center is documented as a preview that may change substantially before release.
Who and what is affected
- Management plane identities: vCenter Single Sign-On domain accounts, the identity source linked to Active Directory or LDAP, local ESXi root accounts, custom roles and global permissions.
- Integration and service accounts: accounts used by backup, monitoring, CMDB discovery, orchestration and infrastructure as code tools against the vSphere API. Each has a credential stored somewhere. See the Infrastructure as Code Security Guide.
- Network security: port groups, VLANs, private VLANs and, where NSX is used, distributed firewall rules and security groups that implement micro-segmentation.
- Encryption: VM encryption storage policies, vSAN encryption, key providers (standard via KMIP or native) and vTPM devices in Windows 11 and Windows Server guests.
- Backup and recovery: image-level backups, immutable copies, replication and disaster recovery runbooks built on vSphere snapshots and APIs.
- Logging and detection: vCenter events, ESXi syslog and SIEM use cases. See the ESXi Logs Detection Guide.
- People: virtualisation administrators whose privileges must be mapped to new roles, and security operations staff who need new detections.
Finding affected systems and identities
- Export vCenter permissions: list every role, its privileges and every principal assigned at each inventory level, including global permissions. Flag Administrator role holders and any role with VM console, datastore browse or cryptographic operations privileges.
- List non-human accounts: for each account that logs into vCenter or ESXi, record the owning tool, the credential type, where it is stored and its privileges. Expect to find shared administrator accounts used by several tools.
- Map network controls: export port groups, VLAN IDs and firewall rules to a rule set expressed in application terms (source, destination, port, purpose) rather than vSphere objects, so it can be rebuilt on any platform.
- Find encrypted and vTPM VMs: list VMs with encryption storage policies, vSAN encryption and vTPM devices; record the key provider and confirm recovery keys for in-guest BitLocker or LUKS are escrowed.
- Map backup coverage: list each protected VM, its job, retention, immutability and last successful restore test.
- Capture logging: list SIEM rules and dashboards that depend on vCenter or ESXi events so equivalents can be written for the target.
- Classify workloads: by criticality, data sensitivity and conversion difficulty (appliances, clustered applications, VMs with snapshots, large databases).
Migration options
Each platform has its own conversion route. What follows is drawn from each vendor's or project's documentation; deeper hardening sits in the linked platform guides.
| Target | Documented conversion route | Security points from the documentation | Platform guide |
|---|---|---|---|
| Hyper-V | VM Conversion extension for Windows Admin Center (preview): online replication from vCenter 6.x, 7.x and 8.x using changed block tracking, delta sync at cutover, up to 10 VMs per batch, cluster-aware migration to Windows Server Failover Clusters | Linux guests need Hyper-V drivers installed before migration; VMware Tools removed from Windows VMs in a cleanup step; Secure Boot and UEFI set by guest OS; check the preview licence terms for support coverage | Hyper-V Security Guide |
| KVM (libvirt) | virt-v2v converts a single guest from vCenter, ESXi, VMX or OVA (optionally over VDDK) to libvirt, oVirt, OpenStack, KubeVirt or local output | Source must be cleanly shut down; hypervisor passwords passed in files with mode 0600; TPM-sealed LUKS keys will not work on the new host, so add a passphrase keyslot first; BitLocker with vTPM prompts for the recovery key once; plan to remove VMware Tools manually if the automated step does not complete | KVM and libvirt Security Guide |
| Nutanix AHV | Nutanix Move appliance, typically on the target cluster; inventory through vCenter; data copied with VADP, VDDK and changed block tracking; pre-seeding then scheduled cutover | Move holds credentials to vCenter and the target; check UAC and WinRM settings before guest preparation; cutover should follow pre-seed within a week to limit source disk growth; AHV supports native or external KMIP key management for data at rest | Nutanix AHV and Prism Security Guide |
| Proxmox VE | Integrated ESXi import wizard (Proxmox VE 8 or later, tested from ESXi 6.5 to 8.0) or OVA/OVF import | Needs an ESXi admin account; "Skip Certificate Verification" is offered for self-signed certificates, so install a trusted CA instead; move vSAN-hosted and encrypted disks by another route and create a new vTPM on the target (confirm with Proxmox); remove VMware Tools and install VirtIO drivers first | Proxmox VE Security Hardening Guide |
Moving to public cloud IaaS changes the model more: the management plane becomes the cloud provider's IAM, network controls become security groups and network ACLs, and key custody moves to a cloud key management service. Treat it as a cloud landing zone project with the same inventory inputs. See the OpenStack Security Guide for a private cloud alternative.
Decision guidance
- Skills and tooling fit: a Windows-centric team with Active Directory and System Center skills will secure Hyper-V faster; a Linux-centric team will find KVM or Proxmox VE more natural. Choose a platform your team can harden and operate confidently.
- Security features you rely on today: if you depend on NSX micro-segmentation, confirm how the target enforces east-west policy (host firewall, platform micro-segmentation or a separate product) before committing.
- Backup vendor support: confirm your backup product supports the target hypervisor at image level with immutability, or plan a backup change at the same time.
- Size: small estates can often convert offline in maintenance windows; large estates need replication-based tools, waves and a longer dual-running period, which means two management planes to secure.
Rebuild the controls on the target
| Control | On vSphere | What to rebuild before cutover |
|---|---|---|
| Admin identity | vCenter SSO, AD identity source, custom roles | Federated admin login with MFA, named accounts, least-privilege roles, break-glass accounts in a vault. See the Privileged Access Management Guide. |
| Integration accounts | Shared vCenter service accounts | One scoped account or API token per tool, stored in a secrets manager, rotated |
| Segmentation | Port groups, PVLANs, NSX distributed firewall | Equivalent VLANs and east-west rules expressed in application terms, tested before production traffic |
| Encryption | VM encryption, vSAN encryption, vTPM | Target data-at-rest encryption with a defined key manager, new vTPMs, escrowed in-guest recovery keys |
| Backup | VADP-based image backups | New jobs, immutable copies and a tested restore on the target |
| Logging | vCenter events and ESXi syslog to SIEM | Target audit and host logs forwarded, with equivalent detections for admin logins, role changes, VM deletion and snapshot removal |
Testing and rollback
- Build and harden the target first: management plane, identity, logging and backup in place and reviewed before any production VM moves.
- Pilot ring: convert low-risk VMs, including one Windows and one Linux guest, one encrypted VM and one with a vTPM. Confirm boot, drivers, network, recovery key handling and removal of VMware Tools.
- Security validation: run a vulnerability scan and configuration check on converted guests; verify firewall rules by testing allowed and denied flows; confirm logs arrive in the SIEM.
- Restore test: back up a converted VM on the target and restore it to an isolated network.
- Waves: migrate by application, not by host, so segmentation rules move with the application.
- Rollback: keep the source VM powered off but intact until the application owner signs off; tools such as virt-v2v state the source must not be restarted unless conversion fails. Rollback means powering the source back on with its original network identity, so do not reuse its IP and MAC elsewhere until sign-off.
- Decommission vCenter and ESXi: after the last wave, remove integration accounts from every tool, delete vCenter SSO trust and AD identity source links, revoke certificates and key provider trust, remove KMIP client credentials from the key manager, wipe datastores and host boot media according to your sanitisation policy, and retire the hosts from monitoring and the CMDB.
Detection and measurement
- Watch during dual running: logins by migration tool accounts outside change windows, role changes on either platform, VM deletion or snapshot removal, and certificate verification being disabled.
- Metrics: percentage of migrated VMs with a tested restore on the target; percentage of firewall rules rebuilt and tested; number of shared admin accounts remaining; percentage of encrypted VMs re-encrypted on the target with keys under a named key manager; days of dual running; vCenter integration accounts still active after decommission (target zero).
Risks of doing nothing
- Unsupported versions: staying on vSphere 7 after 2 October 2025 without a support arrangement leaves the hypervisor layer outside general support.
- Rushed migration later: a migration forced by a renewal deadline skips the inventory and control rebuild described here.
- Hypervisor ransomware: management plane compromise with valid accounts (MITRE ATT&CK T1078) followed by mass encryption of VMs (T1486) is a known pattern against virtualisation layers. See the ESXi Ransomware Playbook.
Common failure patterns
- Clicking "Skip Certificate Verification" or reusing a shared root password for the import connection, then leaving it in place.
- Migrating VMs before the target has MFA and logging, so the first weeks run before those controls are in place on the new management plane.
- Forgetting that NSX rules do not convert, leaving converted VMs on a flat network.
- Decrypting VMs to migrate them and never re-encrypting.
- Decommissioning the VMware backup platform before a restore has been proven on the new one.
- Leaving vCenter running "just in case" with its integration accounts and AD trust intact.
Framework mapping
| Activity | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Inventory of VMs, accounts and controls | CM-8 | ID.AM |
| Management plane identity and MFA | IA-2, AC-2, AC-6 | PR.AA-05 |
| Segmentation rebuild | SC-7 | PR.IR-01 |
| Encryption and keys | SC-28, SC-12 | PR.DS-01 |
| Backup and restore testing | CP-9, CP-10 | RC.RP-01 |
| Logging | AU-2 | DE.CM |
| Decommissioning hosts and media | MP-6 | PR.PS-01 |
Practitioner checklist
- Export vCenter roles, permissions, identity sources and every non-human account with its owning tool.
- Translate network and firewall rules into application terms before choosing a target.
- List encrypted and vTPM VMs and confirm in-guest recovery keys are escrowed.
- Harden the target management plane with federated MFA login, named accounts and least-privilege roles first.
- Issue one scoped credential per migration and integration tool, stored in a secrets manager, and revoke it after use.
- Rebuild backup jobs and prove a restore on the target before decommissioning anything.
- Forward target audit and host logs and rewrite detections before the first production wave.
- Migrate by application in waves, keeping powered-off source VMs until sign-off.
- Decommission vCenter and ESXi by removing accounts, trusts, certificates and KMIP credentials, then sanitising media.
Standards and references
- Broadcom: End of General Support for vSphere 7.0
- Broadcom: VMware by Broadcom business transformation
- Broadcom: Broadcom Completes Acquisition of VMware
- Microsoft Learn: VM Conversion extension for Windows Admin Center
- libguestfs: virt-v2v manual
- Nutanix Bible: VM Migration Architecture
- Proxmox: Migrate to Proxmox VE
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Hypervisor and Virtualisation Security Guide · VMware vCenter Server Hardening Guide · Backup Security and Immutable Backup Guide · ESXi Ransomware Playbook