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
The hybrid estate: what crosses the line between the data centre and the cloud
On-premises data centre
On-premises data centreActive Directory Domain Services
Kerberos, the legacy identity root
DNS forwarders
Conditional, one per private zone
Private cloud
vSphere, Hyper-V, Azure Local or OpenShift
Dedicated links
ExpressRoute
AWS Direct Connect
Cloud Interconnect
Azure
Microsoft Entra Connect
Synchronises AD to Entra ID
Azure DNS Private Resolver
Answers private endpoint names for on-premises
Azure Arc
A privileged management agent on every server
| 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 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 include a full version of this case, with the order the steps have to happen in.