# Hybrid Cloud, Private Cloud and On-Premises

> What pulls workloads on-premises, licensing as an architectural force, the hard parts of hybrid identity, DNS and AI, and tenant-to-tenant migration.

- Web page: https://www.alesanalytics.com/architecture/hybrid-and-on-premises
- Markdown: https://www.alesanalytics.com/architecture/hybrid-and-on-premises.md
- Part of: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md), section "The enterprise estate"
- Last verified: 13 October 2026
- Publisher: Ales Analytics

## What pulls a workload where

Very few enterprises run entirely in one place. The reasons are mostly technical, and they're worth stating plainly because they decide which workloads move and which never will.

| What drives placement | Where it pulls |
| --- | --- |
| Data gravity, and the latency needs of operational technology | On-premises, or the edge |
| Operator control and sovereignty | A sovereign or private cloud |
| Bursty demand, and the appeal of managed services | Public cloud |
| GPU scarcity | Wherever the capacity is |
| Legacy: mainframes, fixed IP addresses, licence dongles | On-premises |

## The parts of an on-premises estate

The facility, with its power, cooling and redundancy (N+1 or 2N). A spine-leaf network fabric. Storage on SAN, NAS or hyperconverged infrastructure. Hypervisors: vSphere, Hyper-V, KVM, OpenShift Virtualization. A private-cloud control plane: VMware Cloud Foundation, OpenStack, Azure Local, AWS Outposts, Google Distributed Cloud. And the shared services everything depends on: Active Directory Domain Services, PKI, DNS, DHCP and NTP.

### Licensing is an architectural force

VMware is now sold by subscription only and licensed per core, with a minimum of 16 cores per CPU. A 72-core minimum per order line, reported to partners for 10 April 2025, was reportedly withdrawn by that date, and Broadcom said it had never announced a price change. Confirm the current terms on a quote.

The architectural point survives the details: per-core licensing makes host core counts and the choice of hypervisor into design variables. A disaster-recovery site full of idle licensed cores costs real money; so does bursting into a licensed estate. Per-user AI licensing and per-token pricing do the same thing to AI topology. Treat licensing as a constraint in the design, not a line in the budget afterwards.

## The hybrid patterns, and their hard parts

**Figure: The hybrid estate: what crosses the line between the data centre and the cloud.** On-premises: Active Directory Domain Services (Kerberos, the legacy identity root), conditional DNS forwarders (one per private zone) and a private cloud (vSphere, Hyper-V, Azure Local or OpenShift). Dedicated links: ExpressRoute, AWS Direct Connect, Cloud Interconnect. In Azure: Microsoft Entra Connect synchronising AD to Entra ID, Azure DNS Private Resolver answering private endpoint names for on-premises clients, and Azure Arc as a privileged management agent on every server. Each link is a dependency that can fail on its own. The two that surprise people most are identity, because a compromise of on-premises Active Directory becomes a path into the cloud, and DNS, because private endpoints only resolve from on-premises if the forwarders are right.

| Pattern | The hard part |
| --- | --- |
| Identity, Active Directory synchronised to Entra | A compromise of on-premises AD becomes a path into the cloud |
| Connectivity over dedicated links and BGP | Genuinely diverse dual circuits, MTU, route filters |
| DNS | Conditional forwarders, and resolving private endpoints from on-premises |
| Bursting to the cloud | Data locality, egress charges, licensing |
| Data, by CDC from on-premises to the cloud | Lag, residency, schema drift |
| AI with the data on-premises and the model in the cloud | The context leaves your boundary with every request |
| Management through Arc or Systems Manager agents | The agents become privileged dependencies on every server |
| Disaster recovery to the cloud | Re-addressing, licensing, and restore tests that actually happen |

The AI row deserves a second look. Keeping documents in your own data centre and sending them to a cloud model as retrieved context means the context crosses the boundary on every request, along with whatever was in it. If the reason for keeping the data on-premises was that it must not leave, that architecture doesn't meet the requirement. The [hybrid AI scenario](https://www.alesanalytics.com/architecture/scenarios.md) shows the usual answer: classify each request, keep high-class data on an on-premises model, and deny the cloud route by default when the class is unknown.

## Real enterprise complexity

### How it accumulates

Each new application adds identities (human, workload and agent), network paths, data stores, a control plane (every SaaS product has one), policies and telemetry. Mergers and acquisitions add whole duplicate stacks: a second tenant, overlapping IP ranges, parallel identity providers and DNS namespaces. Regulation adds per-jurisdiction variants. Legacy adds constraints nobody can negotiate away: fixed IP addresses, Kerberos, licence dongles, mainframe batch windows.

### What you then see

- **Dependency explosion:** the number of edges grows faster than the number of nodes.
- **Hidden coupling:** a shared DNS forwarder, a shared KMS key, a shared CI identity.
- **Central dependencies nobody owns end to end.**
- **Ownership ambiguity at boundaries:** who owns the private DNS zone?
- **Inconsistent policy across estates,** such as Copilot DLP against workload DLP.
- **Duplicated identity and data:** two tenants, copies for analytics, AI indexes.
- **Configuration drift.**
- **Technical debt that turns out to be permission debt,** as oversharing becomes AI exposure.

### Organisational boundaries become technical ones

Systems tend to mirror the communication structure of the organisation that built them (Conway's law). Technically, that means ownership boundaries become API, tenancy, network and policy boundaries; interfaces between teams become trust boundaries that need explicit contracts; and a boundary without an owner becomes an unmonitored shared dependency. Model ownership explicitly, as an `owned-by` relationship, so that blast-radius and drift questions have someone to go to.

### Tenant-to-tenant migration

Moving from one Microsoft 365 tenant to another after an acquisition is a Type-1 identity migration:

- Object IDs change, so ACLs, Graph grants, agent identities, sharing links and labels all have to be remapped.
- Mailbox and OneDrive moves are rate-limited, so the migration takes as long as the throttling allows.
- During coexistence, authorization spans two identity providers.
- Search and AI indexes have to be rebuilt, and RSS and RCD settings don't migrate automatically.

The [design-review exercises](https://www.alesanalytics.com/architecture/exercises.md) include a full version of this case, with the order the steps have to happen in.

Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.

## Where to go next

- Previous: [Microsoft 365 as an Authorization Graph](https://www.alesanalytics.com/architecture/microsoft-365.md)
- Next: [AI Inference and the Model Gateway](https://www.alesanalytics.com/architecture/ai-serving-and-gateways.md)
- Overview and every page: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md)
- The whole site in one file: https://www.alesanalytics.com/llms-full.txt