VCF Migration Estimator

For a typical single-site estate of 1,000 VMs with 12-hour weeknight change windows, plan on roughly 18 to 24 weeks end to end. That covers assessment and dependency mapping, VCF design, platform build and HCX pairing, a pilot wave and three to five migration waves, then cutover and hypercare. Bandwidth, dependency data quality and change-window length move that number more than the VM count does.

With HCX Bulk migration we plan on about 400 VMs per full migration day per stream at a standard pace, rising to around 1,000 a day on compressed waves with multiple service meshes and clean dependency data. RAV runs slower at roughly 175 VMs a day because each VM is live-migrated, and pure vMotion is slower again at about 50.

HCX Bulk replicates a VM in the background and reboots it into the target at a scheduled switchover, which makes it the workhorse for volume. HCX vMotion moves one live VM at a time with no downtime but very little throughput. RAV - Replication Assisted vMotion - combines the two: bulk-style replication with a live switchover, which suits large or busy VMs like databases. More on our VMware HCX services.

We audit at roughly 250 VMs per consultant per working day at a standard pace, so a 2,000-VM estate is about eight days of audit plus site discovery, dependency mapping and constraint capture. In practice a full assessment for a mid-market estate lands between four and seven weeks elapsed, and it shortens materially if you already have current dependency mapping.

Wave count comes from how many VMs you can safely move in a week, not from the size of the estate alone. At a standard pace with 12-hour weeknight windows most estates land on waves of 300 to 400 VMs, so 2,400 VMs is around six waves plus a pilot. Slower change control means smaller, more numerous waves.

Usually not. HCX Network Extension stretches your existing Layer 2 segments to the target so VMs keep their addresses through the move, and you cut the gateway over once a segment is fully migrated. Where L2 extension isn't allowed, re-IP is possible but adds DNS, firewall and application change at every cutover - typically a 10% uplift on migration effort.

Replication runs during business hours in almost every project; it is the switchover that needs a window. HCX vMotion and RAV switchovers are short enough to run in the day for tolerant workloads, while Bulk switchovers involve a reboot and normally sit in an evening or weekend slot agreed with the application owner.

Four things, in order: no current application dependency mapping, a change window narrower than the plan assumed, bandwidth between source and target, and target hardware arriving late. Clustered applications, regulated workloads and legacy guest operating systems each add effort too, which is why the estimator applies a complexity uplift rather than a single flat rate.

Side-by-side gives you a clean, validated VCF platform and a per-VM rollback path, which is why most estates on vSphere 6.7 or 7 choose it. In-place conversion or VCF Import is faster and cheaper where hardware is modern and already on a supported version, but rollback is harder and the platform inherits existing configuration drift. Compare upgrade paths with our VCF upgrade service.

It is built on throughput rates from real VCF migrations we have delivered, and it is deliberately conservative on validation and slack. Expect it to be within about 20% of a scoped plan for a typical estate. It cannot see application constraints, approval cycles or the surprises that dependency mapping always finds, so treat it as a planning number, not a quote.

Inside one data centre bandwidth is rarely the constraint. Across sites it usually is: at 100 Mbps with 120 GB average VMs you can move roughly 30 VMs a night regardless of migration method, so the link - not HCX - sets your wave size. The estimator applies a bandwidth ceiling and flags it when your link is the binding constraint.

Yes, and it belongs in the plan from day one. Protection has to follow the workload, so backup agents, policies, proxies and replication targets are re-pointed wave by wave rather than after the fact. Where the DR platform itself is being replaced, we treat it as a workstream alongside the migration waves. See our BC/DR planning service.