VMware Exit Strategy: The Complete Technical Guide

Broadcom's acquisition of VMware completed in November 2022 and fundamentally restructured how organizations license and deploy vSphere infrastructure. The changes create immediate operational and financial pressure that cannot be ignored at contract renewal time.

Broadcom eliminated perpetual VMware licenses in early 2024, forcing all customers to subscription-only models. Product SKUs consolidated into VMware Cloud Foundation (VCF) bundles, requiring organizations to purchase capabilities they may not use. The partner ecosystem contracted significantly—fewer VARs, changed incentive structures, reduced deployment flexibility.

Organizations face a live contract decision at renewal: does the cost of staying on vSphere at new Broadcom pricing justify operational continuity, or is migration cost plus new platform cost a better five-year investment? Price increases at renewal range from significant to substantial, depending on prior licensing model and current entitlements.

This is not a planning exercise for most enterprises—it is an active contract decision being made at renewal. Organizations cannot wait for 100% application readiness before starting their exit strategy. The on-premises AHV environment gets built regardless—VMC on AWS handles what cannot move yet.

Before choosing a migration path, inventory what you have and how it operates. This assessment creates the foundation for workload classification and migration path selection.

Document your complete vSphere environment: total vSphere host count and hardware generation (ESXi version), cluster count and sizing distribution, and vCenter server count, version, and management scope. This inventory drives infrastructure sizing for the target environment.

Identify features that create migration complexity or require bridge strategies. vSAN changes storage architecture significantly if present. NSX-T/NSX-V creates major dependency requiring separate remediation. vSphere Replication/SRM represents DR architecture dependency with operational impact.

vMotion/DRS have AHV equivalents but behavior differs operationally. VMware Tools/VMCI guest integration requires compatibility assessment. HCX becomes relevant for VMC on AWS bridge—HCX enables migration to VMware Cloud on AWS if licensed.

Classify each VM into three categories that drive migration path decisions:

AHV-ready: Standard Windows/Linux VMs without VMware-specific dependencies. These represent the majority of most environments and migrate cleanly via Nutanix Move.

VMware-dependent: Applications requiring NSX policies, SRM integration, or ISV hypervisor certification. These workloads bridge to VMware Cloud on AWS during the migration.

Refactor candidates: Workloads where VMware dependency signals broader modernization need. These may bridge to VMC on AWS or move directly to cloud-native alternatives.

This classification determines the split between on-premises AHV migration and VMC on AWS bridge placement, directly impacting project scope and economics.

Storage architecture heavily influences migration path choice and timeline. Pure FlashArray with iSCSI or FC connectivity to vSphere hosts can be retained and connected to AHV. vSAN represents software-defined storage local to hosts that requires data migration. Other SAN/NAS solutions need connectivity assessment for AHV compatibility.

Document your Broadcom renewal date and required notice period, current entitlements (licenses versus subscriptions), support contract status and coverage, and Broadcom license portability to VMC on AWS (BYOL eligibility). This information drives project timeline and bridge strategy economics.

Every VMware exit strategy follows one of four primary paths, determined by current architecture, storage investments, and workload dependencies. Understanding when each path makes sense prevents costly false starts.

Best for: Organizations with vSphere as primary hypervisor, no deep NSX dependency, and storage architecture compatible with Nutanix or willingness to change it. The clean-exit path.

Architecture Outcome: Nutanix AHV on Cisco UCS, with Pure FlashArray external storage (disaggregated) or native Nutanix HCI storage (converged). Arista fabric provides IP interconnect.

Migration Tools: Nutanix Move performs online replication of VM disks to Nutanix AHV format, then executes cutover. Supports Windows Server 2008R2 through current versions, major Linux distributions. Does not handle VMware-specific features like NSX policies, certain vGPU passthrough configurations, or VMCI sockets.

VMware-dependent workloads that cannot migrate via Nutanix Move route to the VMware Cloud on AWS bridge rather than blocking the AHV migration. Timeline is typically 12-24 weeks for full environment depending on VM count and data volume.

Best for: Organizations with significant Pure FlashArray investment under active support contract who want to exit VMware hypervisor but retain storage platform.

Architecture: Nutanix AHV runs on compute-only nodes (Cisco UCS recommended) with Pure FlashArray as external storage, connected via iSCSI or NVMe/TCP.

Why This Matters: Many organizations have 3-5 years remaining on Pure support agreements. Replacing Pure to achieve full HCI convergence creates a CFO conversation when the storage performs well and remains under support.

