VMware workload planning: retain, rehost, replatform or retire

Scope and applicability

This note applies to estates running VMware vSphere, with or without vSAN, whose owners are deciding what to do with each workload as licensing, support and hardware cycles change. It covers the four paths a workload can take: retain it on vSphere and plan the next platform upgrade, rehost it on another hypervisor or a cloud, replatform it onto containers or OpenShift Virtualization, or retire it. The decision is per workload. An estate-wide exit date is a budget line, not a plan.

In our layer model the virtualization platform is T1. The platform team owns vCenter, ESXi, vSAN, the hardware and firmware under them and the storage policies the workloads depend on. Replatform targets such as OpenShift Virtualization sit in T2 and bring a second platform team into the decision. The workloads themselves are T3: their owners know the dependencies, the tolerated downtime and whether anyone still uses the application. Procurement owns the entitlement dates that make the decision urgent.

This is an engineering reference, not a report of a customer migration and not licensing advice. Release names, tool names and the data-source attributes below are illustrative; confirm support dates, hardware compatibility and migration tooling against the vendor documentation for the installed releases before committing a wave.

• Broadcom: end of general support for vSphere 7.0
• Red Hat: Virtualization Migration Assessment

Where the handoff seam breaks

Storage policy is the first seam. A vSAN storage policy that guarantees a failure tolerance and a stripe width has no direct equivalent in a target storage class, and the T3 owner who never saw the policy discovers the difference as latency after cutover. vSAN Original Storage Architecture disk groups and Express Storage Architecture NVMe pools also have different hardware lists, so a retain decision that assumes the current hosts carry the next vSAN release can fail its own compatibility check.

Shared disks and snapshots are the second seam. Disks attached to several VMs in multi-writer mode can only move cold, and a long snapshot chain left by a backup tool slows every copy and inflates every cutover estimate. The snapshot that nobody deleted after last quarter’s change is a migration risk that shows up as a stalled transfer at two in the morning.

Identity pins are the third seam. Licences bound to a MAC address, firewall rules bound to an IP, and monitoring agents registered to a hypervisor-generated UUID all survive the migration tooling and break the application afterwards. None of them appear in a VM inventory; they appear in the application owner’s memory, which is why the owner is a required column in the decision record.

Rules and placement are the fourth seam. Distributed Resource Scheduler affinity and anti-affinity rules, host groups and reservation shares express availability requirements that the target platform has to express in its own terms. A database pair that vSphere kept on separate hosts can land on one node after a rehost unless somebody translates the rule.

• Broadcom: vSAN ESA hardware compatibility guide
• Broadcom: VMware snapshot best practices

Pre-flight and validation matrix

Run the matrix once per wave, against the workloads in that wave, before the pilot and again before each production cutover. A row without an evidence reference is a failed row. Every command is read-only; the roles name who signs the evidence.

• Migration Toolkit for Virtualization 2.12: planning your migration

Inspectable artifact: read-only OpenTofu inventory

The configuration below uses only data sources. A plan reads the VMs in a wave from vCenter under a read-only role and emits one record per workload with the facts the platform reports: guest identity, firmware, hardware version, sizing, disks and networks. The decision and the owner are placeholders the assessment fills in, so the record and the evidence live together in the repository.

OpenTofu is one way to read the platform; PowerCLI or the vCenter API give the same facts. What matters is that the inventory comes from the platform rather than a spreadsheet, runs again before every wave, and is diffed against the last run so new VMs and new disks cannot arrive unnoticed.

# workload-inventory.tf -- OpenTofu, data sources only. A plan reads vCenter; it changes nothing.
terraform {
  required_version = ">= 1.8.0"
  required_providers {
    vsphere = {
      source  = "hashicorp/vsphere"
      version = "~> 2.10"
    }
  }
}

provider "vsphere" {
  vsphere_server       = "vcenter.example.invalid"
  user                 = var.vsphere_user     # read-only role: no power, configure or snapshot privileges
  password             = var.vsphere_password # from the pipeline secret store, never a tfvars file
  allow_unverified_ssl = false
}

variable "vsphere_user" { type = string }
variable "vsphere_password" {
  type      = string
  sensitive = true
}

variable "workloads" {
  description = "VM names in the wave under assessment, one decision record each."
  type        = list(string)
  default     = ["REPLACE_WITH_VM_NAME"]
}

data "vsphere_datacenter" "site" {
  name = "REPLACE_WITH_DATACENTER"
}

data "vsphere_virtual_machine" "workload" {
  for_each      = toset(var.workloads)
  name          = each.value
  datacenter_id = data.vsphere_datacenter.site.id
}

# The decision record starts from facts the platform reports, not from a spreadsheet.
# Snapshot age and changed block tracking come from the backup tool report; this data source
# does not expose them, so the matrix lists them as separate rows.
output "workload_inventory" {
  value = {
    for name, vm in data.vsphere_virtual_machine.workload : name => {
      guest_id         = vm.guest_id
      firmware         = vm.firmware
      hardware_version = vm.hardware_version
      cpus             = vm.num_cpus
      memory_mb        = vm.memory
      disks            = [for d in vm.disks : {size_gb = d.size, thin = d.thin_provisioned}]
      network_ids      = vm.network_interfaces[*].network_id
      decision         = "REPLACE_WITH_RETAIN_REHOST_REPLATFORM_OR_RETIRE"
      owner            = "REPLACE_WITH_APPLICATION_OWNER"
    }
  }
}

• OpenTofu: data sources

Rollback and recovery boundaries

Platform state is the first boundary. The vCenter inventory, cluster settings, storage policies, distributed switch configuration and placement rules can be re-applied from a vCenter backup or from code. If a retained platform’s upgrade fails, this is what the vendor procedure restores, and it should be exercised in the test environment before the production window.

Guest persistent data is the second boundary and does not come back with platform state. For a rehost or replatform wave, keep the source VM intact and powered off until the wave is formally accepted. A powered-off source contains nothing written on the new VM after cutover, so rolling back means isolating the new VM, deciding how data written since cutover is reconciled, and only then starting the source and moving DNS or the load balancer back. A snapshot taken before cutover is a convenience for the copy tool, not a backup.

Retire is a recovery decision too. A retired workload needs its data archived to an agreed retention location, its licences released and its monitoring removed, with a written date after which the archive is the only copy. Retire without an archive owner is just a VM that nobody powers on until the day somebody needs it.

Write the recovery authority down for every wave: who can stop a cutover, how long a wave may run before rollback, and who approves data reconciliation. Measure the restore and the rollback in the pilot, because the pilot is the only place to find out that the source takes forty minutes to boot after a month powered off.

• Migration Toolkit for Virtualization 2.12: planning your migration
• Broadcom: VMware snapshot best practices

How we approach it

Bring the workload inventory, the entitlement dates, the storage architecture and the candidate targets to the discussion. The Assessment Sprint produces the per-workload decision record, the validated matrix for the first wave and the recovery boundaries in writing. Migration execution and retained-platform upgrades are scoped separately for the installed releases.