The Complete VMware HCX Migration Checklist: 70 Checks Before, During and After Cutover

VMWARE HCX MIGRATION CHECKLIST

A Consult Circle working checklist for vSphere to VCF migrations, covering discovery, compatibility, network, storage, build, execution and decommissioning.

This is the checklist we work through on vSphere to VCF migrations. It is not a summary of the product documentation. Every item on it exists because it caused a problem on somebody’s estate, and most of them cost a change window rather than an afternoon.

It is organised in the order the work happens: discovery first, then compatibility, licensing, network, storage, the HCX build itself, wave planning, the cutover window, post-migration validation and finally decommissioning. Work through it in order. The sections build on each other and several of the later checks are meaningless until the earlier ones have passed.

If you are running the migration with a partner, this doubles as a way of testing whether their runbook is thorough. If seventy items look excessive for your estate, that is a reasonable conclusion to reach after reading them rather than before.

What This Checklist Covers

• Discovery and inventory, ten checks
• Compatibility and eligibility, eight checks
• Licensing and access, six checks
• Network readiness, ten checks
• Storage and capacity, six checks
• HCX build and validation, eight checks
• Wave planning, five checks
• Cutover window, four checks
• Post-migration validation, seven checks
• Decommissioning, six checks

Discovery and Inventory

Everything downstream is priced and planned off this section. An inventory that is six months old will be wrong in both directions, and both directions cost money. Export it fresh and reconcile it against what the platform reports rather than against what the documentation says.

• Full virtual machine inventory exported from every vCenter, with power state, hardware version, guest operating system and resource allocation
• Inventory reconciled against the source of truth used by the business, with discrepancies investigated rather than averaged out
• Powered off and orphaned virtual machines identified, with a decision recorded for each: migrate, archive or delete
• Snapshots older than seven days identified and consolidated before migration planning proceeds
• Application dependency map produced, showing which workloads must move together
• Named owner identified for every significant application, with confirmation they know a migration is planned
• Downtime tolerance recorded per application, obtained from the owner rather than assumed from the tier label
• Templates, content libraries, ISO stores and folder structures catalogued, since these do not migrate with workloads
• Existing backup coverage documented per workload, including which jobs and which retention
• Monitoring and alerting coverage documented, so it can be re-pointed rather than rebuilt

Compatibility and Eligibility

Different migration mechanisms have different eligibility rules and the strictest is Replication Assisted vMotion. Audit against the strictest rule first, then assign the mechanism to what you find rather than choosing the mechanism and hoping the estate complies.

• Source vSphere and ESXi builds recorded per cluster and checked against the HCX interoperability matrix for the target VCF release
• HCX Connector and HCX Cloud Manager versions confirmed compatible with each other, since mismatched builds will not pair
• Target VCF version confirmed along with its NSX and vCenter baselines
• Minimum destination vSphere build for RAV to VMFS6 datastores verified, since it is the destination floor rather than the source ceiling that catches people out
• Virtual machines below hardware version 9 identified and a remediation window scheduled, as this needs a reboot
• Fault Tolerance, multi-writer disks, shared SCSI bus and shared VMDK configurations flagged and assigned an alternative mechanism
• Independent Persistent and Non-Persistent disks, virtual NVMe controllers, attached ISOs and serial port devices identified and resolved or reassigned
• Infrastructure appliances such as vCenter and NSX Manager confirmed as out of migration scope and handled through rebuild instead

Licensing and Access

Short section, disproportionately common as a cause of delay, because every item on it involves somebody outside the infrastructure team.

• HCX Enterprise entitlement confirmed at both source and destination if RAV is in the plan, since Advanced does not unlock it
• Destination VCF environment licensed and the licence applied, not merely purchased
• Dedicated service accounts created at both sites with the correct vCenter and NSX role assignments
• Service account credentials stored somewhere the team can retrieve them at three in the morning without waking anyone
• Outbound access to the activation endpoint confirmed, including proxy configuration where internet access is restricted
• Certificate trust established between sites, since self-signed or internally issued certificates on the destination are a common cause of pairing failure

Network Readiness

The largest section, and the one that most often sits blocked in somebody else’s change queue. Start it in week one regardless of how far away the migration feels.