Operational Trade-off: Slightly more complex operations—Prism Central manages compute and virtualization, Pure1 manages storage. Not a single pane of glass natively. IVI's Aegis co-managed services bridge this by providing unified monitoring across both platforms via LogicMonitor.

Best for: Organizations with VMware-specific dependencies (NSX, SRM, specific ISV integrations) that cannot be re-platformed immediately.

VMware Cloud on AWS serves as the AIM bridge approach for workloads that cannot move to AHV on the primary migration timeline. VMC on AWS provides a native vSphere environment on AWS infrastructure where VMware-dependent workloads continue running while applications are upgraded, refactored, or replaced.

Critical Understanding: VMC on AWS is a managed service where VMware (now Broadcom) and AWS jointly provide the infrastructure and management. Customers can use BYOL for certain scenarios or pay for VMware licensing through the service. VMC on AWS is not the same as running vSphere on EC2 instances.

Best for: Organizations currently running vSAN who want to exit vSphere entirely and move to comparable HCI model under single vendor management.

Architecture: Nutanix nodes with native AOS distributed storage replace vSAN clusters. Cisco UCS or other Nutanix-compatible server hardware provides compute foundation.

Key Difference: Storage also migrates—data must be rehydrated from vSAN format to Nutanix DSF (Distributed Storage Fabric). This represents the most significant migration operation and requires careful capacity planning and execution.

Nutanix Move handles VM migration; storage migration requires Nutanix data services or third-party backup/restore methodology depending on data size and complexity. VMware-dependent workloads that surface during vSAN migration follow the same VMC on AWS bridge path—they do not block the vSAN-to-HCI transition.

Understanding workload compatibility with AHV versus VMware Cloud on AWS determines migration path and timeline. Most enterprise workloads move cleanly, but specific dependencies require planning or bridge strategies.

Standard Windows Server VMs (file/print, AD/DNS, standard applications) and standard Linux VMs (web servers, app servers, database servers running MySQL, PostgreSQL, etc.) migrate without issues. VMs without VMware-specific hardware dependencies (VMCI, vGPU on certain configurations) and VMs with standard vmxnet3 NICs move cleanly—Nutanix Move converts to virtio automatically.

vGPU Passthrough VMs: AHV supports GPU passthrough but configuration differs from vSphere. Requires per-VM assessment and reconfiguration.

Windows Server VMs with vSphere Replication: Replace with Nutanix Protection Domains and async replication. Requires DR runbook updates and testing.

Applications with VMware vSphere API for Data Protection (VADP) Integration: Most enterprise backup products (Veeam, Commvault, Rubrik) support AHV natively. Verify backup product AHV support before cutover execution.

Applications Certified on vSphere but Not Explicitly AHV: ISV certification lookup required. Most major enterprise applications (Oracle, SAP, Microsoft SQL Server) support AHV. Reference the Nutanix Ready program and compatibility documentation for authoritative compatibility information.

Applications Dependent on NSX-T SDN Policies: Cannot be re-platformed on the AHV migration timeline without network re-architecture.

SRM-Protected Workloads: Where DR runbooks are complex and revalidation timeline exceeds migration window capacity.

Tier-1 Workloads with ISV License Terms: Requiring specific hypervisor certification (vSphere only, no AHV certification available).

Vendor-Restricted Workloads: Any workload where the application vendor refuses AHV certification or support.

These workloads move to VMware Cloud on AWS as a time-bounded bridge. Every workload placed on VMC on AWS receives an exit plan: upgrade to AHV-certified version, refactor to remove VMware dependency, replace with cloud-native alternative, or retire. VMC on AWS serves as temporary infrastructure, not permanent hosting.

VMware Cloud on AWS is a jointly engineered service that runs VMware's software-defined data center (SDDC) stack on dedicated, bare-metal AWS infrastructure. The service provides native VMware vSphere, vSAN, NSX, and vCenter in an AWS-hosted environment.

VMC on AWS is not EC2 instances running VMware—VMC runs on dedicated bare-metal hosts. It is not customer-managed infrastructure—AWS and VMware jointly manage the underlying infrastructure. It is not a direct replacement for on-premises VMware—it's a bridge service with different operational characteristics.

VMC on AWS solves a specific, time-bounded problem in the AIM engagement. It eliminates on-premises hardware commitment—organizations do not need to refresh on-premises ESXi server hardware to keep a shrinking set of VMware workloads running.

It decouples hardware refresh from application re-platforming—organizations can decommission on-premises VMware infrastructure without waiting for every application to achieve AHV readiness. It provides stable AWS-hosted vSphere environment that serves as temporary home while VMware-dependent applications are upgraded, refactored, or replaced.

