In meetings with customers and IT decision makers, I still often hear things like: “We’re only keeping the datacenter for legacy workloads,” or “Sooner or later we’d like to move everything to Azure.”
These are understandable statements. For many years, after all, the journey to the cloud was told as an almost linear progression: from the traditional datacenter to hybrid cloud and, finally, to public cloud. In that narrative, hybrid was mainly an intermediate stage — a temporary condition destined to gradually disappear.
What I see in projects today is different.
Hybrid is not a transition strategy; it is becoming a deliberate operating model.
This doesn’t mean public cloud has lost its centrality. On the contrary, it remains the best choice for a great many workloads. What it does mean is that we should stop treating cloud and on-premises as two alternative destinations, and start thinking in terms of a model where applications and data can be distributed intentionally across different environments.
The question, then, should no longer be “cloud or on-premises?” but “where does it make the most sense to run this specific workload?”
Every workload has different requirements
The starting point should always be the workload. Different applications have different characteristics, and in the same way public cloud and local infrastructure offer distinct benefits. The goal isn’t to decide up front which model is better, but to match the application’s requirements with the platform’s characteristics.
It’s this combination that makes it possible for a workload to be effective and efficient at the same time.
There are, for example, scenarios where physical proximity remains decisive. One case I come across frequently is in manufacturing. Picture an organization with its main datacenter in Bologna and production plants spread across several countries. Some MES applications simply have to stay close to the plants they control, because latency, connectivity continuity and dependencies on local systems can matter far more than the elasticity public cloud offers.
In a scenario like this, moving a workload to the cloud simply because “the strategy is cloud-first” would risk adapting the application to the platform, instead of choosing the platform to fit the application.
And that is exactly the opposite of what should happen.
Latency and connectivity aren’t the only factors
Proximity is only one of the criteria to weigh. Another important one is cost.
There’s a fairly widespread belief that cloud is inherently cheaper than local infrastructure or, conversely, that migrating to the cloud is necessarily very expensive. Taken in absolute terms, neither statement means much.
A stable, predictable workload can have a very different economic profile from one with sharp swings in demand. An application that needs a lot of elasticity has different requirements from a system that will use essentially the same capacity for many years. That’s why decisions should rest on a real Total Cost of Ownership (TCO) analysis, not on beliefs formed in the past or on perceptions unsupported by data.
Data sovereignty and compliance matter just as much. In certain industries, data location, operational control, regulatory requirements and the organization’s own specifics can directly shape architectural choices.
Workload placement therefore means balancing several dimensions at once: latency and local dependencies, connectivity, cost, sovereignty, compliance, business continuity, and the characteristics of the application itself.
This multidimensional approach is exactly what we tried to put at the center of the Adaptive Cloud strategy in Azure Local Unleashed as well.
But keeping everything on-premises isn’t a better strategy
If I think migrating everything to public cloud as a matter of principle is wrong, I consider keeping everything on-premises simply because that’s how it’s always been just as risky.
That situation is still very common too. Sometimes it comes down to not knowing the alternatives, sometimes to the fear of tackling something new. And then there’s the classic “if it works, don’t touch it” — an understandable attitude operationally, but one that becomes a limitation when it stops you from even evaluating different scenarios.
The same happens when a cloud migration is ruled out up front as too expensive, without any real economic comparison ever being made. In some cases, continuing to own and manage local infrastructure means keeping oversized servers, refresh cycles, support contracts, datacenter space, power, specialist skills and operational processes that may no longer be justified by the value of the workload.
For certain applications, public cloud can clearly be the better option.
So once again, the problem isn’t picking a side. It’s choosing well.
What’s changed compared with the hybrid cloud of a few years ago
Distributed infrastructure is nothing new. Companies have been running datacenters, branch offices, production plants and remote sites for decades. The real difference from the past is the maturity of the tools we now have to govern these environments.
Historically, distributing infrastructure often meant distributing the management tools as well. Each environment might have its own consoles, its own procedures, different monitoring tools, standalone security models and independent update processes. It was hybrid from an infrastructure standpoint, but rarely from an operational one.
That paradigm is now changing. Common control planes, centralized policy, automation, observability and — increasingly — AI-based tooling make it possible to separate where a workload runs from how it is governed.
And that is probably one of the most important shifts in the evolution of hybrid cloud: distribution doesn’t have to mean fragmentation.
It’s the principle behind technologies like Azure Arc, though I consider the concept more important than any single product. The real goal is being able to apply governance, policy, security, monitoring and automation consistently, regardless of where a resource sits.
Workload placement is no longer necessarily permanent
There’s another significant difference from the past. Infrastructure decisions used to be treated as final: once a platform had been chosen and the project delivered, moving a workload again could be expensive, complex and risky.
Today, migration, replication, automation and management technologies are far more mature. That turns workload placement into a decision that can be reassessed over time rather than treated as immutable.
An application that has to live in the datacenter today might be modernized and moved to public cloud tomorrow. A workload born in the cloud might instead come to need closer proximity to data or to a production plant. New regulation could change sovereignty requirements, just as a shift in usage profile could make a different platform more cost-effective.
In this scenario, the ability to change a decision becomes almost as important as the original decision. Architecture therefore has to be designed not only to meet today’s requirements, but to keep future options open.
The real problem is often governance
This is where one of the strategic mistakes I see most often in organizations comes out: choosing the platform first and analyzing the workloads afterwards.
It should be the other way round. First you need to understand applications, data, dependencies, operational requirements and the cost profile; only then does it make sense to identify the most suitable platform.
There’s a second mistake, though, and perhaps an even more important one: underestimating governance.
Building a hybrid environment without a coherent governance model simply risks multiplying complexity. Being able to run workloads in different environments isn’t enough: you have to be able to inventory, protect, monitor, update and govern them under consistent principles.
This is precisely where hybrid cloud differs profoundly from the past. The value doesn’t come only from having more places to run an application, but from being able to do so without multiplying operational complexity proportionally.
In other words, the real challenge of hybrid cloud isn’t distributing infrastructure. It’s being able to govern that distribution.
Where Azure Local fits in
In this landscape, Azure Local is one of Microsoft’s answers to the evolution of hybrid infrastructure.
I don’t find it interesting simply because it lets you run virtual machines outside Azure. That’s only a starting point. The more significant element is the ability to bring compute capacity closer to applications and data while keeping an operating model that is increasingly consistent with the one used in the cloud.
It’s also one of the concepts we wanted to highlight in Azure Local Unleashed: Azure Local shouldn’t be read simply as a replacement for existing infrastructure, but as a component of a distributed model in which a workload can be placed where it creates the most value.
This doesn’t mean replicating Azure inside your own datacenter, nor claiming that cloud and on-premises will become completely equivalent. It means reducing the discontinuity that has historically marked moving a workload between different environments, so you don’t have to rebuild processes, tools and control models every time.
It’s an important distinction: the value isn’t in having “the cloud on-premises,” but in making the way different environments are managed more consistent.
From cloud-first to workload-first
Maybe it’s time to move past some of the labels we’ve used in recent years.
Cloud-first played an important role: it pushed many organizations to question long-established infrastructure models, accelerating the adoption of new services and new operating paradigms. The next level of maturity, though, may well be a workload-first approach.
That means not starting from the platform, from the technology we know best, or from the goal of moving something. It means starting from the application — understanding its requirements, dependencies, cost profile, security requirements and operational constraints — and only then deciding where it should run.
That’s why I don’t believe hybrid infrastructure is a transitional phase. I believe it’s becoming the natural outcome of an IT in which placement decisions can be made more deliberately and revisited over time, while governance and operations become progressively independent of the physical location where the workload sits.
In the end, the idea can be summed up in a single sentence:
The future of enterprise IT is not cloud versus on-premises, but intelligent workload placement.
And that’s exactly where the next article in this series will start: how do you decide, concretely, whether a workload should run in Azure, on Azure Local, or on traditional on-premises infrastructure?