• Firewall change raised covering every port required, submitted early enough to clear normal change lead times
• TCP 443 confirmed between HCX Manager and vCenter, NSX and ESXi at both sites, and for site pairing
• UDP 500 and UDP 4500 confirmed between the Interconnect and Network Extension uplink interfaces across sites
• Replication and vMotion paths confirmed reachable, including from the appliance addresses rather than only from an administrative workstation
• Forward and reverse DNS confirmed resolving correctly from the appliances themselves at both sites
• NTP configured and time synchronised across both environments, since certificate and pairing failures frequently trace back to clock drift
• MTU validated end to end across the actual uplink path with a real test, allowing at least 1600 bytes where Network Extension is in scope
• Sustained throughput baselined using HCX Transport Analytics rather than taken from the circuit rating
• Bandwidth headroom confirmed at a minimum of 100 Mbps per concurrent vMotion and 150 Mbps for RAV, with awareness that these are functional floors rather than schedule targets
• Distributed switch versions on the source checked against Network Extension requirements, with any upgrade sequenced before the build

Storage and Capacity

Storage problems tend to appear as throughput problems, which sends people to investigate the network. Confirm the storage position first so you can rule it out.

• Destination datastore capacity confirmed against the incoming workload profile, with headroom for growth during the migration period
• Destination IOPS headroom confirmed, particularly on vSAN backed workload domains during concurrent replication
• Source ESXi host CPU, memory and storage read performance assessed, since these govern achievable concurrency more often than the network does
• Storage policies defined on the destination and mapped to source protection levels, so workloads do not silently land on a weaker policy
• Appliance capacity reserved on both sides for the HCX managers, Interconnect, Network Extension and any WAN Optimization appliances
• Full CPU and memory reservations applied to the Interconnect and WAN Optimization appliances, so migration throughput does not compete for scheduler time

HCX Build and Validation

The build itself is quick when the preceding sections have passed. These checks confirm that it is actually working rather than merely deployed.

• HCX Manager deployed and activated at both sites, with vCenter and NSX registered against the correct instances
• Site pairing established and showing healthy from both directions rather than only from the source
• Compute profiles created at both sites with only the services you have licensed and intend to use enabled
• Network profiles created with IP pools sized for at least double the appliances you currently plan to deploy
• Service Mesh deployed and all tunnels showing up at both sites
• Transport Analytics reporting sensible throughput figures consistent with the earlier baseline
• Interconnect appliance scale-out designed against the approximate 2 Gbps per appliance ceiling, with anti-affinity rules applied so appliances do not land on the same host
• A single disposable test workload migrated end to end successfully, validating pairing, tunnels, replication path, vMotion path and destination mappings

Wave Planning

Waves grouped by hostname prefix are faster to build and much worse to run. Group by application, because that is the unit the business will judge the migration by.

• Mobility groups defined by application rather than by cluster or naming convention
• Migration mechanism assigned per group based on downtime tolerance rather than applied uniformly across the estate
• Wave sequence ordered so the earliest waves are low risk, letting the team build confidence on workloads nobody will escalate about
• Change windows booked for every planned wave, against the number actually available per month rather than the number theoretically possible
• Rollback trigger and procedure written for each wave, defining what constitutes failure and who has authority to call it

Cutover Window

Four checks, all of which need to be true before the window opens rather than during it.

• Maintenance window sized against the cumulative serial switchover time for the whole batch, not the largest single workload, since switchover is serial even when replication was parallel
• Backup team informed that Change Block Tracking is disabled during the RAV workflow, with the coverage gap explicitly accepted for the duration
• Switchover options agreed as policy in advance, including MAC address retention and whether hardware and tools upgrades happen during the move or afterwards
• Application owner available during the window and briefed on what validation they need to perform

Post-Migration Validation

Infrastructure green is not the same as application green. A wave is not complete until somebody who owns the application has said so.

• Guest operating system running, reachable on the expected address and resolving DNS correctly
• VMware Tools running and reporting the correct address to vCenter
• Storage policy on the destination confirmed as the intended one rather than the default
• Application owner smoke test completed and confirmed in writing
• Backup job picked up the workload at its new location and completed at least one successful run
• Monitoring and alerting re-pointed, with the source object removed rather than left generating alerts nobody reads
• Performance compared against the pre-migration baseline, since a workload that is running but slower is a finding rather than a success

Decommissioning

The section most likely to be cut when a project runs late, and the reason so many estates carry stretched segments and orphaned appliances years afterwards. It has an order, and doing it out of order will drop connectivity for workloads that have already moved.

