Neither fully on-premises nor fully cloud is the right answer for most organisations.
Hybrid cloud architecture is not about splitting infrastructure evenly between cloud and on-premises. It is about placing each workload where it performs, costs, recovers and operates best, then managing the environment as one coherent operating model.
Some workloads belong in Azure. Some should stay on local infrastructure. Some need Azure Local, Nutanix, Proxmox or another retained local platform. Some need Azure VMware Solution as a temporary bridge. Some should be retired or replaced rather than carried forward. The question is not cloud or on-premises; it is what belongs where, and how the whole environment will be operated after the decision is made.
See the workload placement frameworkHybrid cloud is workload placement discipline with unified management.
Hybrid cloud is often described as using both on-premises and cloud infrastructure. That is too shallow. The real discipline is deciding where each workload belongs and then preventing the environment from becoming two disconnected operating models.
A workload with predictable load, local dependency, low-latency requirements or site-specific data may perform and cost better on local infrastructure. A workload with variable demand, modern application patterns, managed-service fit or broader access requirements may belong in Azure. A mixed estate should not be forced into one answer.
The benefit of hybrid architecture is workload placement flexibility. The discipline is maintaining operational consistency across deployment locations without creating unnecessary platform management overhead, which means identity, network, security, backup, monitoring, documentation and support ownership need to work across both local and cloud environments. Hybrid cloud is not a compromise. It is often the most accurate answer.
Hybrid architecture works when workload placement and operational consistency are designed together.
Placement across platforms, by requirement
Hybrid cloud architecture places workloads across local infrastructure, Azure, Microsoft 365, SaaS and other platforms based on technical, commercial and operational requirements. It may include Azure workloads, Microsoft 365 services, Azure Local, retained VMware, Nutanix, Proxmox, Azure VMware Solution, local file, identity, application and infrastructure services, SaaS replacements, and workloads staged for later movement.
Mixed workload patterns
Hybrid architecture is strongest where the organisation has mixed workload patterns — some systems need local performance or control, others benefit from Azure elasticity, managed services or cloud-native capability.
One controlled estate, not two platforms
The hard part is not connecting cloud and on-premises. It is operating the environment as one controlled estate rather than two separate platforms joined by a network link.
The questions a hybrid design must answer
Which workloads stay local, which move to Azure, which move later, which need a bridge, which should be retired or replaced, how identity, network, security, backup and monitoring work across the whole environment, and who supports it after it is live.
Hybrid architecture has become the practical choice because both extremes have become harder to defend.
Fully on-premises infrastructure can become expensive, rigid and difficult to modernise when VMware renewal pressure, hardware refresh, backup weakness and lifecycle risk arrive together. Fully public cloud can also become difficult when costs are unpredictable, workloads are steady-state, data movement is heavy, or the operating model is not mature enough to govern the environment properly.
Hybrid architecture gives the organisation a more practical path — local infrastructure remains where it has a genuine role, while Azure and Microsoft cloud services are used where they improve scalability, manageability, resilience or operating efficiency. Common triggers include:
- VMware renewal pressure
- Ageing server and storage infrastructure
- Unpredictable cloud consumption
- Cloud workloads without enough cost governance
- Local systems that still need low latency or operational proximity
- Business continuity requirements across local and cloud services
- Dual management tools creating operational overhead
- The need to modernise without moving every workload at once
VMware cost pressure is changing the on-premises decision. Cloud cost unpredictability is changing the cloud decision.
For many organisations, VMware is no longer just a renewal line item; it has become a forcing event. Commercial changes, subscription models, minimum licensing positions and renewal pressure have made some organisations question whether another VMware cycle is still the right platform decision. On the other side, Azure can be the right destination for many workloads — but cloud needs governance, and costs can become difficult where usage does not match the model.
- Retain VMware temporarily, or reduce the VMware footprint
- Move selected workloads to Azure
- Move retained local workloads to Azure Local
- Assess Nutanix or Proxmox as the local platform
- Use Azure VMware Solution as a bridge
- Retire or replace workloads that should not be migrated
- Refresh local infrastructure where it still makes sense
- Idle compute and underused reserved capacity
- Development and testing cost overruns
- Storage growth without lifecycle policy
- Data transfer and egress costs
- Backup and monitoring charges not included in early models
- Workloads moved to cloud without being redesigned or governed
Related reading on the local side: Broadcom VMware renewal, VMware exit strategy and VMware workload placement. On the cloud side: Managed Cloud and Migration, Azure migration strategy and Azure landing zones.
Operational complexity is the real hybrid risk.
The technical connection between local infrastructure and Azure is only one part of the architecture — the operating model matters more. A weak hybrid design leaves the team with:
- Separate monitoring tools and inconsistent security controls
- Unclear identity ownership
- Duplicated backup processes
- Inconsistent patching and lifecycle discipline
- Unclear escalation paths and cloud cost ownership gaps
- Documentation that does not match reality
- Support processes split between platforms
Business continuity shapes placement decisions.
Business continuity requirements often explain why a fully cloud or fully local approach does not hold. Some systems need to keep running close to users, sites, equipment or local data; some need cloud-based resilience, geographic recovery or managed backup; some need both.
A hybrid architecture should consider how critical each workload is, what outage the business can tolerate, whether local access is required during connectivity disruption, whether cloud recovery is appropriate, what identity services are needed during recovery, how backup and restore work across local and Azure workloads, what order systems need to recover in, and whether recovery has been tested rather than just documented.
New architecture does not improve continuity unless the recovery model is designed. Hybrid can be strong for resilience, but only when backup, recovery and failover are engineered properly.
The platform decision should follow the workload's requirements, not the other way around.
A hybrid architecture should start with workload classification. The full per-workload framework sits on the workload-placement page; the summary view follows.
Low-latency requirements, high-volume local file access, local plant, equipment, branch or site dependency, predictable steady-state utilisation, data residency or control requirements, specialised hardware or local integration, recovery requirements that depend on local operation, or applications with complex migration dependencies.
Variable or bursty demand, development and testing environments, internet-facing applications, applications being modernised, managed database or PaaS fit, workloads needing scale or geographic reach, backup, DR and analytics use cases where Azure improves the model, or services where infrastructure ownership should reduce.
Legacy systems with unclear dependencies, VMware workloads under renewal pressure, applications with complex database or file dependencies, systems with vendor-controlled change windows, workloads requiring IP continuity or bridge migration, or workloads that may eventually move but need time.
A migration or refresh review should also identify systems that should be retired, replaced, consolidated, moved to SaaS, or left untouched until an application decision is made. Hybrid architecture is strongest when it avoids migrating technical debt.
Most estates split roughly this way — but the workloads that land in the wrong column are the expensive ones. A workload-by-workload pass settles it before anything is licensed.
Map your estate →Azure Local bridges local control with Azure management. Azure Arc makes the whole estate consistent.
Local infrastructure, Azure-connected management
Azure Local is relevant where workloads still need to run locally but the organisation wants Azure-consistent management, governance, monitoring and security. It is Microsoft's Azure-connected infrastructure platform for customer-owned environments, and it can help organisations modernise local infrastructure without pretending every workload belongs in public cloud.
It can fit where workloads still need local performance or control; the estate is Microsoft-heavy; Azure Arc, Azure Policy, Azure Monitor and Defender for Cloud fit the operating model; Azure Hybrid Benefit materially improves the commercial case; VMware pressure is forcing a local platform review; HCI is a better fit than a traditional three-tier refresh; or local infrastructure still matters but should be managed in a more Azure-aligned way.
Azure Local is not the right answer for every hybrid environment; it is one platform option inside the architecture, and should be compared against Nutanix, Proxmox, retained VMware, AVS and direct Azure migration before the platform is locked. See Azure Local HCI, Azure Local vs Nutanix and VMware vs Azure Local.
Azure management, beyond Azure
Azure Arc is central to many hybrid cloud architectures because it extends Azure management capabilities to infrastructure running outside Azure — on-premises servers, Azure Local, other clouds and edge environments. The value is not only visibility; it is operational consistency.
Azure Arc can support inventory and visibility across local and cloud infrastructure, Azure Policy enforcement, Microsoft Defender for Cloud integration, Azure Monitor integration, governance across Azure and non-Azure resources, role-based access control patterns, and a more consistent security and compliance posture.
Azure Arc does not remove the need for good architecture. It gives the organisation a management layer that can reduce fragmentation when designed properly, but the operating model still needs ownership.
Connectivity determines whether hybrid architecture works in practice.
Hybrid architecture depends on network design. A workload may be correctly placed on paper and still perform poorly if connectivity, routing, DNS, identity or firewall design is weak.
Private connectivity to Azure
Usually considered where bandwidth, consistency, security posture, latency or business criticality justify a dedicated private connection.
Encrypted connectivity over the internet
Appropriate for smaller environments, secondary paths, lower-volume traffic or cost-sensitive use cases.
Application-aware branch connectivity
Can help where multiple sites, multiple underlays, application-aware routing or branch connectivity are part of the hybrid design. See Managed SD-WAN.
Hybrid architecture also needs to consider firewall design, segmentation, DNS, routing, remote access, identity traffic, cloud security controls, monitoring and logging paths, and backup and replication traffic. Connectivity is not a bolt-on; it is part of the architecture.
Hybrid architecture should be built incrementally.
Hybrid implementation should start with workload assessment and placement planning rather than infrastructure deployment — understanding which systems belong where drives the architecture design. The architecture should then be built in controlled stages. A practical sequence usually includes:
Local infrastructure, Azure usage, Microsoft 365, identity, network, backup, monitoring, security, applications, data flows and support ownership.
Stay local, move to Azure, move later, use a bridge, or retire.
The local, cloud and management layers designed together, including Azure Arc, Azure Local, networking, backup, identity, governance and support model.
Across three years for local infrastructure, Azure consumption, licensing, support, migration, backup, monitoring and operations.
Cloud and local foundations before workloads move, including Azure landing zones, Azure Arc, Azure Local, backup, monitoring, identity and network controls.
Lower-risk workloads first, validating performance, access, backup, monitoring, security and support processes.
In waves, refreshing local infrastructure where required and stabilising after each phase.
Documented ownership for patching, monitoring, backup, recovery, lifecycle, cost governance and incident response.
What good hybrid architecture should produce.
The organisation knows which workloads belong in Azure, which remain local, which need a staged path, and which should be retired or replaced.
Azure Arc, Azure Monitor, Defender for Cloud and other tooling used where they create genuine operational consistency.
ExpressRoute, VPN, SD-WAN, routing, DNS and security paths designed around workload behaviour, not generic diagrams.
Backup, restore, failover and continuity patterns defined across local and cloud workloads.
Cloud consumption, local spend, licensing, migration and support cost modelled together.
Who owns identity, backup, monitoring, patching, security response, cost review, lifecycle management and escalation.
The environment can change over time without forcing every workload into one platform decision.
The result should be one operating model across different locations.
Hybrid architecture designed for operational outcomes, not platform balance.
The goal is not to use cloud and on-premises equally; it is to place each system where it performs best and costs sensibly, while keeping the environment manageable after the work is complete.
Placement decisions are based on workload requirements, not platform preference. VMware alternatives are assessed properly — Azure Local, Nutanix AHV, Proxmox, Azure VMware Solution and selective Azure migration — with the recommendation following the estate rather than vendor loyalty. Real cost is modelled: TCO analysis includes licensing, support, migration, backup, monitoring, egress, operational overhead and three-year cost shape, because vendor calculators are only part of the picture. Azure Arc and related tooling are used where they provide genuine operational consistency, because a single pane of glass is only useful if it supports how the team actually operates. Connectivity — ExpressRoute, VPN, SD-WAN, routing and security paths — is designed around performance, resilience and supportability. And assessment, design, implementation and ongoing support stay connected enough that the target state can actually be operated after go-live, with clear escalation and practical ownership.
As an illustration of the pattern rather than a headline: in recent cloud and infrastructure work, hybrid architecture was the right answer where some workloads benefited from Azure while others needed to remain local because of project data, finance systems, performance requirements or dependency complexity. The outcome was not a blanket cloud migration. It was a placement-led architecture — cloud where cloud improved the operating model, retained local infrastructure where local performance and control still mattered, and staged movement where dependencies needed to be handled carefully. That is the practical value of hybrid architecture; it lets the organisation modernise without pretending every workload has the same destination.
The question is not cloud or on-premises. It is what belongs where — and how the whole environment will be operated after the decision is made.
Hybrid cloud architecture usually sends the decision in one of two commercial directions.
If many workloads still need to remain local
The next step is usually Infrastructure Refresh: Azure Local, Nutanix, Proxmox, VMware retention, AVS, server replacement, stronger backup or a staged local platform decision. See also Server replacement strategy, Azure Local HCI and Azure Local vs Nutanix.
If many workloads are cloud-ready
The next step is usually Managed Cloud and Migration — a proper cloud foundation before production workloads move: landing zones, identity, networking, security, backup, cost governance, monitoring and support ownership. See also Azure migration strategy and Azure landing zones.
If VMware pressure is the trigger
The next step is usually VMware Workload Placement, Broadcom VMware Renewal or VMware Exit Strategy.
If the target state is already mixed
The next step is usually Hybrid Infrastructure Workload Migration — staged movement across VMware, Azure, Azure Local, Nutanix, Proxmox, AVS and retained local platforms.
Hybrid cloud architecture questions we hear most.
What is hybrid cloud architecture?
The design of workloads, identity, networking, security, backup, monitoring and support across local infrastructure and cloud services. It is not simply having some systems on-premises and some in Azure.
Is hybrid cloud just a temporary step to full cloud?
Not always. For many organisations, hybrid is the durable operating model because different workloads genuinely have different requirements. Hybrid only becomes a problem when it is unmanaged.
What workloads should stay on-premises?
Workloads often stay local when they need low latency, local data access, predictable performance, site dependency, data control, specialised hardware or strong local recovery.
What workloads should move to Azure?
Workloads often move to Azure when they benefit from elasticity, managed services, cloud-native capability, geographic reach, modern application design or reduced infrastructure ownership.
Where does Azure Local fit?
Azure Local can provide a modern local platform for workloads that still need to run on-premises but benefit from Azure-connected management, governance, monitoring and security.
Where does Azure Arc fit?
Azure Arc extends Azure management and governance to infrastructure outside Azure, helping create a more consistent operating model across hybrid environments.
Do we need ExpressRoute?
Not always. ExpressRoute is usually considered where private connectivity, consistent bandwidth, latency, security posture or business criticality justify it. Smaller or lower-volume environments may use site-to-site VPN.
Is hybrid more complex than cloud-only or on-premises-only?
It can be — hybrid creates more moving parts. The benefit is better workload placement; the trade-off is that identity, network, backup, monitoring, security and support must be designed properly.
How does hybrid architecture relate to VMware exit?
VMware exit often produces hybrid architecture because not every VMware workload has the same best destination — some move to Azure, some to Azure Local or Nutanix, some to AVS as a bridge, and some stay local temporarily.
Where does Hybrid Cloud Architecture sit in Inlight IT's Cloud and Infrastructure structure?
It sits inside the authority spine as a bridge page, connecting Infrastructure Refresh and Managed Cloud and Migration because hybrid decisions often include both retained local infrastructure and cloud-ready workloads.
Design the hybrid architecture before the platforms are locked in.
Decide what runs where — and how it is run afterwards. Cloud-leaning estates can start with Managed Cloud and Migration.
Explore Infrastructure Refresh