Migrating VMware to Azure is a programme, not a weekend cutover. The workloads that should move first are the ones where Azure removes a real constraint: hardware refresh risk, a datacentre lease, a DR site you no longer want to staff, or an application that needs Azure services sitting next to it.
Lift-and-shift of a large, chatty three-tier app with on-premises SQL, file shares and printer mappings will work technically and disappoint commercially. You will pay for IaaS, bandwidth and the same operational toil, plus a new networking design. Those systems need a landing zone, a dependency freeze, and often an application change before the business case is honest.
Good early movers: relatively isolated application stacks, disaster-recovery replicas, development and test, file services that can become Azure Files or NetApp Files with a clear permission model, and anything already blocked on ageing hardware. Poor early movers: domain controllers without a thought-through identity plan, latency-sensitive manufacturing systems, and anything whose licence forbids the target SKU.
Azure Migrate, AVS and native IaaS are different tools. AVS can reduce rewrite pressure if you need VMware constructs in Azure for a defined period. Native IaaS is cheaper to operate long-term if you can live without those constructs. Pick the tool from the constraint, not from a vendor slide.
Before you migrate, freeze a minimum viable landing zone: identity, hub networking, DNS, backup, logging, and a subscription/management-group design someone will actually own. Teams that skip this step import VMware sprawl into Azure and call it transformation. It is just a more expensive datacentre.
All technical perspectives