Before the first VM moves, the business objective, destination, migration approach, and acceptable risk must be clear.
Tooling matters, but it cannot correct an unclear objective, unknown dependencies, or recovery objectives that have not been agreed.
An inventory shows servers. A migration plan must show applications, owners, dependencies, business criticality, data flows, security requirements, and cutover constraints. The planning unit is not always the VM; it is the business service.
Each decision should produce a specific, testable deliverable before the pilot wave is approved.
Determine whether the primary driver is cost, hardware lifecycle, licensing, resilience, security, cloud adoption, datacenter exit, or modernization. Without an agreed outcome, technical options cannot be evaluated objectively.
The target may be Azure IaaS, Azure VMware Solution, Azure Local, Windows Server Hyper-V, or modernization to PaaS. The choice should align with compatibility, skills, latency, compliance, cost, and the desired operating model.
Identify application dependencies, database connections, identity flows, DNS, file shares, firewall rules, certificates, scheduled jobs, and integrations. Build migration groups around dependencies, not arbitrary VM lists.
Agree RTO and RPO per application, not only per VM. Decide IP retention or re-IP, VLAN mapping, routing, DNS, firewalls, bandwidth, and the resilience pattern for the target platform.
Define the pilot, production waves, migration window, change freeze, test migration, validation owners, monitoring, backup, rollback trigger, and hypercare. Every wave needs explicit go/no-go and completion criteria.
This is a decision aid, not an automatic recommendation. The final choice requires workload-level assessment.
For workloads that can move to or modernize on Azure services.
For VMware workloads that need limited initial platform change.
For Azure-connected infrastructure in customer-managed locations.
For on-premises virtualization when it fits the requirements and operating model.
The pilot should test the real assumptions behind the architecture and operating model.
Start with low-risk workloads, validate the assumptions, and scale through a repeatable runbook.