Should We Move Our VMware Environment to Azure VMware Solution?

For organizations reconsidering their VMware strategy, Azure VMware Solution can be an effective way to move VMware workloads into Azure without immediately redesigning the applications that run on them.

That does not mean AVS is automatically the right destination for every VMware environment.

AVS runs VMware vSphere clusters on dedicated Azure bare-metal infrastructure and includes familiar VMware components such as vCenter Server, vSphere, vSAN, and NSX. The minimum initial deployment is three hosts, which creates a very different cost model from native Azure virtual machines. For some organizations, that tradeoff is worthwhile because it reduces migration complexity and preserves the existing VMware operating model. For others, migrating suitable workloads directly to native Azure services may be more economical.

The right answer depends on workload density, application dependencies, migration timelines, storage requirements, operational skills, and what the organization ultimately wants to accomplish with its VMware estate.

What is Azure VMware Solution?

Azure VMware Solution, commonly referred to as AVS, is a Microsoft-managed VMware environment hosted in Azure.

The distinction matters. AVS is not the same thing as converting a VMware virtual machine into an Azure virtual machine.

An AVS private cloud provides VMware infrastructure running on dedicated Azure hardware. Customers continue working with the VMware tools and constructs they already know, while Microsoft manages the underlying Azure infrastructure and AVS platform.

That platform consistency can significantly reduce the amount of change required during a migration. Applications that currently depend on VMware do not necessarily need to be redesigned simply because the infrastructure is moving to Azure.

For organizations facing a datacenter exit, hardware refresh, VMware contract decision, or other deadline, that can be valuable.

Why choose AVS instead of migrating directly to native Azure?

The strongest argument for AVS is usually not that it is the cheapest way to run virtual machines. It is that it can provide a faster and less disruptive path out of an existing VMware environment.

Consider an organization with hundreds of VMware workloads, complex application dependencies, established network configurations, and an operations team that has spent years working with vSphere. Moving every workload directly to Azure virtual machines may require substantial discovery, remediation, testing, networking changes, and application-level work.

AVS gives that organization another option.

The VMware environment can move into Azure while retaining much of the existing operating model. This can be particularly useful when a datacenter lease or hardware lifecycle creates a firm deadline, application modernization cannot happen within the same timeline, or workloads have complicated dependencies that make immediate refactoring risky.

In those situations, AVS can separate two very different projects: moving infrastructure and modernizing applications. Trying to do both simultaneously is not always the lowest-risk approach.

Is Azure VMware Solution expensive?

It can be.

This is one of the most important parts of the AVS discussion and one that should be addressed before an architecture is selected.

AVS uses dedicated hosts and requires a minimum initial deployment of three hosts. That means an organization is purchasing a block of VMware compute capacity rather than paying only for the individual virtual machines it consumes.

A small VMware environment may therefore have difficulty making efficient use of the minimum AVS footprint. A larger, densely consolidated estate may have a very different economic profile.

This is also why comparing the monthly price of AVS with the monthly price of several Azure VMs can be misleading. A meaningful financial comparison should account for the broader cost of the current VMware environment, including licensing, server and storage refreshes, datacenter or colocation expense, backup and disaster recovery, maintenance, operational labor, and upcoming capital expenditures.

The comparison should also include alternatives within Azure. Some workloads may be better candidates for Azure VMs or platform services rather than AVS.

AVS should earn its place in the architecture. It should not be selected simply because the source environment happens to be VMware.

Assess the VMware estate before sizing AVS

One of the easiest ways to make AVS unnecessarily expensive is to size the target environment directly from provisioned VMware resources.

VMware environments often accumulate excess capacity over time. Virtual machines may have more CPU or memory assigned than they actually use. Test workloads remain online after projects end. Old systems continue consuming storage because nobody is comfortable retiring them.

Those conditions matter when sizing dedicated infrastructure.

Before an AVS sizing exercise, our engineers typically want to understand:

• CPU and memory utilization over a representative period
• Storage capacity, growth, IOPS, and throughput
• VM and application dependencies
• Current cluster utilization
• Backup and recovery requirements
• Application maintenance windows
• Licensing constraints
• Workloads that can reasonably be retired or consolidated

Performance-based assessment matters because provisioned capacity and consumed capacity can tell very different stories.

