Introduction

A vSphere migration can bring the new vCenter online while one or more ESXi hosts are still managed through the old one or still appear there because cleanup never finished. The new management plane appears healthy, but inventory stays incomplete, one cluster contains the migrated hosts while another still shows stale or still-attached host records in the previous vCenter, or host management fails only after the old vCenter is shut down because host registration, certificates, and automation often move separately from the compute layer itself.

Treat this as a management-plane attachment and inventory-cleanup problem instead of a generic ESXi outage. Start by checking which vCenter an affected host is actually registered with and whether the old vCenter is only showing stale inventory, because migrations often validate the new vCenter interface while live hosts or operator workflows still depend on the earlier management target.

Symptoms

  • An ESXi host still registers to the old vCenter after migration
  • The new vCenter is healthy, but some hosts never appear or remain disconnected there
  • One host or cluster uses the new vCenter while another still belongs to the previous one
  • Management or lifecycle tasks fail only after the old vCenter is retired
  • The host is online and running VMs, but inventory and policy still depend on the old management plane
  • The issue started after moving vCenter, clusters, or virtualization management infrastructure

Common Causes

  • The ESXi host was never cleanly detached from the old vCenter before migration
  • Certificates or trust relationships still bind the host to the previous vCenter
  • Cluster membership, datacenter mapping, or host-add workflows updated some hosts but not others
  • Automation, host profiles, or provisioning scripts still register rebuilt hosts to the retired vCenter
  • DNS aliases, management records, or inventory tooling still point operators to the old control plane
  • Validation confirmed the new vCenter was online but did not verify where each live host actually reported

Step-by-Step Fix

  1. Capture one affected ESXi host and record the vCenter registration, cluster membership, certificate trust, and management endpoint it actually uses, because the runtime management attachment determines where lifecycle operations really land.
  2. Compare that active host-management path with the intended post-migration vSphere design, because one stale registration can keep a host tied to the retired control plane.
  3. Review vCenter inventory, ESXi host registration, certificates, cluster placement, and automation for references to the old vCenter, because host attachment depends on management trust and inventory state together.
  4. Check each host, cluster, and provisioning path separately if behavior differs, because migrations often fix one host group while another still uses the previous vCenter.
  5. Update the authoritative host registration and trust configuration so affected ESXi hosts attach to the intended vCenter, because standing up the new management plane alone does not retarget existing hosts.
  6. Run a controlled host-management action and confirm the intended vCenter handles the task for the affected host, because a reachable ESXi management interface does not prove the right vCenter owns it.
  7. Verify the old vCenter no longer owns active host management or stale inventory records for the migrated hosts, because operator confusion and automation errors can persist even after the actual host attachment has moved.
  8. Review certificates, DNS, lockdown settings, and automation templates if registration still fails, because the destination can be correct while trust or host policy still blocks the new attachment.
  9. Document which team owns host onboarding, certificate trust, and migration validation so future vCenter cutovers verify the actual management target per host before retiring the previous control plane.