• Every workload on an extended segment confirmed as moved and validated by its owner before the segment is touched
• Network Extension segments un-extended and routing normalised on the destination side
• Service Mesh deleted, removing the Interconnect, Network Extension and WAN Optimization appliances at both sites
• Compute and network profiles removed and IP addresses released back to the pool
• Site pairing broken and the HCX Connector decommissioned on the legacy side
• As-built documentation produced and handed to whoever operates the platform, covering what moved, when, and by which mechanism

Scaling the Checklist to Your Estate

Seventy items is proportionate for an estate of several hundred workloads across multiple clusters. It is not proportionate for everything, and applying it uniformly regardless of size produces a lot of ticking without much thinking. Three rough profiles cover most situations.

Under a hundred workloads, single vCenter

Roughly forty of the seventy items apply directly. The sections that collapse are appliance scale-out and placement, since a single Interconnect appliance will comfortably carry the estate, and much of wave planning, since the whole migration may fit into three or four waves. What does not collapse is discovery, eligibility, network readiness and validation. A fifty workload estate with one unmapped application dependency has exactly the same problem as a five hundred workload one, and it is proportionally more disruptive because there are fewer waves to absorb it.

Two hundred to eight hundred workloads, several clusters

The profile this checklist was written for. All seventy items apply and the scale-out, placement and wave planning sections earn their place. Expect the discovery and eligibility work to take between three and ten days, and expect the network readiness section to be the one that determines your start date, because firewall changes cross an organisational boundary.

Over a thousand workloads, multiple sites

Seventy items is a floor rather than a ceiling. At this scale the additions are mostly about parallelism and coordination: multiple Service Meshes with a deliberate placement strategy, concurrency management across simultaneous waves, more rigorous per-wave change control, and a communications plan that treats application owner engagement as a workstream rather than a task. The technical checks stay the same; the coordination around them becomes the harder problem.

Whatever the size, resist the temptation to shorten discovery. It is the only section where the effort saved is reliably paid back later at a worse rate, and it is the section that determines whether the remaining sixty items are being applied to the estate you actually have.

How This Maps to Your Project Plan

The checklist is not a single exercise completed at the start. It maps onto the project as a series of gates, each of which should be passed before the next phase begins. Treating it as a document to be completed once, at the beginning, is how items get answered optimistically.

Sections	When	Gate it protects
Discovery, compatibility, licensing	Before the design is written	Prevents designing against an estate that does not exist as documented
Network, storage and capacity	Before the build starts	Prevents deploying appliances into an environment that cannot carry them
HCX build and validation	Before the first production wave	Prevents discovering platform faults with real workloads
Wave planning	Before dates are committed to owners	Prevents a schedule the business cannot actually absorb
Cutover window	Before each wave opens	Prevents overrunning maintenance windows
Post-migration validation	Before each wave is closed	Prevents accumulating waves that are nearly finished
Decommissioning	Before the project is closed	Prevents stretched segments and orphaned appliances surviving for years

The most valuable of these gates is the third. A single disposable workload migrated end to end, with full validation, costs an hour and proves the entire chain: pairing, profiles, tunnels, replication path, vMotion path, destination mappings, storage policy and the validation process itself. Teams under deadline pressure skip it more often than any other item on this list, and it is the one item that would have caught the problem they then spend two days diagnosing.

What Evidence to Keep

A tick in a box is worth very little six months later when somebody asks what the state of the environment was before the migration. Keep the artefact rather than the confirmation, particularly for the items below, because these are the ones that get questioned afterwards.

• Pre-migration inventory export. Timestamped, from every vCenter. This is the reference point for every reconciliation question that arises later, and it is impossible to reconstruct once the source has been decommissioned.
• Eligibility findings and remediation record. What was found, what was done about it, and who approved each remediation. This becomes the answer to why a particular workload moved by a particular mechanism.
• Throughput baseline. The measured figure, the date and the conditions. When a wave later runs slower than expected, the baseline is what tells you whether something has changed or whether the expectation was always wrong.
• Pilot migration record. The end to end test, including timings. This becomes the estimate that all subsequent wave planning is based on.
• Per-wave completion record. Which workloads, which mechanism, when, and the application owner sign-off. This is the audit trail and it is also what tells you which wave to look at when a problem surfaces a fortnight later.
• Pre-migration performance baselines. Captured per significant workload. Without them, any post-migration performance complaint is unanswerable, because nobody can establish what normal looked like beforehand.
• Decommissioning record. What was removed, when and by whom, particularly for extended segments. This is what allows the source environment to be switched off with confidence rather than left running indefinitely because nobody is certain.

Reading Your Results

The value of a checklist is not the ticks, it is the pattern of what is missing. Three patterns come up repeatedly and each points at a different problem.