We see this fairly often in mature VMware estates. The environment has grown incrementally over years, workloads have come and gone, and the resources assigned to individual VMs no longer necessarily reflect what those applications actually need. Moving that footprint without first examining utilization can carry years of overprovisioning directly into the new cost model.

Rightsizing before migration is usually much easier than trying to correct an oversized environment after the move.

Storage deserves its own design discussion

AVS includes VMware vSAN, which uses the local storage available within each host in the cluster. For many workloads, that model works well.

It can become less efficient when an environment needs substantially more storage than compute.

Suppose the available CPU and memory in the AVS cluster are sufficient, but the organization requires significantly more datastore capacity. Adding another AVS host simply to obtain additional vSAN storage means buying compute and memory that may not be needed.

External storage can change that equation.

AVS supports external storage options that allow storage capacity to scale independently from AVS compute. This can be particularly important for storage-heavy VMware environments where sizing the cluster exclusively around vSAN capacity could result in unnecessary host capacity.

This is why storage profiling belongs early in the assessment rather than after the cluster has already been sized. An environment with modest storage requirements and very high compute utilization may favor one design. A storage-heavy estate with relatively low CPU utilization may point toward another.

How does AVS connect to the rest of Azure?

AVS should not be viewed as an isolated VMware island.

An AVS private cloud can connect to Azure virtual networks and native Azure services. Hybrid connectivity can also be established between the existing on-premises environment and the AVS private cloud.

That creates an architecture where VMware workloads can remain on AVS while beginning to consume services elsewhere in Azure.

This is another pattern we see organizations considering as part of a broader modernization strategy. Not every application tier has to move at the same time or to the same destination.

An application may remain on VMware initially while its database, integration layer, security services, backup platform, or other components gradually move toward Azure-native services. That gives infrastructure and application teams more flexibility when sequencing modernization work.

How do VMware workloads move into AVS?

VMware HCX is commonly used to support workload mobility between an existing VMware environment and AVS.

The source and destination both use VMware technologies, which can reduce the amount of change required at the application layer. That does not eliminate migration engineering.

Network extension, application dependencies, available bandwidth, migration windows, rollback procedures, testing, and workload sequencing still need to be considered carefully.

The migration plan should also reflect application relationships rather than simply the structure of the source VMware clusters. Moving ten virtual machines is straightforward. Moving ten virtual machines that collectively support a revenue-generating application requires a very different level of planning.

AVS versus native Azure is not an either-or decision

This may be the most important point in the entire discussion.

There is rarely a technical reason every VMware workload has to end up in the same destination.

A practical VMware modernization program may create several paths:

• Move to AVS: Applications that need to leave the datacenter quickly but would require significant effort or risk to redesign.
• Move to Azure VMs: Conventional server workloads that can operate effectively on native Azure infrastructure.
• Modernize to Azure platform services: Applications or databases where reducing infrastructure management creates enough value to justify additional engineering.
• Retire or consolidate: Systems that no longer justify the cost or complexity of migration.
• Remain on-premises: Workloads with hardware dependencies, latency requirements, regulatory constraints, or economics that make a move difficult to justify.

We tend to favor this portfolio approach because the answer is rarely as simple as moving an entire vCenter inventory to a single new destination.

The question should be asked at the workload level: what is the right long-term home for this application, and how much change is reasonable during the current migration window?

When would we be cautious about recommending AVS?

There are several situations where we would want to challenge an AVS-first strategy.

A relatively small VMware environment is one. Because of the minimum host footprint, the economics may be difficult to justify if the organization cannot effectively consume the available capacity.

We would also look carefully at AVS when most workloads are straightforward candidates for native Azure, when the organization explicitly wants to eliminate its VMware operating model, or when there is no business deadline forcing a rapid relocation.

Other warning signs include environments that have not been rightsized, workloads that are already candidates for retirement, or a business case based primarily on an assumption that cloud will automatically be cheaper.

Cloud architecture does not eliminate economics. It changes them.

When is AVS particularly compelling?

AVS tends to become more interesting as several conditions appear together.

A large, densely utilized VMware estate is one. A near-term datacenter exit is another. Significant application dependencies, limited appetite for application changes, and a desire to preserve VMware operational skills can all strengthen the case.

The key consideration is usually the value of reducing change during migration.

If keeping the application environment largely intact avoids months of remediation or materially lowers migration risk, the cost premium of dedicated AVS infrastructure may be justified.

