How a VCF Migration Engagement Actually Runs

Discovery & Dependency Mapping

Before any design work starts, we build a complete inventory of the source environment: compute clusters, datastore layout and utilization, VLANs and routing, firewall rules, and existing backup and DR posture. In parallel, we map application dependencies — which VMs communicate with which, on what ports, and which groups of workloads must migrate together to avoid breaking a running application mid-wave.

This is also where we identify migration constraints: workloads that cannot tolerate any downtime versus those that can absorb a scheduled outage, VMs with hardware version or OS compatibility issues that need remediation before migration, and any environments already running degraded or out of vendor support.

Target VCF Design

We size the management domain and workload domain(s) based on the discovered capacity, growth headroom, and fault-domain requirements — how many hosts per cluster, vSAN or external storage policy, and whether workloads are separated into multiple workload domains for compliance or performance isolation. Design decisions here are driven by the discovery data, not a generic template.

NSX Network Extension

Before workloads move, we extend the source Layer 2 networks into the target VCF environment using NSX and HCX Network Extension. This lets migrated VMs keep their existing IP address and MAC address after cutover, which avoids a re-IP exercise and the application reconfiguration, firewall rule updates, and DNS changes that come with it. Network extension is validated and stable before any workload migration begins — it is a prerequisite, not a parallel task.

HCX Migration: Bulk vs. vMotion

HCX supports several migration mechanisms, and we select per workload rather than defaulting to one method for the whole environment:

• Bulk Migration — replication-based, with a scheduled cutover and brief downtime window. Used for the majority of standard workloads, especially where migrating in larger batches matters more than zero downtime.
• HCX vMotion — live migration with no downtime, for workloads that cannot tolerate any interruption. This requires sufficient bandwidth and acceptable latency between source and target, so it's reserved for VMs where that trade-off is justified and the network path supports it.

The selection criteria come down to the workload's tolerance for downtime (RTO), the available bandwidth and latency between sites, VM size and change rate, and whether the application is sensitive to brief network interruption during cutover.

Maintenance-Window Planning

Migration waves are scheduled against maintenance windows approved by the client's application owners and business stakeholders, not against our own convenience. Each wave is sized to fit inside its window with margin for validation, and waves are sequenced so that dependent applications land in the same window or in the correct order.

Per-Wave Validation

After each wave, we validate before declaring it complete: network connectivity and routing from the new location, application-level functional checks with the application owner, and a performance comparison against the pre-migration baseline captured during discovery. A wave is only signed off once these checks pass — we don't move to the next wave on an unverified one.

Rollback Planning

Every wave has a defined rollback path decided before cutover, not improvised after something goes wrong. For bulk migrations, the source VM remains intact and available until the wave is validated, so rollback means reactivating the source and reverting network extension routing. The rollback decision point and who has authority to call it are agreed with the client in advance.

Post-Migration Operational Handover

Once all waves are complete and network extension is decommissioned, we hand over updated documentation — network diagrams, host and cluster layout, storage policies, and runbooks reflecting the as-built environment — along with a knowledge-transfer session for the client's operations team. Ongoing operational support is available as a separate engagement where needed.