VMware exit strategy: business case and migration plan

Assess a VMware exit: The Virtualisation Exit Check combines inventory, Proxmox target design and migration planning. Arrange an initial discussion.

A VMware exit strategy answers three questions: which applications should move, under which technical conditions and with what economic justification? This calculation framework is a planning method, not measured savings. Product information as of October 2026. Contract quotations and approvals must be available at the decision date.

Contents

• Objectives and decision boundaries
• Inventory and target design
• Collect data for the business case
• Calculation scheme with placeholders
• Business case without false precision
• Migration waves and rollback
• Outline of the decision paper
• Approvals and next step
• Sources

Objectives and decision boundaries

Record the actual trigger: an expiring contract, a desired operating change or new requirements. Collect actual termination, renewal and usage terms from your own contract. General reporting about Broadcom or VMware cannot replace those documents. This article assumes neither a price increase nor a particular contract model.

Compare at least continued operation, partial migration and a complete move. Define mandatory criteria before calculating costs: application approvals, permitted interruption, recovery and ownership of target operations. Lower licence costs cannot make a target suitable if a mandatory criterion fails.

Inventory and target design

Map applications, VMs, hosts, storage, network functions, backups and identities. Include dependencies outside the VM, such as licence servers, appliances and storage integrations. The VMware migration checklist turns these into evidence to collect.

VMware alternatives supports open target selection. Proxmox VE combines KVM, LXC, storage and network management (product overview). That does not establish equivalence with every vSphere, vSAN or NSX function. For each function in use, record whether to map it to the target, replace it, change the application or retain it for now.

Collect data for the business case

Without an inventory every cost calculation stays an assumption. With VMware PowerCLI you can export the estate from vCenter as CSV (adjust the server address):

Connect-VIServer vcenter.example.com

# VMs: size, state, guest system
Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB, ProvisionedSpaceGB, UsedSpaceGB, VMHost, @{N='Guest';E={$_.Guest.OSFullName}} |
  Export-Csv vm-inventory.csv -NoTypeInformation

# Hosts: sockets and cores determine the licence basis on both sides
Get-VMHost | Select-Object Name, Version, ProcessorType, MemoryTotalGB,
  @{N='Sockets';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuPackages}},
  @{N='Cores';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuCores}} |
  Export-Csv host-inventory.csv -NoTypeInformation

Add what the export does not deliver: application owners, permissible interruption, backup method and dependencies outside the VM. The number of CPU sockets determines the Proxmox subscription; cores and minimum quantities determine the VMware licence according to the contract. Both values belong in the input list with a source.

Calculation scheme with placeholders

The scheme shows the structure of the calculation, not its magnitude. All quantities are variables that you fill from documented quotations and the inventory:

Continue (period T years)
  C_continue = T × (platform_renewal + operations_today + backup_today)

Switch (period T years)
  C_switch = one-off (analysis + build + transfer + acceptance)
           + T × (subscription × sockets + operations_new + backup_new + hosting_new)
           + transition (parallel run + decommissioning)

Difference per year  D = (C_continue − C_switch) / T
Payback              only if D > 0 and cumulative difference ≥ one-off

If a variable has no evidence, it stays "open" in the table and enters the base case and the variants as a range. A single figure without evidence does not belong in the decision paper.

Business case without false precision

Use the same period and service requirements for every option. Mark each input as evidenced, assumed or open, with its source, date and owner. Keep net and gross amounts, and one-off and recurring costs, separate.

Full cost per option = one-off costs + sum of recurring costs over the chosen period + transition and decommissioning costs. Avoid double counting: do not include hardware already covered elsewhere again as additional procurement. Show sunk acquisition costs separately from future payments.

Proxmox subscriptions are measured by occupied physical CPU sockets; the vendor pricing page describes their scope. Use current quotations rather than generic licence multipliers. Guest and application licences remain separate items; see Windows Server licensing.

Calculate a base case and variants for uncertain inputs, such as extended parallel operation or additional target hardware. Separate risks without monetary values from actual payments. Payback occurs only when the cumulative cost difference covers the additional switching costs. Report it if that does not happen within the chosen period. Reliable savings percentages require reliable inputs.

Turn assumptions into an assessment: The Virtualisation Exit Check brings together inventory, Proxmox target design and switching risks. Technical implementation is a separate commission.

Migration waves and rollback

Group by application and data dependencies, rather than VM count alone. Plan a bounded rehearsal first, then waves of related services. The Proxmox migration documentation recommends testing before production migration and covers imports and guest adjustments. The technical guide develops that procedure.

Each wave needs owners, prerequisites, a write freeze, data transfer, cutover and acceptance criteria. Define abort conditions and how new target data will be treated during rollback. Simply retaining the old VM does not reconcile data.

Also plan the operational handover: access, monitoring, backups, recovery, updates and escalation. PBS verify jobs check backup integrity; that does not establish application-level recovery. A restore test needs its own criteria.

Outline of the decision paper

1. Occasion and deadline: contract, expiry date, desired change.
2. Must-have criteria: application approvals, permissible interruption, recovery objectives.
3. Estate: figures from the inventory, dependencies, functions that cannot be mapped.
4. Variants: continue, partial move, full switch with target design.
5. Costs: table per variant with status documented, assumption or open.
6. Risks: technical, contractual and operational risks with a measure.
7. Wave plan: order, owners, abort criteria, rollback.
8. Recommendation and approvals: decision, named approvers, next steps.

Approvals and next step

The decision record includes the target and exceptions, cost variants with open assumptions, dependencies, waves and named approvals from IT and application owners. Missing critical evidence is a stop condition or a documented reason to remain on the source. Decommission only after documented acceptance, resolved retention and contract review.

WZ-IT assesses the Proxmox path in the Virtualisation Exit Check. VMware migration covers subsequent implementation. This does not imply an operating offer for every platform in the comparison.

Prepare a decision record: View the Virtualisation Exit Check or discuss the estate.

Sources

• Proxmox VE: capabilities
• VMware PowerCLI
• Proxmox VE: subscription model
• Proxmox: migration to Proxmox VE
• Proxmox Backup Server: verification