Azure VMware Solution
We design and migrate VMware environments onto dedicated Azure infrastructure, with licensing, connectivity, recovery and ongoing operations planned together. Azure VMware Solution (AVS) can support an urgent data centre exit, a staged move to other Azure services or a longer-term VMware environment where the applications and operating costs justify it.
- VMware workloads
- Data centre or hosting deadline
- Application and network dependencies
- Dedicated Azure hosts
- VMware platform
- HCX migration
- Defined operating responsibilities
- Retain in AVS
- Move to Azure services or SaaS
- Return to local infrastructure
- Retire
VMware on dedicated Azure infrastructure
AVS provides a private cloud built from dedicated hosts in Azure data centres. It includes the VMware platform components vSphere, vCenter Server, vSAN and NSX. Microsoft operates the underlying service and platform, while your team or provider runs the workloads and their policies.
Applications continue to run in a VMware environment, using familiar management tools and virtual networking. That can reduce the changes needed during a data centre move. We still validate application support, connectivity, backup and access before treating the workload as ready to migrate.
What stays and what changes
AVS keeps the VMware platform and changes where it runs, so you stop running your own hosts but keep a VMware licensing and operating commitment.
Use AVS where VMware continuity has a clear value
A data centre or hosting deadline leaves little room to redesign
A lease expiry, hosting exit or hardware constraint may arrive before applications can be moved to another platform. AVS can separate the physical exit from the later application changes, provided host capacity, licences and connectivity can be secured in time.
The applications carry dependencies that are costly to change
Legacy networking, tightly coupled systems and specialist appliances can favour continued use of VMware. We check the application vendor's support position and test licences tied to MAC addresses or other virtual hardware identifiers, because moving to AVS doesn't by itself confirm those licences stay valid.
VMware remains part of the longer-term design
AVS can stay in service where its application compatibility, Azure location and Microsoft-managed infrastructure justify the cost. If it's an interim platform, we also price the later move. A small estate, a straightforward direct Azure migration or workloads that need to stay at the site can favour another route.
Design the network around the AVS deployment
AVS has two private cloud generations with different network attachment models. We establish the generation, host type, region and available capacity before committing the network or migration design.
Microsoft-managed ExpressRoute connectivity links the private cloud to Azure networking. ExpressRoute Global Reach is a common route between AVS and an on-premises ExpressRoute circuit. AV64 has specific expansion prerequisites.
The private cloud attaches directly to an Azure Virtual Network and supports direct deployment of an AV64 cluster. Microsoft lists Australia East and Australia Southeast among the supported regions; capacity and the required features still need confirming.
Routing and inspection through the migration
We design site connectivity, address ranges, DNS, return routes, firewall inspection and access to Azure services as one network. The chosen ExpressRoute or VPN path has to carry both the migration traffic and the applications that stay split between locations.
For Generation 1, connecting two ExpressRoute circuits to the same VNet gateway doesn't make the gateway route traffic between them; Global Reach or a supported transit design is needed for that path. For Generation 2, we check the current peering, routing, DNS and recovery-product limitations against the proposed architecture.
HCX migration and network extension
VMware HCX connects the source environment and AVS through a service mesh. We select the migration method around VM size, change rate, network conditions and permitted outage, then test it on representative workloads.
Layer 2 Network Extension can preserve IP addressing during migration. We also plan gateway placement, traffic between sites and when the extension will be removed, because applications that keep their address can still be affected by latency or a changed traffic path.
| HCX method | What it means for the migration |
|---|---|
| Cold Migration | The VM is powered off for the move. The outage needs to cover transfer and validation. |
| Bulk Migration | Data is replicated ahead of a scheduled switchover, with a shutdown and start at the destination. |
| HCX vMotion | Live migration for suitable workloads. Compatibility and network conditions decide feasibility. |
| Replication Assisted vMotion | Replication supports migration at greater scale, followed by a live switchover where supported. |
HCX also offers OS Assisted Migration for supported Hyper-V and KVM workloads, which is a separate conversion scenario. We confirm HCX versions and entitlements, test throughput and allow for the selected generation's current limitations. The cutover plan includes application checks, recovery and the point beyond which rollback needs data reconciliation.
Explore Cloud Migration and delivery →Price the whole environment and the time it will stay
We compare AVS with the actual renewal, local platform and direct Azure options over the same period. The model includes the initial move, parallel operation and any further migration, alongside the recurring platform cost.
Dedicated hosts set the minimum commitment
The minimum AVS cluster has three hosts, with up to 16 hosts per cluster, so a small workload count doesn't reduce the initial host requirement. We size compute, usable storage and spare capacity for the required availability and maintenance, then confirm the host quota and regional supply.
Pay-as-you-go and reservation choices affect the cost of a short stay or staged exit. We model when whole hosts can actually be removed, since moving a few VMs elsewhere may leave the host bill unchanged and a reservation or licence commitment may continue after capacity is released.
Portable VCF is a separate VMware subscription
New AVS deployments need a portable VMware Cloud Foundation subscription purchased from Broadcom. We match the entitlement to the deployed physical cores and register it for each private cloud, with Azure infrastructure charges and the VMware subscription kept as separate parts of the budget.
Add-ons are checked against the design too. NSX Distributed Firewall and Gateway Firewall features can need a separate vDefend entitlement, and scaling the environment needs a matching check of the registered cores and subscription term.
Windows Server and SQL Server licensing
Eligible Windows Server and SQL Server licences can be used in AVS through Azure Hybrid Benefit. We compare licensing individual VMs with qualifying host-level rights, based on the editions, Software Assurance and applicable Product Terms.
For SQL Server Enterprise unlimited virtualisation, the selected hosts need all physical cores covered, and VM-host placement policies can define those hosts. Per-VM licensing is also available where the terms allow.
Connectivity, recovery and operation stay in the budget
We include circuits and gateways, firewalls, additional storage, backup, disaster recovery, monitoring and applicable data-transfer charges, along with guest operating systems, applications and ongoing engineering. Running in Azure doesn't make these part of the AVS host charge.
Existing licence-included AVS deployments
Microsoft is retiring licence-included AVS in stages, with deadlines that depend on the SKU and any reservation, and a reservation that expires earlier loses its licence-included benefits at expiry. We check the deployed SKU and plan the move to portable VCF against its deadline. AVS itself is continuing.
Plan what happens after the first move
When AVS is the interim step, we include the next workload decisions in the initial scope. The plan names the systems, owners, dependencies and commercial commitments that set how long that step lasts.
Move the VMware workloads
Establish the AVS platform and network, migrate in agreed waves, validate the applications and put backup and monitoring into operation. The original site or hosting commitment closes only once the required services, data and recovery arrangements are accounted for.
Carry out the agreed workload changes
Suitable systems may move to Azure VMs, Azure platform services or SaaS. Others may return to local infrastructure, stay in AVS or be retired, sequenced around application projects and support dates with the cost of each further move included.
What can actually end at each wave
Hosts, network extensions, circuits, licences and old recovery infrastructure. If the remaining workloads justify continued AVS use, we document that operating and commercial decision.
An interim move carries a second delivery cost
When the business case relies on moving workloads again, it needs the people, budget and migration windows for that work. We include them before treating AVS as a short-term commitment.
Who looks after what once you're on AVS
We agree the division of responsibility before cutover, including our managed scope, your team's access and the escalation path to Microsoft and application vendors.
| Microsoft manages | Your team and Inlight IT manage within the agreed scope |
|---|---|
| AVS service infrastructure and physical hosts | Workload capacity, VM configuration, application performance and resource changes |
| The managed VMware platform and its maintenance | Guest patching, application changes, maintenance coordination and validation |
| Underlying service networking | Workload segments, routing, NSX policies, firewall rules, identity and administrator access |
| Platform health and service-level remediation | Application monitoring, alert response, backup, restore tests, disaster recovery, cost review and incident coordination |
We use vCenter Server and NSX Manager alongside Azure tools to operate the environment. Access and changes have to work within the permissions of the managed service, so existing scripts and management integrations are checked.
vSAN protection and host replacement don't replace a workload backup or site recovery plan. We define recovery points, restore order, isolated backup access and a tested recovery destination, using a recovery product that supports the AVS generation and configuration being deployed.
Compare AVS with the move you could make directly
Renew or reduce the existing VMware environment
If the site can stay in use and the platform is supported, renewal may provide time for a single migration. We compare the actual available term and licensed capacity with the cost of moving to AVS first.
Move suitable applications directly to Azure
Azure VMs, platform services or SaaS may avoid an intermediate VMware move. We test application support, networking changes and delivery time against the deadline before assuming that keeping the hypervisor makes the project faster.
Build the next local platform
Where latency, site operation or application requirements keep workloads local, Azure Local or Nutanix may be the better investment. That route needs time for hardware, platform conversion and testing, and Infrastructure Refresh covers the wider local options, including Proxmox where it fits.
See what we’ve delivered for our clients
AVS was one of six paths we considered for PPK. The platform selected and delivered was Azure Local.
nodes in the VMware estate
virtual server workloads migrated
landing paths assessed before selection
AVS questions we hear most
Does AVS remove our reliance on VMware?
AVS moves the infrastructure into Azure while keeping the VMware platform. It can form part of a wider VMware exit, but leaving the software needs a later move to another platform or service.
Does AVS have to be temporary?
No. It can be a longer-term destination where VMware continuity and the Azure operating arrangement justify the cost. We plan a second migration only when it’s part of the intended outcome.
What is the minimum deployment?
Three dedicated hosts per cluster. The selected host type sets the initial capacity and physical-core licensing requirement. We confirm capacity availability and size for maintenance and failure conditions as well as normal operation.
Can we keep our existing IP addresses?
HCX Layer 2 Network Extension can support IP continuity during migration. We validate the supported network, gateway and routing design, then plan the eventual removal of the extension. Application licences linked to virtual hardware also need checking.
Is AVS cheaper than running VMware locally?
That depends on the workload scale, host utilisation, licensing and the costs of the current site. We compare AVS infrastructure, portable VCF, guest licences, connectivity and operations with the full local cost, including any later migration.
Does Microsoft manage the applications and backups?
Microsoft manages the AVS infrastructure and platform. Application support, guest patching, access, network policies and workload recovery stay with the customer and its provider under the agreed service scope.
Do we need ExpressRoute for AVS?
It depends on the generation and the traffic. Generation 1 private clouds connect to Azure through Microsoft-managed ExpressRoute, and Global Reach is the usual path to an on-premises ExpressRoute circuit. Generation 2 sits inside an Azure virtual network, so a site-to-site VPN or ExpressRoute into that network can both work. We size the link for migration traffic and for applications split between locations.
Can we use our existing Windows Server and SQL Server licences in AVS?
Often, yes. Licences covered by Software Assurance can be applied through Azure Hybrid Benefit, either per VM or through qualifying host-level rights such as SQL Server Enterprise unlimited virtualisation. We check the editions and Product Terms against the design before counting the saving.
If AVS is on the shortlist, put the migration and operating costs together
Bring us the deadline, VMware inventory and current commercial terms. We'll work through the AVS design and alternatives, then carry the agreed path through migration and operation.