Most migrations end in a hybrid state for a period, and some end there permanently. Designing for it beats treating it as a temporary embarrassment.
Some systems will not move: a licensing constraint, a hardware dependency, a data residency rule or simply a replacement already planned for two years' time. Designing the integration properly is better than treating it as transitional.
The risk in calling it temporary is that nobody invests in making it work well, and it then runs badly for years.
Establish reliable private connectivity — a dedicated link where volume and latency justify it, a well-configured VPN otherwise — and plan address space carefully to avoid overlap, which is painful to fix later.
Federate identity so people and workloads authenticate once. Two disconnected identity systems produce duplicated accounts, inconsistent offboarding and a genuine security gap.
Data gravity dominates hybrid design. Applications should generally run near their data, because chatty access across a network boundary is slow and expensive.
Two monitoring systems, two deployment pipelines and two on-call rotations produce gaps precisely at the boundary, which is where failures concentrate.
Aim for consistent tooling across both sides even where the underlying platforms differ. It is the difference between one estate operated coherently and two estates blaming each other.
Hybrid arrangements often persist because nobody decided otherwise. Making the decision explicit for each remaining workload — move, replace, or keep indefinitely — converts drift into a plan.
For anything kept indefinitely, invest accordingly: proper monitoring, a supported platform, a documented recovery plan. Systems in permanent limbo receive neither migration effort nor maintenance, which is the worst of both.
Revisit the list annually. Constraints change — a licence expires, a vendor releases a cloud version, a hardware dependency is retired — and workloads that could not move often become movable.
It carries the overhead of two environments, which is real. It is often still cheaper than forcing an unsuitable migration or replacing a system before its natural end of life.
Ideally one backup strategy with consistent retention and testing, even if the mechanisms differ. Divergent approaches are how gaps appear.
A dedicated private circuit where throughput and latency justify the cost; otherwise a well-monitored VPN with sensible redundancy. The failure mode to design for is the link being down, not being slow.
Keep reading
The overspend is rarely caused by the cloud itself. It is usually set in motion by three decisions taken in the first few weeks, often by people who did not realise they were making them.
All four run the same workloads competently. The decision usually follows existing commitments, data residency and the skills already in your team.
A meaningful share of cloud spend on a typical estate is recoverable without changing the architecture at all. Start there.