That is a business decision as much as an infrastructure decision.

AVS can be the first step, not the final architecture

Moving workloads to AVS does not mean the organization has committed to VMware indefinitely.

One of the more practical uses of AVS is as a transition platform.

An organization might first move VMware workloads out of a datacenter because of a lease expiration, hardware deadline, or licensing event. Once those workloads are operating in Azure, individual applications can be evaluated over time for Azure-native modernization.

That separates an urgent infrastructure event from a much longer application transformation program.

For some organizations, that distinction is what makes the migration practical.

So, should you move VMware to Azure VMware Solution?

Possibly, but the fact that you currently run VMware is not enough reason by itself.

AVS is strongest when the business needs to move VMware workloads quickly, preserve existing operational patterns, and minimize application changes during migration. It can be particularly effective for large or complex estates where immediate refactoring would create substantial cost, risk, or delay.

Native Azure may be a better destination when workloads can move cleanly, when the organization wants to eliminate VMware rather than relocate it, or when the economics of a dedicated AVS cluster are difficult to justify.

In many environments, the right answer will be a combination of both.

The assessment work matters because the decision should be based on actual workload characteristics, dependencies, utilization, and business requirements rather than assumptions about the platform.

For organizations considering their VMware options, Oakwood’s VMware Modernization Assessment is designed to evaluate the existing estate, identify practical migration and modernization paths, and help establish where AVS, native Azure, or another approach makes the most sense.

Frequently Asked Questions

• Is Azure VMware Solution cheaper than on-premises VMware? Not necessarily. AVS uses dedicated host infrastructure and requires a minimum initial three-host footprint. Economics depend heavily on utilization, storage architecture, licensing, commitment options, and the on-premises costs being replaced.
• Can existing VMware VMs move to AVS without being rebuilt? In many cases, yes. AVS preserves the VMware platform, which allows workloads to migrate with considerably less application change than moving them directly to a different infrastructure model. VMware HCX is commonly used as part of that migration process.
• Do we still use vCenter with AVS? Yes. AVS includes VMware vCenter Server along with vSphere, vSAN, and NSX. Customers continue to use familiar VMware management capabilities while Microsoft manages the underlying AVS service.
• Can AVS workloads communicate with native Azure services? Yes. AVS can connect with Azure virtual networks and Azure-native resources, allowing organizations to retain VMware workloads while gradually adopting other Azure services.
• Does AVS require ExpressRoute? ExpressRoute is a fundamental part of AVS connectivity. The private cloud includes connectivity into Azure, and hybrid designs can extend connectivity back to the on-premises environment depending on the architecture.
• Can storage scale separately from AVS compute? Yes. AVS includes vSAN, but supported external storage options can allow additional storage capacity to be added without increasing the number of compute hosts. This can materially affect the economics of storage-heavy environments.
• Is AVS intended to be permanent? It can be, but it does not have to be. Some organizations use AVS as their long-term VMware platform in Azure. Others use it as a landing zone while applications are gradually evaluated for native Azure modernization.
• What should we assess before deciding on AVS? At minimum, evaluate actual CPU and memory utilization, storage capacity and performance, application dependencies, network requirements, recovery objectives, licensing, migration timelines, and workloads that could move directly to native Azure or be retired.

Why Oakwood?

VMware modernization discussions have become more nuanced. Organizations are not simply asking where to move their virtual machines. They are weighing licensing changes, datacenter decisions, hardware refreshes, cloud economics, application dependencies, recovery requirements, and longer-term modernization plans at the same time.

That is consistent with the conversations our Azure engineers are having today. In many cases, the initial question is about VMware, but the eventual architecture is mixed. Some workloads are strong candidates for AVS, others belong on native Azure infrastructure, and certain applications warrant a deeper modernization discussion. There are also workloads where the right answer is to leave them alone for now.

Oakwood is a Microsoft Solutions Partner with deep Azure infrastructure experience across migration, networking, storage, governance, disaster recovery, and high-performance computing. Our approach to VMware modernization begins with understanding the current environment and the business event driving the decision. From there, our engineers can model the available paths, identify dependencies and risks, and develop an architecture that makes sense technically and financially.

The goal is not to move VMware to Azure. The goal is to determine what should move, where it should go, and what the organization gains by making the change.