Azure VMware Solution is a legitimate VMware exit bridge. It needs a defined exit of its own.
Azure VMware Solution moves VMware workloads into Azure data centres on dedicated bare-metal hosts with minimal change to the VM layer, IP addressing and management tooling. That can make AVS the fastest path out of a data centre, hosting contract or VMware renewal deadline when re-platforming is not feasible in the available window. It is also a premium, scenario-specific solution with a three-node minimum cost floor and a separate Broadcom portable VMware Cloud Foundation subscription requirement — which makes indefinite use commercially difficult to justify unless the workload case genuinely supports it.
See where the AVS case holds and where it failsWhat AVS actually is and is not; how ExpressRoute and HCX handle connectivity and migration; the three-layer cost structure behind the hard cost floor; the staging post model and why Phase 2 matters; the responsibility split after cutover; when AVS is the right bridge; the conditions where the case does not hold; and how AVS compares with temporary renewal, Azure Local, Nutanix and direct Azure migration. Inlight IT assesses AVS as part of VMware exit and infrastructure refresh work. The right question is not whether AVS is capable — it is whether AVS is the right Phase 1 for this estate, and whether there is a credible Phase 2 planned before the cost floor becomes the long-term operating model.
AVS is a transition tool, not a target architecture by default.
AVS is strongest when the clock is running and re-platforming is not realistic in the available window. For data centre exits, VMware renewal pressure, complex legacy networking or MAC-tied licensing constraints, AVS can remove immediate risk with less workload disruption than a direct platform change. That is the benefit.
The trade-off is that AVS can become expensive and strategically awkward if it becomes the long-term destination by default. The organisations that use AVS well are usually not the ones that treat it as “VMware in Azure forever” — they are the ones that define Phase 2 before committing to Phase 1.
Phase 2 may mean:
- moving some workloads to Azure-native services
- moving some to Azure VMs
- moving some back to modern local HCI
- retaining selected workloads in AVS because the case genuinely supports it
- retiring and replacing workloads that should not be carried forward
Speed of exit is the benefit. A premium cost floor with a defined Phase 2 exit is the trade-off.
AVS runs VMware on dedicated Azure bare metal. It is not VMware inside an Azure VM.
Azure VMware Solution is a Microsoft-managed service that provisions a full VMware Software-Defined Data Centre stack — vSphere, vCenter Server, vSAN and NSX — on dedicated bare-metal hosts inside Azure data centres. The hosts are hardware-tested and securely erased before use. Clusters scale from three to sixteen ESXi hosts, and each private cloud receives its own isolated infrastructure.
The point that matters most for buyers coming from on-premises VMware: AVS runs VMware directly on dedicated Azure hardware. It is not nested VMware inside Azure virtual machines. That distinction changes performance expectations, support boundaries, cost structure, migration method, networking design and operational responsibility after cutover.
AVS connects through ExpressRoute. HCX is the recommended migration path.
AVS can be accessed from on-premises environments and Azure resources through ExpressRoute, VPN or Azure Virtual WAN. For on-premises to AVS connectivity, ExpressRoute Global Reach is usually the key pattern: it connects on-premises environments to AVS private clouds through the Microsoft edge without routing through an Azure Virtual Network gateway. That matters because an ExpressRoute gateway in a VNet cannot provide transitive routing between two attached ExpressRoute circuits — Global Reach is used to solve that connectivity pattern.
For VM migration, Microsoft recommends VMware HCX as the fully supported method — with Service Mesh connectivity and Layer 2 Network Extension. HCX supports:
- Cold Migration
- HCX vMotion
- Bulk Migration
- Replication Assisted vMotion
- OS Assisted Migration
- Layer 2 Network Extension
AVS has a hard cost floor. It requires planning to remain commercially justifiable.
The cost structure has three layers that need to be understood before any commercial comparison is credible.
The minimum initial deployment is three dedicated hosts, regardless of workload size. Clusters can scale to sixteen hosts, but the three-host minimum exists whether the business needs three hosts or only enough capacity for a smaller estate. For smaller VMware environments, that dedicated-host cost floor is a structural issue that direct Azure IaaS does not have.
AVS now requires a portable VMware Cloud Foundation subscription from Broadcom, brought separately. Microsoft installs, patches and maintains VCF as part of the AVS managed service after the subscription is registered. The AVS infrastructure charge and the Broadcom VCF subscription are billed separately, and some VMware add-ons may also need to be pre-purchased from Broadcom. Buyers who model only the AVS infrastructure charge will underestimate the total cost.
Azure Hybrid Benefit can apply existing Windows Server and SQL Server licences in AVS. For SQL Server, licences apply at the host level and must cover all physical cores on a host, not just the VMs running SQL. Placement policies can constrain SQL workloads to specific hosts to control licensing scope, but host replacement behaviour and compliance need to be accounted for in the design.
AVS works best as a deliberate Phase 1 with a defined Phase 2 exit.
The strongest AVS strategies are not migration-only projects — they use AVS to solve an immediate timing problem, then use the stability window to make better workload decisions.
- Move workloads with minimal change into a stable VMware environment inside Azure
- Resolve the immediate data centre pressure or hosting exit
- Clear the renewal event or hardware constraint
- Refactor suitable workloads to Azure PaaS
- Re-platform suitable workloads to Azure IaaS
- Move some to SaaS
- Repatriate selected workloads to on-premises HCI where that is the right fit
- Retain only the workloads that genuinely justify AVS long-term
- Retire or replace systems that should not be carried forward
Without a Phase 2 plan, AVS can become a high-cost steady state. The three-node minimum, dedicated host pricing and separate Broadcom VCF subscription do not become easier to justify just because the migration succeeded. How Phase 2 movement is staged — waves, coexistence and rollback — is covered in hybrid infrastructure workload migration.
Microsoft owns the host layer. You own the workload layer and the policy layer.
AVS reduces infrastructure management responsibility — it does not remove operational responsibility for the environment running on top of it. The split between Microsoft's responsibility and the customer or MSP responsibility is clearer than in many managed infrastructure models, but it needs to be understood before go-live.
- The AVS service infrastructure
- The dedicated host and platform layer
- VCF installation, patching and maintenance once the subscription is registered
- Virtual machines and guest operating systems
- Applications
- Identity and access
- NSX configuration and network policies
- Firewall and segmentation rules
- Backup and restore design
- Monitoring and alerting
- Security posture
- Guest patching
- Incident response
- Cost review
- Documentation and escalation
The VMware toolchain remains in play after cutover. The organisation still manages vSphere and NSX resources through vCenter Server and NSX Manager; the Azure portal is involved for deployment and some management operations, but AVS does not remove the need for VMware operational expertise. AVS can reduce host-layer management burden — it does not make the VMware environment operationally self-managing.
When AVS is the right bridge.
AVS is strongest where speed, continuity and low-change migration matter more than immediate platform simplification — usually when the business has a hard deadline and cannot safely redesign or re-platform workloads before it. AVS can be a strong fit when:
- A data centre lease expiry creates a fixed deadline
- A hosting contract needs to be exited
- VMware renewal pressure is forcing a decision
- Hardware lifecycle pressure is urgent
- Legacy applications have complex networking dependencies
- IP and MAC continuity materially reduces migration risk
- Application refactoring is not feasible in the available window
- MAC-tied licensing makes like-for-like VMware continuation a hard requirement
- Business-critical workloads need a lower-change migration path
- The business needs VMware continuity while Phase 2 is prepared
The conditions where the AVS case does not hold.
AVS is a premium, scenario-specific solution. The cases that fail are often not technical failures — they are fit mismatches that should have been identified before commitment.
A small VMware estate may not justify the three-node minimum and dedicated host cost floor. If the workloads can move directly to Azure IaaS, Azure-native services, SaaS or a modern local HCI platform, AVS may be overkill.
AVS is strongest as a staging post. With no defined plan to reduce, modernise, repatriate or selectively retain workloads after Phase 1, the business risks turning a bridge into a permanent premium platform.
AVS depends on a separate portable VCF subscription from Broadcom. If procurement, licensing or commercial management around that subscription is not workable, the AVS case weakens.
If the business has enough time to move workloads to Azure-native services, Azure VMs, SaaS or local HCI without excessive risk, AVS may only carry VMware technical debt forward.
If nobody owns NSX, vSphere operations, backup, recovery, guest patching, monitoring, routing, cost review and Phase 2 planning after cutover, AVS will not solve the operating problem — it will simply move it.
AVS should be compared against the actual options, not treated as the default.
When AVS enters the conversation, it usually sits beside several other paths, and it should be compared against the actual options rather than treated as the default low-change answer.
A temporary renewal may be stronger when the estate is stable, migration risk is high and there is no hard data centre or hosting deadline. AVS may be stronger when the business must exit a physical environment or hosting arrangement before a full redesign is possible. See Broadcom VMware renewal.
Azure Local may be stronger where workloads still need to run locally, the business is Microsoft-aligned, and a modern HCI platform can be built before the renewal or refresh deadline. AVS may be stronger where the business must move quickly without re-platforming and needs VMware continuity in Azure as a bridge. See Azure Local HCI, and VMware vs Azure Local for the direct platform comparison.
Nutanix may be stronger where the business wants mature HCI or private cloud operations on local infrastructure. AVS may be stronger when the immediate need is a cloud-hosted VMware environment under time pressure. See Nutanix AHV — and where a lower-cost open-source alternative is also on the table, Proxmox VE has its own fit profile.
Direct migration may be stronger where workloads are ready to move to Azure VMs, PaaS, SaaS or Microsoft 365. AVS may be stronger where redesign, re-addressing or dependency changes cannot happen safely in time. See Azure migration strategy.
The useful comparison is not “which platform is best?” It is “which option removes the immediate constraint without creating a worse long-term position?”
Where AVS lands in VMware exit assessments.
In VMware exit assessments for Australian organisations, AVS appears as the right Phase 1 path in specific scenarios:
- A data centre lease expiry creates a hard deadline
- A hosting exit needs to happen before redesign is feasible
- Legacy application networking dependencies make re-addressing risky
- MAC-tied licensing makes like-for-like VMware continuation a hard requirement
- Complex VMware dependencies need stability before deeper platform decisions are made
In those cases, AVS removes the immediate problem while a structured Phase 2 plan is developed alongside the migration. Where AVS does not usually appear in recommendations is where the footprint is small enough to go straight to Azure-native services, or where the team has enough time to re-platform properly.
We scope AVS engagements to include Phase 2. That is not standard practice, but it should be.
Most AVS engagements are scoped as migration projects. The migration is delivered, the Phase 2 question gets deferred, and two years later the organisation may still be paying for three dedicated hosts plus a Broadcom VCF subscription for workloads that could have moved to Azure-native services or on-premises HCI at a lower ongoing cost.
Our approach is different. Before an AVS engagement is scoped, we work through the Phase 2 exit: which workloads should eventually move to Azure-native services, which should re-platform to Azure IaaS, which should repatriate to on-premises HCI, which might genuinely stay in AVS long-term, which should be retired or replaced, what the commercial threshold is for remaining in AVS, and who owns the operating model while workloads remain there.
That analysis changes the AVS design — and sometimes it changes whether AVS is the right Phase 1 at all. If AVS is the right call, we recommend it and deliver the migration properly. If the scenario does not justify it, we say so before a commitment is made.
The right question is not whether AVS is capable. It is whether there is a credible Phase 2 planned before the cost floor becomes the long-term operating model.
If you can name the deadline forcing Phase 1 — the lease, the hosting exit, the renewal — but not what happens to each workload after it, the bridge has no far shore yet.
Test the bridge against a refresh plan →AVS usually raises the next decision. It rarely ends the strategy.
- If AVS is on the shortlist — the next step is a structured review of the estate: licensing exposure, HCX feasibility, connectivity design, Phase 2 options and commercial fit. See Infrastructure Refresh.
- If the broader VMware exit context needs resolving — the next step is usually a structured exit decision. See VMware exit strategy.
- If workload placement logic needs resolving — the next step is deciding what should stay local, move to cloud, bridge, or not be carried forward. See VMware workload placement.
- If AVS is not the right fit — the next step is usually comparing local HCI alternatives such as Azure Local and Nutanix. See Azure Local vs Nutanix.
- If some workloads are cloud-ready — the next step may be Managed Cloud and Migration or Azure migration strategy.
AVS questions we hear most.
Is AVS VMware running inside Azure VMs?
What is the minimum AVS deployment?
Does AVS require a separate Broadcom subscription?
Is AVS a good VMware exit strategy?
Is AVS cheaper than VMware on-premises?
When does AVS make sense?
When does AVS not make sense?
What is HCX used for?
Does AVS remove the need to manage VMware?
Where does AVS sit in Inlight IT's Cloud and Infrastructure structure?
If AVS is on the shortlist, validate the bridge before the cost floor.
Plan what comes after the bridge, not just the move onto it.
Talk through your infrastructure refresh options