• Gaps concentrated in discovery. The estate is less well understood than the team believes. This is the cheapest problem to fix and the most expensive to ignore, because everything downstream is planned against assumptions that have not been tested.
• Gaps concentrated in network readiness. Usually an organisational issue rather than a technical one. The information exists but it sits with a team that has not been engaged. Fix it by starting the conversation, not by researching harder.
• Gaps concentrated in validation and decommissioning. The plan covers getting workloads to the destination and stops there. This produces migrations that are technically complete and operationally unfinished, and it is the pattern that leaves stretched segments in place for years.

A first pass with eight to twenty unanswered items is normal for a mid-sized estate. A first pass with two is usually a sign that the checklist has been read rather than worked through.

The Checks That Get Skipped Most

The MTU test. Everyone reads the switch configuration and almost nobody tests the actual path. The single hop that silently fragments will not appear in any configuration file, and it will present as an inexplicable throughput problem three weeks later.

The throughput baseline. A circuit rated at 1 Gbps rarely sustains 1 Gbps under real replication load once overhead, encryption and existing production traffic are accounted for. Measure it before wave dates are published.

Anti-affinity on scaled-out appliances. Deploying four Interconnect appliances and letting placement happen automatically gives you the cost of parallelism and very little of the throughput.

The serial switchover calculation. Replication is parallel, switchover is not. A wave of two hundred workloads does not switch over in the time it takes to switch over one, and maintenance windows sized on the wrong assumption overrun predictably.

The written rollback trigger. Every team believes they would know when to abandon a wave. Deciding it at two in the morning under pressure produces worse decisions than deciding it in a planning meeting the week before.

The application owner sign-off. Infrastructure can confirm a workload is running. Only the owner can confirm it is working, and the gap between those two states is where migration escalations come from.

Frequently Asked Questions

How long does it take to work through this checklist?

The discovery, compatibility and network sections typically take three to ten days of effort on a mid-sized estate, and they can run in parallel with commercial discussions. The remaining sections are gates within the project rather than a separate exercise.

Which checks are non-negotiable?

The eligibility audit, the MTU and throughput validation, the end to end test migration, and the written rollback procedure. Those four catch the failures that are most expensive to discover late, and none of them takes long.

Can we skip sections for a small estate?

Some items collapse on a simple estate, particularly around scale-out and appliance placement. Discovery, eligibility and validation do not scale down, because a fifty workload estate with one unmapped dependency has the same problem as a five hundred workload one.

What if we are already mid-migration?

Work backwards from the section you are in and check the earlier ones anyway. Problems found mid-project usually trace to a discovery or compatibility item that was skipped, and finding it now is better than finding it in the next wave.

Do these checks apply if we are not using HCX?

Most of them do. Discovery, dependency mapping, network readiness, storage capacity, wave planning, validation and decommissioning are common to any workload migration. The build and eligibility sections are HCX specific.

Who should own the checklist?

One named person, with sections delegated to network, storage, backup and application teams. Checklists owned collectively tend to be completed optimistically, because nobody is accountable for the item that turns out to be wrong.

Can Consult Circle run this for us?

Yes. Our discovery engagements work through the first five sections and produce a findings report with a remediation plan attached. It is a small, self-contained piece of work and the output is yours regardless of who delivers the migration afterwards.

Where Consult Circle Fits

This checklist reflects how we run these projects rather than being a condensed version of the documentation. The items on it are the ones that have cost somebody a change window, which is why several of them look trivial and none of them are.

We run the first five sections as a discovery engagement producing a findings report and a remediation plan, and we run the full lifecycle from audit through execution to decommissioning where that is what is needed. If your team is running the migration and wants the plan reviewed before execution starts, we do that as a standalone piece of work too.

Related Guides in This Series

• VMware Migration Services: How to Scope, Price and Run a VCF Move
• How to Migrate to VCF Using HCX: A Step by Step Walkthrough from Site Pairing to Cutover
• vSphere to VCF Migration and Upgrade Paths: In-Place, Side-by-Side or Greenfield
• VCF Migration Services for vSphere 7 and 8 Estates: What Changes After End of Support
• VMware HCX Migration Problems and How to Fix Them: Service Mesh, Network Extension and Failed Transfers
• VMware Cloud Foundation 5.x vs VCF 9.x: Key Differences, Architecture Changes and Upgrade Considerations
• Migrating from Legacy vSphere to VMware Cloud Foundation (VCF) Using HCX