Your Hybrid Cloud Is Probably a Stalled Migration With Better Branding

There is a reliable way to tell a designed hybrid estate from an accidental one. Ask who decided that the ERP stays on-premises, when they decided it, and what would change their mind. In a designed estate, someone answers within a minute. In an accidental estate, you get a history lesson: a migration started in 2022, the easy things moved, the hard things did not, the programme lost its sponsor, and at some point the remainder started being described as the hybrid strategy.

That relabelling is not harmless. A stalled migration and a deliberate hybrid architecture look identical on an inventory sheet and behave very differently under load, under audit, and under cost review. The difference is whether the split was chosen or inherited.

The tell is not the topology, it is the absence of a rule

Deliberate hybrid estates have a placement rule you can state out loud. Something like: systems of record with regulated data stay in the datacentre, anything that needs elastic compute goes to the cloud, and the boundary between them is a small number of documented interfaces. The rule may be wrong, but it exists, and it can be argued with.

Accidental hybrid has no rule. It has a residue. What stayed behind is whatever resisted a lift-and-shift: applications with hardcoded IP addresses, licences tied to physical cores, a database with a storage engine nobody wants to touch, and the two systems whose original developers left. That set has nothing in common except difficulty, which is why it cannot be reasoned about as a category. If your on-premises footprint is defined by "the things that were hard", you do not have an architecture, you have a backlog with a data centre attached.

Working out which one you are looking at is worth doing explicitly, and there is a short set of diagnostic questions that separate a stalled migration from a real hybrid design you can run through without a consultant in the room. It is also worth being precise about the vocabulary, because what hybrid cloud actually means in practice is narrower than the marketing use of the term: two environments running independently with no shared identity, network or data path are not a hybrid estate, they are two estates.

What the residue actually costs you

The costs of an unfinished migration are not obvious on a bill, because they show up as duplication and drag rather than as line items.

Symptom	Designed hybrid	Stalled migration
Identity	One directory, federated to both sides	Two directories, manual reconciliation, orphaned accounts
Networking	A small number of documented paths	VPN tunnels added ad hoc, nobody owns the route table
Data movement	Chosen and budgeted	Discovered when the egress bill arrives
Release process	One pipeline, two targets	Two pipelines, drifting apart
On-call	One rota with a runbook per boundary	Escalation depends on which engineer is awake
Capacity planning	Cloud elastic, on-prem sized to a known floor	On-prem sized for a peak that moved to the cloud two years ago

The last row is the expensive one and it is nearly always missed. Hardware refresh cycles are planned against historical peak. Once a chunk of demand has moved, the remaining on-premises workload runs on a fleet sized for a business that no longer exists there, and that overprovisioning gets renewed on a three or five year cycle without anyone re-deriving the number.

The identity row causes the incidents. Two directories in a hybrid estate means access reviews are performed twice, by different people, with different definitions of leaver. That is where audit findings come from.

Chatty boundaries are the real failure mode

When a migration stops halfway, it usually stops through an application, not around one. The web tier moves, the database does not. A reporting service moves, the source it queries does not. Every one of those becomes a request path that used to be a backplane hop and is now a wide-area round trip with an order of magnitude more latency and a failure mode that did not previously exist.

Applications built with a local database in mind make far more queries than their designers ever counted, because the queries were free. Move the caller and the query count becomes a bandwidth bill and a latency budget at the same time. This is the mechanism behind most hybrid performance complaints, and it is why the networking work that connecting on-premises systems to cloud actually requires is a design task rather than a procurement task. A dedicated interconnect fixes the throughput and does nothing about the round-trip count.

It also explains why the residue resists further migration. Each half-migrated application has quietly grown a dependency on the boundary, so moving the remaining half is no longer a migration, it is a rewrite of an interface that is now load-bearing.

Finish, formalise, or fund

There are only three honest positions for any workload sitting on the wrong side of a stalled migration.

1. Finish it. Move the remainder and delete the boundary. This is only cheap where the obstacle was scheduling rather than architecture.
2. Formalise it. Declare that this workload stays where it is, permanently, for a stated reason: latency to a factory floor, a licence that does not travel, data that cannot leave a jurisdiction, or a dataset large enough that moving it is not economic. Then design the interface properly instead of tolerating the one that emerged.
3. Fund it. If you can neither finish nor justify it, the workload is technical debt with a hosting cost. Say so, put a number against it, and let someone decide.

Most estates need all three, distributed across different systems. What they cannot survive is the fourth option, which is leaving every workload undecided and calling the aggregate a strategy.

The formalise path is the one worth most attention, because it is where the genuinely permanent decisions live. Some workloads should never move, and the reason is almost always mass rather than preference: once a dataset is large enough, everything that touches it wants to run beside it. Thinking clearly about data gravity and where workloads actually belong converts a vague reluctance to move something into a defensible placement rule, which is exactly what the accidental estate is missing.

What to do this quarter

Take the inventory and put every workload in one of the three buckets above. Do not allow a fourth. The exercise takes days, not months, and the value is not the classification itself but the arguments it forces: you will find workloads that three teams each assumed another team was going to move.

Then write the placement rule down. One page. Which side new systems default to, what makes something an exception, and who signs off. Without it, next year's projects will add to the residue at the same rate you are draining it.

If the boundary itself is the problem rather than the placement, that is a design job with a known shape, and it is the work our hybrid cloud integration practice exists to do: identity, network paths, data movement and the interfaces between the two halves, treated as one system rather than as leftovers.