VMC on AWS functions as a bridge, not a destination. Organizations that treat it as a destination continue paying for VMware licensing indefinitely, now with added AWS infrastructure cost.

Phase 1: Workload Classification - Inventory the full VM estate and classify every workload into AHV-ready (typically 70-90% of VM estate), VMware-dependent (applications with NSX-T policy dependencies, SRM-based DR, ISV hypervisor certification requirements), and refactor/replace candidates.

Phase 2: Build Both Target Platforms in Parallel - AIM engagement stands up Nutanix AHV on Cisco UCS plus Pure on-premises. VMC on AWS environment stands up VMware Cloud on AWS for VMware-dependent workloads. Both platforms build concurrently.

Phase 3: Execute AHV Migration - Nutanix Move migrates AHV-ready workloads to on-premises AHV. This represents the primary AIM workstream and covers the majority of VMs.

Phase 4: Move VMware-Dependent Workloads to VMC on AWS - VMware-dependent workloads move to VMware Cloud on AWS using VMware HCX or vMotion within the vCenter domain. These workloads continue running on vSphere—the underlying infrastructure changes from on-premises servers to AWS-managed bare-metal.

Phase 5: Retire On-Premises VMware Hardware - Once both migrations complete, on-premises ESXi hosts and vCenter are decommissioned. The on-premises VMware hardware refresh cycle breaks.

Phase 6: Application Work on VMC on AWS - Every workload on VMC on AWS needs a plan: upgrade to AHV certification, refactor to remove VMware dependency, replace with cloud-native alternative, or retire. VMC on AWS has finite lifespan in the architecture.

IVI's AIM practice designs and delivers the on-premises Nutanix/UCS/Pure environment. IVI's AWS practice handles VMC on AWS environment design, deployment, and ongoing management. These are coordinated but operationally separate workstreams.

For clients using both on-premises AHV and VMC on AWS, Aegis co-managed services provide unified monitoring across both environments via LogicMonitor—giving operations a single view regardless of where workloads currently live.

IVI also owns Phase 6 application exit planning for VMC on AWS workloads, tracking each workload's path off VMC on AWS and coordinating migration back to on-premises AHV (or to AWS native services) as applications become ready.

The AIM methodology provides a structured approach to VMware exit that minimizes risk while maximizing operational continuity. Each phase has defined deliverables and success criteria.

Full VMware environment inventory via automated tools (RVtools or PowerCLI). Workload classification drives AHV versus VMC on AWS split. Storage architecture documentation and compatibility assessment. Network dependency mapping covers VLANs, subnets, application communication patterns.

Existing Pure/UCS asset inventory if applicable. VMC on AWS sizing estimate for VMware-dependent workloads includes host count, storage, network connectivity to on-premises. Output is Migration Path Recommendation and Project Scoping Document, including VMC on AWS bridge scope if applicable.

Nutanix cluster design covers node count, storage tier, replication factor. UCS domain design includes FI pair, service profile templates, firmware baseline. Arista fabric design for storage VLANs. Pure FlashArray integration design covers iSCSI or NVMe/TCP, volume groups, host mappings.

Network integration with existing data center fabric. VMC on AWS environment design if applicable: AWS account structure, SDDC sizing, Direct Connect or VPN to on-premises, licensing model selection. Aegis co-managed services pre-provisioned and monitoring before first workload migrates, covering both on-premises AHV and VMC on AWS environments.

5-10 VMs representing workload types across environment. Validates Nutanix Move behavior, network connectivity, storage performance, application functionality post-migration. Establishes baseline performance metrics and operational procedures. For VMC on AWS-bound workloads: validate HCX or vMotion path to VMC on AWS environment.

Wave sequencing based on application criticality, business calendar, application interdependencies. Each wave includes pre-cutover replication, validation window, cutover execution, post-migration monitoring. Rollback plan maintained per wave with VM preserved in vSphere until confirmed stable on AHV. VMware-dependent workloads migrate to VMC on AWS on separate but coordinated wave schedule.

vCenter and ESXi hosts decommissioned in reverse order of migration. Pure FlashArray disconnected from former vSphere hosts, connected to AHV. UCS service profiles migrated from vSphere to AHV boot targets. On-premises VMware hardware retired or repurposed.

Each VMC on AWS-hosted workload tracked with defined exit criteria and timeline. As applications achieve AHV certification or are refactored/replaced, workloads migrate from VMC on AWS to on-premises AHV or AWS native services. VMC on AWS SDDC downsized as workloads exit. Target: Zero VMware workloads on VMC on AWS—complete VMware license retirement.

The post-migration architecture represents a modern, vendor-diverse infrastructure stack optimized for operational efficiency and cost effectiveness.

