The question this answers
When should some of the system stay on-premises, and what does connecting the two halves actually commit us to?
The order-management system runs on hardware in a facility the company owns, talks to machines on the factory floor over a local network, and is not going anywhere this decade. The new customer portal should be built in the cloud. The two need to exchange orders.
One logical system spanning two environments: private, non-internet connectivity between them, consistent addressing, and the ability to place each workload where its constraint says it belongs rather than where a strategy slide says.
The four honest reasons, and the shape they produce
Hybrid is much easier to justify than multi-cloud, because the reasons are usually physical rather than political. Legacy systems: software that requires specific hardware, an unsupported operating system, a licence bound to a physical machine, or a vendor appliance nobody will re-certify. Compliance and sovereignty: a regulator or a customer contract requiring that certain data sit on hardware you control. Data locality and latency: a workload that must be milliseconds from equipment — factory floor, hospital, retail store, trading venue — where a round trip to a region is a functional failure, not a performance one. Gradual migration: the honest and time-boxed case, where hybrid is the intermediate state of a move, not a destination.
Notice how different the last one is. Migration hybrid has an end date and should have a sunset plan attached from day one, or it becomes permanent by default — which is the most common way organizations end up operating two platforms nobody chose. The other three are stable architectures, and should be designed as such: not as a temporary compromise, but as a deliberate placement of each workload against its actual constraint.
The shape that results is almost always the same. A private link — a dedicated circuit or a VPN over the internet — joins the on-premises network to the cloud virtual network. Address ranges are planned so they do not overlap, because two sites that both chose 10.0.0.0/16 cannot be routed together without translation, and discovering this after both are in production is a genuinely painful week. Identity is federated so people and workloads have one directory rather than two. And a small number of well-chosen integration points carry traffic across the seam.
The link is the system now
In a hybrid architecture, the private connection stops being plumbing and becomes the component whose failure defines your worst day. It has finite, provisioned bandwidth — unlike cloud networking, you cannot scale it in an afternoon; a dedicated circuit is ordered from a carrier and takes weeks. It has real latency determined by physical distance, which no amount of tuning removes. And it is a single path unless you deliberately paid for two, ideally through different physical routes and different carriers.
The failure mode that surprises teams is not the link going down — that is obvious and alarms fire. It is the link *degrading*: packet loss or congestion that turns a 5 ms hop into a 400 ms hop with occasional resets. Every synchronous call across the seam then inherits that latency, connection pools fill with slow calls, thread pools exhaust, and services that never touch the link start timing out because they were waiting behind something that did. Meanwhile both sites report healthy hosts. This is why the design rule matters so much: cross the seam asynchronously wherever you possibly can. A queue at the boundary turns a link outage into a growing backlog that drains afterwards, instead of a customer-facing failure.
The second design rule is about data gravity. Whichever side holds the authoritative data pulls the compute toward it. A cloud service that makes six synchronous queries against an on-premises database per page render will be slow forever, and no caching layer fully rescues it. Either move the data, or move the computation to the data, or replicate a read-only copy across the seam and accept the staleness explicitly. Pretending the link is a local network is the single most common hybrid design error.
| Workload characteristic | Where it belongs | Why | What crosses the seam |
|---|---|---|---|
| Millisecond dependency on local equipment | On-premises | Physics — the round trip cannot be optimized away | Aggregates and events, asynchronously |
| Regulated data with a residency obligation | On-premises | Contractual or legal, not technical | Derived, de-identified data only |
| Licence bound to specific hardware | On-premises | Commercial constraint until renegotiated | An API surface, versioned |
| Public-facing, spiky, stateless | Cloud | Elasticity and edge presence you cannot build on-prem | Requests inward, async |
| Batch analytics over historical data | Cloud | Elastic compute, cheap object storage | A scheduled bulk export, not live queries |
| New services with no legacy dependency | Cloud | No reason to add to the on-prem estate | Nothing, ideally |
| Chatty service that queries the legacy database per request | Neither — redesign | It will be slow wherever you put it | Fix the coupling before choosing a side |
Two operating models, one team
The cost people forecast is the circuit. The cost that actually bites is that the team now operates two fundamentally different models simultaneously. On-premises has capacity you bought eighteen months ago, a procurement lead time measured in weeks, hardware failures that require a person in a building, firmware and hypervisor patching, and a fixed cost that does not care about load. The cloud side has elastic capacity, API-driven provisioning, no hardware to touch, and a variable bill. Neither is worse; they are simply different disciplines, and the same on-call engineer is expected to hold both.
This shows up in unglamorous places. Infrastructure-as-code covers the cloud side and probably not the on-premises side, so half the estate is reproducible and half is a machine somebody configured. Monitoring is often two systems with two alerting paths. Capacity planning is a forecast on one side and an autoscaling policy on the other. Backup and restore procedures differ in kind. And the security model has to reconcile a perimeter-shaped on-premises network with an identity-shaped cloud one — see The IAM Model and Infrastructure Trust Boundaries.
None of this is an argument against hybrid; the constraints that produce it are usually real and non-negotiable. It is an argument for treating it as a permanent architecture with a budget, an owner and a documented seam, rather than as an unfinished migration everyone hopes will resolve itself. And if the reason *is* migration, put the sunset date in writing on the first day, because that is the only thing that stops the intermediate state from becoming the final one. See Migrating a System to the Cloud.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- Four legitimate reasons: legacy systems, compliance, data locality, and gradual migration — the last one needs a sunset date on day one.
- Plan non-overlapping address ranges before either side is in production; discovering the overlap later is a painful and avoidable project.
- Cross the seam asynchronously. A queue at the boundary turns a link outage into a backlog rather than a customer-facing failure.
- A degraded link is worse than a dead one: latency propagates into unrelated services while both sites report healthy.
- Data gravity decides placement — a cloud service making synchronous queries to an on-premises database will be slow forever.
- The real cost is operating two models at once, not the circuit; budget for it explicitly.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • A dedicated circuit or an IPsec VPN joins the corporate network to the cloud virtual network, with routes exchanged so both sides can address each other privately.
- • Address ranges are allocated from one plan across both environments so no subnet overlaps and no translation is needed.
- • DNS is made consistent in both directions — cloud workloads resolve on-premises names and vice versa — usually with conditional forwarding.
- • Identity is federated to one directory, so a person or a workload has one identity with different authorizations per environment.
- • Integration points are deliberately few and mostly asynchronous: a queue, an event stream or a scheduled export rather than live cross-seam queries.
- • Monitoring from both sides is shipped to one pipeline, including synthetic probes that traverse the link itself.
- • You still own the on-premises half completely: hardware, firmware, hypervisor, capacity, physical access and the spare parts cupboard.
- • You own the link: its bandwidth forecast, its redundancy, its carrier relationship and the renewal that takes weeks to change.
- • You own DNS and routing consistency across both sides — the most common cause of "it works from the office but not from the cloud".
- • You own two patching cadences, two backup regimes and two restore procedures, and both need testing. See Restore Testing.
- • You own the seam contract: which calls are allowed to cross, synchronously or not, and who reviews new ones.
- • You own the sunset plan if the justification was migration, including the date and the owner.
- • Link outage with a synchronous dependency across it: user-facing requests fail even though both environments are entirely healthy.
- • Link degradation — loss and jitter rather than a clean failure — propagating latency into services that never touch the seam.
- • Overlapping address ranges discovered at connection time, forcing translation or a re-addressing project.
- • DNS resolving differently on each side, producing intermittent failures that follow no pattern anyone can see.
- • On-premises capacity exhausted with a six-week procurement lead time, while the cloud half could have absorbed it in seconds.
- • A "temporary" migration hybrid that quietly becomes permanent, with two platforms funded by an ambiguity nobody owns.
- • The cloud half scales elastically; the on-premises half scales by purchase order, and the mismatch shows up as the whole system scaling at the slower rate.
- • Link bandwidth is provisioned, not elastic — it is the dimension that runs out first, and the slowest to change.
- • Cross-seam chattiness scales worse than traffic: every added integration point multiplies both latency exposure and transfer cost.
- • Read replicas on the cloud side scale reads without scaling the link, at the price of explicit staleness.
- • The link is a trust boundary, not an extension of the LAN: authenticate and encrypt across it, and do not grant on-premises-level trust to cloud workloads by virtue of the route existing.
- • Segment what each side may reach — a compromised cloud container should not have a flat path to the whole corporate network, which is the default if you simply route the two together.
- • Federated identity is a benefit and a concentration: the directory now authenticates access to both estates, so its own protection is critical.
- • On-premises firewalls and cloud security groups express policy differently; keep one intent document, or the two drift.
- • Data classified as on-premises-only must be prevented from crossing, not merely expected not to — enforce it at the integration point.
- • The circuit is a fixed monthly cost independent of use, plus a second one if you took redundancy seriously.
- • Transfer across the seam is metered and direction-dependent; replication and bulk exports dominate it.
- • On-premises capacity is a fixed cost sized for peak, which is precisely the property cloud elasticity exists to avoid.
- • Dual operations — two toolchains, two runbooks, two skill sets — is usually the largest item and the least forecast.
- • A migration hybrid pays for both environments simultaneously for the whole overlap period, which is the number that should drive the sunset date.
- • Link availability, throughput against provisioned bandwidth, latency and packet loss — as a first-class service, not as a network footnote.
- • A synthetic probe that crosses the seam end to end, because it is the only check that exercises what actually breaks.
- • Queue depth at the integration points, which is where a link problem shows up as a business metric.
- • Cross-seam call counts by service, as the early warning that someone added a synchronous dependency.
- • The signal that lies: host and application health on both sides, which stay green through a total link failure because neither environment is unwell.
- • All cloud, with the legacy system replaced or re-hosted. If the constraint is a licence or an unsupported OS rather than physics, buying out the constraint is sometimes cheaper than operating a hybrid forever.
- • All on-premises. If the workload is steady, the hardware is bought and there is no elasticity requirement, cloud is not automatically better. See On-Premises vs Cloud.
- • Complete separation with a documented file or API exchange, and no private network at all. Many "hybrid" requirements are satisfied by a nightly export over an authenticated endpoint, which removes the circuit, the routing and the whole class of seam failures.
- • Edge compute at the site for the latency-bound part only, with everything else in the cloud — a narrower seam than a full corporate interconnect.
- • A time-boxed migration hybrid with a contractual sunset date, when the end state really is all-cloud.
- • Buys correct placement for genuinely constrained workloads; costs a permanent second operating model.
- • The private link buys private, predictable connectivity; costs a fixed charge, weeks of lead time to change, and a new top-priority failure domain.
- • Async integration buys resilience to link failure; costs eventual consistency and the design work to make every crossing retryable.
- • Federated identity buys one directory; costs a single high-value target authenticating both estates.
What people believe, and what is true
Once the circuit is up, the cloud is just another data center.
It has a different latency, a finite provisioned bandwidth, a metered transfer charge and a different failure profile. Designing as if it were a LAN produces the classic chatty-cross-seam architecture.
Hybrid is a transitional state.
Sometimes. Legacy hardware constraints, sovereignty requirements and physical latency are permanent, and the resulting architecture deserves to be designed and funded as permanent.
The risk is the link going down.
A clean outage is detected and alarmed. A degraded link is worse: latency propagates into services that never touch the seam, and every dashboard on both sides stays green.