Moving from vSphere to Azure: The Pre-Flight Check

Migration tools work fine until they don't. The network is usually the problem. This pre-flight checklist exists to prove the path before you schedule a vSphere-to-Azure cutover.

Outcome: Pre-flight checklist proves network readiness, data fit, and dependency mapping before any cutover attempt.

Pre-flight means proving the path

You are not just moving compute. You are moving an application's dependency chain through a new network boundary. If the path is not measured, the timeline is fiction.

The pre-flight checklist

1. Baseline latency, jitter, and throughput. Measure round-trip latency and sustained throughput between the source cluster and the Azure landing zone.
2. Data transfer math. Calculate the data volume, change rate, and the cutover window. If the numbers do not fit, plan a seeded transfer and a delta sync.
3. Dependency map (inbound and outbound). Inventory services, ports, DNS names, and IP ranges the workloads touch.
4. IP, routing, and firewall rules. Check for address overlap, NAT requirements, and route propagation. Confirm firewall rules with a test flow, not a screenshot.
5. Identity and DNS cutover logic. Document where identity lives (AD or Entra), which DNS zones are authoritative, and the TTL strategy.
6. Rollback plan (the "revert" button is a lie). Define the point of no return, data divergence handling, and the exact steps to go back. Test rollback in a staging window.
7. Application validation steps. Define the exact smoke tests that prove the workload is healthy. Assign an owner and capture pass/fail criteria.
8. Evidence pack. Capture diagrams, test results, and the runbook in one place.

Stop and fix before cutover

• Latency variance is unstable or packet loss appears under load.
• Any dependency is still "maybe" or "we think."
• Rollback steps are incomplete or untested.

Stability PrincipleCutover is a test of the network, not the tool. If the path is not measured, the cutover plan is a guess.