Compute: Cisco UCS X-Series (Intersight Managed Mode) provides the server foundation with centralized management and automated firmware lifecycle.

Hypervisor: Nutanix AHV requires no separate hypervisor license, reducing licensing complexity and cost.

Storage: Pure FlashArray (external, iSCSI or NVMe/TCP) or Nutanix native HCI storage, depending on migration path selected.

Fabric: Arista leaf-spine architecture provides high-performance, low-latency networking with CloudVision management.

Management: Prism Central + Cisco Intersight + Pure1 + Arista CloudVision provide platform-specific management with Aegis co-managed services via LogicMonitor delivering unified monitoring across all platforms.

VMware Cloud on AWS: VMware-dependent workloads on AWS-managed infrastructure with native vSphere stack.

Connectivity: AWS Direct Connect or VPN to on-premises AHV environment ensures secure, high-performance connectivity.

Monitoring: Aegis co-managed services cover VMC on AWS-hosted vSphere environment alongside on-premises AHV, providing single operational view.

Lifecycle: VMC on AWS workloads tracked for exit to AHV or AWS native services with defined timelines and success criteria.

This guide addresses specific organizational profiles and technical environments where the AIM approach delivers maximum value.

Organizations on vSphere 6.x through 8.x facing Broadcom renewal in the next 12-24 months represent the primary target. Organizations currently running Cisco UCS as compute platform have the most natural migration path to UCS + Nutanix AHV.

Organizations with Pure Storage investments wanting to retain storage while exiting VMware hypervisor licensing benefit from the compute-only Nutanix approach. Mid-to-large enterprises (50+ VMs, 5+ hosts) where migration complexity justifies architected engagement versus DIY approach.

Organizations that cannot tolerate extended downtime for production workloads benefit from Nutanix Move's online replication model that minimizes cutover windows. Organizations with mix of AHV-ready and VMware-dependent workloads who need defined bridge strategy rather than delaying entire exit.

Organizations heavily invested in VMware NSX-T as network overlay require network re-architecture as separate workstream from hypervisor migration. VMC on AWS can bridge NSX-T-dependent workloads during re-architecture period.

Organizations standardized on vSAN-based hyperconvergence where storage migration complexity dominates the challenge need specialized vSAN-to-HCI migration planning.

Organizations without Cisco UCS compute base who want to use commodity server hardware can be supported but AIM co-managed services model is optimized for UCS. Organizations looking for VMC on AWS as permanent VMware hosting solution should understand that VMC on AWS under AIM is a bridge with defined exit, not managed VMware hosting service.

Five core questions determine the optimal migration path for your environment, with additional VMC on AWS-specific criteria for organizations requiring bridge strategies.

1. Do you have active Pure FlashArray under support contract? YES leads to Path 2 (compute-only Nutanix + retained Pure). NO leads to Path 1 (full HCI convergence) or Path 4 (vSAN replacement with HCI).

2. Do you have VMware NSX-T deployed? YES means NSX must be separately addressed, with VMC on AWS bridge handling NSX-dependent workloads while network re-architecture proceeds. NO means simpler migration path with Nutanix AHV native networking sufficient.

3. What is your Broadcom renewal timeline? Under 6 months requires focus on quick-win AHV migrations first, VMC on AWS bridge for VMware-dependent workloads. 6-18 months allows full phased migration with VMC on AWS bridge if needed. Over 18 months enables full AIM engagement without renewal pressure.

4. Do you have VMware-specific ISV applications? YES requires workload classification with AHV-certified apps moving to AHV and VMware-only apps bridging to VMC on AWS. NO enables full migration to AHV without bridge requirements.

5. What is your RTO/RPO for Tier-1 workloads during migration? Aggressive requirements (under 1hr RTO) need wave-based approach with pre-staged replication and extended parallel-run windows. Standard requirements can use standard Nutanix Move replication with planned maintenance windows.

6. What percentage of your VMs are VMware-dependent? Under 10% makes VMC on AWS bridge small and straightforward to exit. 10-30% represents meaningful bridge requiring careful sizing and cost modeling. Over 30% usually indicates classification criteria are too conservative or environment has deep VMware platform dependencies needing dedicated remediation plan.

7. Do you have AWS Direct Connect or VPN to AWS already? YES simplifies VMC on AWS network connectivity establishment. NO requires factoring in Direct Connect provisioning timeline (typically 4-8 weeks) for VMC on AWS bridge environments with significant on-premises communication requirements.

The decision framework drives migration path selection and determines whether VMC on AWS bridge capability is required for your specific environment and timeline constraints.