Home/Migration Timeline
Migration timeline

VMware migration timeline: what to expect.

A well-run mid-market migration takes 3–9 months from kickoff to decommission. Here's each phase, how long it typically takes, and where schedules actually slip.

Renewal inside 6 months? A full replatform (Nutanix, Proxmox, Hyper-V) takes 3–9 months for mid-market environments. If you're already inside that window, a managed VMware bridge or a short-term renewal buys time without forcing a rushed migration. Start the assessment now regardless: the earlier you lock a target, the more negotiating leverage you keep.

The single most common planning mistake is working backward from a renewal date with no margin. If your VMware contract expires in December, a migration that starts in September will fail, or you'll end up paying a bridge renewal at exactly the moment you have zero leverage. Map the phases below against your real calendar before you commit to a date.

Quick read: Discovery 2–4 weeks → design 2–6 weeks → pilot 2–4 weeks → production waves (the long middle) → cutover → decommission. Typical totals: ~3–4 months for 25–100 VMs, 4–9 months for 100–500 VMs, 9–18 months for 500+ or container replatforms. Moves to managed VMware clouds run shortest because nothing is converted.

The six phases

1

Discovery & assessment · 2–4 weeks

You can't migrate what you can't see. This phase builds the source-of-truth inventory and surfaces the surprises early, while they're cheap.

  • Full VM inventory: vCPU, RAM, storage, OS, owner
  • Application dependency mapping
  • Licensing audit and renewal-date confirmation
  • RTO/RPO and compliance requirements
  • Platform shortlisting (2–3 candidates)
  • Budget band established (cost guide)
2

Design & platform selection · 2–6 weeks

Decisions get locked here: target platform, architecture, network design, and the wave plan. Shorter for managed-VMware targets, longer when hardware must be specced and ordered.

  • Final platform decision (compare options or the top migration solutions guide)
  • Target architecture, sizing, and network/IP plan
  • Storage and backup/DR design
  • Migration tooling selection (HCX, Move, etc.)
  • Wave groupings and go/no-go criteria
  • Hardware ordered (lead times: 4–12 weeks)
3

Pilot · 2–4 weeks

Move a representative, low-risk slice, typically 5–10% of VMs, and validate the whole chain: tooling, runbook, performance, backup, rollback. The pilot exists to be wrong cheaply.

  • Build target environment and connectivity
  • Migrate dev/test and one tolerant prod workload
  • Validate performance against baselines
  • Test backup, restore, and rollback end to end
  • Time the runbook, this calibrates the wave schedule
  • Go/no-go review with stakeholders
4

Production waves · 4–16 weeks

The long middle. VMs move in dependency-grouped waves, usually 2–6 of them, lowest risk first, with validation gates between waves. This phase scales with VM count and downtime windows, not effort.

  • Wave 1: remaining non-prod and tolerant workloads
  • Middle waves: standard production by app group
  • Final wave: crown jewels (ERP, databases)
  • App-owner validation gate after every wave
  • Rollback plan kept live until each gate passes
  • Status comms at every milestone
5

Cutover & stabilization · 1–3 weeks

Final DNS/IP cutovers, the last replication sync, and a hypercare window while the environment settles. Most "migration failures" are actually skipped stabilization.

  • Final cutover runbook executed (checklist)
  • Performance baselines compared pre/post
  • Backup jobs live on the new platform
  • DR failover tested end to end
  • Hypercare: daily checks, fast-path escalation
6

Decommission · 1–2 weeks (after a 2–4 week hold)

Only after every validation gate has passed: power down the old cluster, terminate licensing, and reclaim the budget line. Keep a final cold backup of the source environment regardless.

  • Source hosts powered down after agreed hold period
  • VMware subscription/SnS termination notice sent
  • Hardware redeployed, sold, or recycled
  • Documentation and runbooks finalized
  • Lessons-learned review and TCO actuals captured

Typical total duration by environment size

EnvironmentReplatform (Nutanix/Proxmox/Hyper-V)Managed VMware / hyperscaler VMwareOpenShift / containerization
25–100 VMs3–5 months6–12 weeks6–12 months
100–500 VMs4–9 months2–5 months9–18 months
500–2,000 VMs9–18 months4–9 months18+ months

These are typical ranges for reasonably run projects with engaged app owners. VMware-to-VMware moves run shortest because VMs are replicated, not converted.

Where schedules actually slip

  • App-owner availability. Validation gates wait on people, not technology. Book the sign-off calendar in phase 1.
  • Hardware lead times. HCI nodes and switches can take 4–12 weeks; order during design, not after.
  • The undiscovered dependency. The fax server nobody documented that talks to the ERP. Dependency mapping in discovery is what catches it.
  • Change freezes. Retail Q4, fiscal year-end, audit windows, block them out before building the wave schedule. Sector-specific constraints are covered in the financial services and government guidance.
  • Renewal collision. Start at least 6–9 months before your VMware expiry so you're never forced into a panic renewal. If you're inside that window now, a managed provider bridge or short-term renewal may be part of the plan.

Want this mapped to your actual renewal date and VM count? A free assessment produces a dated plan, and the calculator pairs it with cost in minutes.

Work backward from your renewal date

Get a dated migration plan built for your environment.

Tell us your VM count and renewal date. A vendor-neutral advisor maps the phases, the providers, and the price, free.