Beyond virtualization: what is the real value of Azure Local?
When a customer asks me to evaluate Azure Local, in most cases the conversation starts from a concrete need: replacing VMware, refreshing a datacenter, or finding an alternative to the existing virtualization platform.
That’s a perfectly legitimate starting point, especially at a time when many organizations are rethinking their infrastructure strategies. But it’s also the moment when I try to widen the perspective — because evaluating Azure Local purely on its virtualization capabilities risks overlooking an important part of the solution’s value.
Sometimes a degree of scepticism surfaces as well, once people discover that Hyper-V sits underneath Azure Local. I understand that reaction: some perceptions are still tied to experiences from many years ago and don’t always account for how the platform has evolved.
More broadly, I often find that Azure Local is still relatively little known, especially in terms of its wider potential. That’s one of the observations that led us to write Azure Local Unleashed: to help make better known a solution whose value, in our view, goes well beyond replacing a hypervisor.
Azure Local shouldn’t be seen simply as a platform for running virtual machines, but as a vehicle for evolving the infrastructure’s operating model.
From choosing the hypervisor to choosing the operating model
For many years, infrastructure decisions centred largely on the hypervisor. The main questions concerned virtualization features, high availability, performance, storage and compatibility with the existing environment.
That approach was consistent with an IT whose primary goal was consolidating servers and making datacenters more efficient.
Today the picture is different. Applications may be distributed across public cloud, corporate datacenters, production plants and remote sites. Some depend on legacy systems, others use containers and cloud-native services. Some require direct control over data, while others benefit most from the elasticity and managed services of public cloud.
In this context, choosing a platform can’t be reduced to the question «where do I run the VMs?» It also has to account for how those resources will be managed, protected, monitored and modernized over time.
This is where I see the most interesting change Azure Local introduces. The platform makes it possible to keep workloads and data in environments the organization controls, while adopting tools and operating principles consistent with the Azure ecosystem.
That doesn’t mean replicating public cloud wholesale inside the datacenter, nor automatically getting the same capabilities available in Azure. It means reducing, where possible, the operational differences between environments that will remain physically distinct.
The first element of value: governance and operations
Of the advantages Azure Local offers, the one I consider most significant is its contribution to building a coherent governance and management model across distributed environments.
In my experience, this is rarely the first thing that convinces a customer to consider the platform. At the outset, infrastructure characteristics almost always dominate: cost, performance, availability, migration and compatibility with existing workloads. The value of governance generally becomes clearer once you look more closely at how the infrastructure will have to be managed over time.
Think of an organization with numerous production sites. Having a reliable cluster in each plant matters, but it isn’t enough. You have to maintain consistent configurations, know the state of your resources, apply security controls, plan updates and verify compliance with corporate requirements.
In this scenario, technologies such as Azure Arc and Azure Policy make it possible to extend management and governance capabilities to distributed resources, coordinating inventory, policy and controls through the Azure model.
One distinction is important, though.
Azure Arc is not an Azure Local–exclusive capability. It can also be used with traditional servers, VMware environments and Kubernetes clusters outside Azure, extending a range of management, security and governance capabilities to those resources.
The distinctive value of Azure Local is therefore broader than simple Azure Arc integration. Azure Local was designed from the start as an infrastructure platform integrated with Azure: the provisioning model for supported resources, the management of the platform and its lifecycle, together with governance capabilities and compatible services, all contribute to an operational experience more consistent with the cloud.
The difference, then, isn’t just about making existing resources visible in Azure, but about designing local infrastructure as an integral part of a broader operating model.
The benefit isn’t simply having a common console. It’s reducing, over time, the number of exceptions, procedures and different tools an organization has to maintain.
That’s an important shift, because the complexity of a distributed infrastructure doesn’t depend only on the number of servers. Above all, it depends on the ability to govern them coherently.
The second element: local control and sovereignty
Another fundamental aspect is the ability to keep applications running close to the data, the users or the production processes.
In certain scenarios, this need doesn’t stem from a preference for on-premises, but from objective requirements: latency, application dependencies, connectivity, operational continuity, data sovereignty or regulatory constraints.
It’s particularly evident in manufacturing, where IT applications and factory systems often have to coexist. Some workloads can be placed in public cloud, while others need to stay close to the plants to guarantee performance and continuity.
Azure Local makes it possible to address these needs without necessarily treating local infrastructure as an environment separate from the organization’s innovation journey.
Sovereignty, too, is becoming increasingly relevant. Being able to keep data and compute capacity within environments the customer controls can help satisfy specific requirements around location, security and operational control.
It’s important to remember, however, that data location does not automatically equate to sovereignty. Jurisdiction, administrative access, operational responsibilities, technology dependencies and connectivity requirements all come into play as well.
Azure Local can therefore be a component of a sovereignty-oriented architecture, but it shouldn’t be considered a guarantee of compliance on its own. The outcome depends on the design choices and the operating model adopted.
The value, then, isn’t simply keeping applications on-premises. It’s being able to do so within a technology strategy that combines local control and cloud integration, according to the organization’s actual requirements.
The third element: a platform that can evolve with the applications
The third element concerns the ability to support application modernization over time.
An Azure Local project can begin with a very traditional need: replacing a virtualization infrastructure and migrating the existing virtual machines. There’s nothing wrong with that approach. The point is not to treat it as necessarily the end state.
Legacy applications can’t always be modernized quickly. They often depend on vendors, software versions, integrations or business processes that take a long time to change. Forcing an immediate transformation can introduce risks that are hard to justify.
Azure Local allows you to set up a gradual path. VMs can form the initial base, while new application requirements can be addressed through Kubernetes and other services supported by the platform.
This makes it possible — where technically feasible — for traditional applications and more modern workloads to coexist, letting each evolve on its own timeline and priorities.
The advantage is being able to extract value from the initial infrastructure investment even for needs that weren’t necessarily present at the time of adoption.
Naturally, the availability of individual services has to be assessed against the platform version, the prerequisites and the specific scenario. Consistency with Azure does not imply full equivalence between the two environments.
The principle remains important, though: don’t design infrastructure only for what it has to run today, but also for the evolution it may enable tomorrow.
A real case: when replacing VMware wasn’t the real objective
A concrete experience helps illustrate this change of perspective.
We worked with an Italian manufacturing multinational with several production plants and a complex IT environment. The organization already had a significant public cloud presence, with numerous workloads in Azure, virtual desktop services, machine learning, and some applications hosted on AWS as well.
So this wasn’t a customer still discovering the cloud. A structured strategy was already in place, supported by governance activities covering cost, compliance, operational management, architectural standards and documentation.
The main pain point was in the on-premises infrastructure instead: a VMware environment that had grown over time, made up of heterogeneous systems — some by now dated — with performance problems, scalability limits and growing management complexity.
The initial need was to identify an alternative solution. Rather than starting directly from a feature comparison between platforms, however, we based the evaluation on the organization’s requirements and objectives.
The first element was the need to keep certain production-related workloads running locally. The second concerned continuity with the skills already present in the IT team. The third was the ability to integrate the new platform with the Azure ecosystem and with the governance model already adopted. To these, of course, were added economic sustainability, performance, reliability and room for future evolution.
We then analyzed the different alternatives: keeping VMware through an infrastructure refresh, evaluating Azure VMware Solution, migrating the workloads directly to Azure IaaS, adopting Hyper-V on Windows Server, or introducing Azure Local.
Each option had its advantages and trade-offs.
Refreshing VMware would have guaranteed technological and operational continuity, but wouldn’t necessarily have resolved some of the economic and strategic issues behind the evaluation.
Azure VMware Solution would have preserved the VMware model, but would have moved the workloads into Azure regions. An interesting possibility for certain scenarios, but not necessarily consistent with the plants’ latency and autonomy requirements.
Migrating directly to Azure IaaS made sense for some applications, but not for those that had to keep running locally.
Hyper-V on Windows Server was a real alternative, not least thanks to the skills already in the team and the licensing assets available. Part of the operating model, however, would have required additional integration between management tools and processes.
Azure Local emerged as an option particularly well aligned with the full set of requirements: local execution, Hyper-V skills already in place, Azure integration and the ability to adopt a cross-cutting governance model.
Licensing was a favourable factor too. The customer held Windows Server Datacenter licenses with Software Assurance which, where Microsoft’s eligibility requirements are met, allow Azure Hybrid Benefit to be used to reduce specific cost components of the platform.
The most interesting aspect, though, wasn’t the comparison between the individual alternatives.
It was the method used to choose.
Together with the customer we defined shared evaluation criteria, weighting each one in line with the organization’s priorities. That allowed us to compare different platforms without limiting ourselves to a simple feature matrix.
We weren’t looking for the solution with the largest number of technical features, but for the one that best matched the requirements and the operating model the organization intended to build.
The outcome of the evaluation therefore wasn’t only about potentially replacing VMware. It was about the opportunity to bring the governance of local infrastructure into line with an already existing hybrid strategy.
And that is exactly the kind of value that risks going unnoticed when Azure Local is compared with other solutions purely as a virtualization platform.
Assessing the value without ignoring the trade-offs
Azure Local is not, of course, the best choice for every scenario.
One of the first aspects to consider is hardware. The platform requires validated, supported configurations, so reusing systems already in the datacenter can be complex or simply not viable. That matters a great deal, especially when the customer wants to get more out of relatively recent hardware investments.
A second factor is lifecycle management. Azure Local is a continuously evolving platform and requires a structured approach to updates. This means benefiting from improvements and new capabilities, but it also calls for the right operational processes, planning and skills.
It’s essential, therefore, to assess not only the initial deployment, but also how sustainable the management will be over time.
The same applies to connectivity to Azure. Cloud integration is an integral part of the platform’s value, but the level of dependency and the capabilities available have to be analyzed against the specific deployment model.
Finally, there’s the economic dimension. Azure Local can offer significant advantages over other platforms, especially where licensing conditions are favourable. Limiting the comparison to hardware and license costs, however, means leaving out an important part of the decision.
When evaluating different platforms, the risk is building a very long table and simply counting the available features. That’s a useful exercise for verifying technical requirements, but rarely sufficient for a strategic decision.
The question to ask instead is which solution makes automation, monitoring, security, policy, updates and the management of distributed resources more sustainable over time.
The real comparison isn’t just between platforms, but between the operating models those platforms let you build.
Modernizing infrastructure also means modernizing how you manage it
Evaluating Azure Local only by comparing it with other virtualization platforms risks confining the discussion to what the technology can do today, while overlooking what it might let you build tomorrow.
Infrastructure characteristics remain fundamental. Performance, reliability, supportability and cost must continue to drive any evaluation. But the choice should also take into account how the organization intends to manage, protect and modernize its infrastructure in the years ahead.
The platform’s evolution, from application services to edge and AI scenarios, can progressively widen the range of opportunities available. Not all of these capabilities are necessarily suitable or available for every scenario, but they’re worth considering when designing an infrastructure meant to last.
This is the perspective we wanted to develop in Azure Local Unleashed as well: going beyond the technology to understand its role within a broader modernization strategy. In the next article we’ll start from one of the situations where this change of perspective can produce the most tangible results: infrastructure refresh. Because a hardware refresh can be far more than a simple technology swap.
