Cloud-to-Cloud, Hybrid & Repatriation
Most of this course assumes you're moving from an old data center up to the cloud. But real life has more directions than that. Sometimes you move from one cloud to another. Sometimes you keep one foot on the ground and one in the sky. And sometimes — surprisingly often — you move things back down. This page maps all the extra roads.
Imagine your family already moved from your old house (Fort Rusty) into an apartment in Cloudville. But maybe the AWS district got expensive, or the Azure district has a better school. So you move across town to a new apartment — that's cloud-to-cloud. Or you keep a little storage unit back at the old house — that's hybrid. Or you decide the apartment was too pricey and move some boxes back home — that's repatriation. Moving isn't a one-way street.
The move isn't always up
☺ Like you're 10: Up to the cloud is just the most famous trip. There are three other trips people take all the time, and each one needs its own plan.
When people say "migration," they usually mean the classic journey: from on-premises (your own servers in your own building — "on-prem" for short) up to a public cloud. You can revisit that whole trip on what is migration and the migration journey. But the cloud world has grown up, and now teams routinely take three other kinds of trips:
- Cloud-to-cloud — moving a workload from one public cloud provider to another (for example, from AWS to Azure, or Google Cloud to AWS).
- Hybrid cloud — deliberately running on-prem and public cloud together as one connected system, and staying that way.
- Repatriation — moving a workload back from the public cloud to on-premises or a private data center.
None of these is exotic or a sign that something went wrong. They're normal tools in a mature toolbox. Let's walk each road.
Direction is a per-workload decision, not a company-wide one. The same estate can be sending one app up to the cloud, moving a second across clouds, keeping a third hybrid, and pulling a fourth back home — all in the same quarter. Each of the four roads below is its own project with its own plan.
Cloud-to-cloud: moving across town
☺ Like you're 10: You already live in Cloudville, but you're switching to a different district. The furniture is yours, but the new apartment has different plugs, different locks, and a toll to carry your boxes out the door.
Cloud-to-cloud migration means relocating applications and data from one cloud provider to another — for example off AWS and onto Azure, or from Google Cloud onto AWS. Both ends are already "cloud," but that shared word hides how different the two houses really are on the inside.
Why teams do it
☺ Like you're 10: Nobody switches apartments for no reason — there's always a push (something got worse where you are) or a pull (somewhere else got better).
Cloud-to-cloud moves are deliberate. Teams choose to relocate for concrete reasons:
- Cost — another provider offers better pricing for your particular workload, or you've negotiated a better commitment deal.
- Better services or features — one cloud has a managed service (say, a specific AI, analytics, or database offering) that fits your needs better.
- Mergers and acquisitions — two companies combine, and one has to move onto the other's cloud to consolidate.
- Reducing lock-in — vendor lock-in is when your setup depends so heavily on one provider's proprietary tools that leaving becomes painful. Some teams move partly to prove they can, and to stay portable.
- Compliance and data residency — data residency means the legal requirement that certain data physically stay in a specific country or region. If your provider doesn't have a region where the law demands, you may have to switch.
- Exiting a provider — a strategic decision to leave one vendor entirely.
Notice how these split into two flavors: a pull toward something better on the other cloud (a feature, a price, a required region) and a push away from where you are (lock-in, an M&A mandate, a planned exit). Naming which one is actually driving the move keeps the project honest — a vague "the grass looks greener" rarely survives the egress bill you'll meet below.
The challenges: why cloud-to-cloud is harder than it looks
☺ Like you're 10: The furniture is yours, but the new place has different plugs and different locks — and there's a toll just to carry your boxes out the door.
Here's the trap: people assume "cloud to cloud" is easy because both ends are already cloud. Often it's the opposite. The challenges are real and specific:
| Challenge | What it means |
|---|---|
| Managed services don't map 1:1 | Provider-specific managed services (databases, queues, serverless functions the cloud runs for you) rarely have an identical twin on another cloud. The closest match behaves differently. |
| Different identity models | IAM (Identity and Access Management — the system of who is allowed to do what) is designed differently on each cloud. Permissions and roles must be rebuilt, not copied. |
| Networking differences | Virtual networks, load balancers, and firewall rules use different names and defaults on each provider. |
| Egress fees | Egress fees are charges for moving data out of a cloud. Pulling terabytes out to hand them to a competitor can cost real money — the "toll at the door." |
| Retooling IaC | IaC (Infrastructure as Code — defining your servers and networks in text files instead of clicking buttons) is usually written for one cloud. It needs rewriting or a portable rework. |
| Retraining teams | Your engineers' hard-won knowledge of one cloud's consoles and quirks doesn't fully transfer. People need time to learn. |
The deeper you used a cloud's proprietary managed services, the harder cloud-to-cloud gets. A workload built on portable, open technology moves far more easily than one wired into one vendor's special sauce.
Put together, these mean a cloud-to-cloud move is rarely a simple copy. The compute might move cleanly, but the surroundings — identity, networking, the managed services, and the IaC that wires them together — usually have to be rebuilt for the destination. Budget for that rebuild and retraining, not just the data copy.
A practical approach
☺ Like you're 10: Treat it like a real move with a real plan — don't just shove everything in one truck and hope the new plugs fit.
Ellie and Benny handle a cloud-to-cloud move much like any other migration — the same phased, batch-by-batch discipline from wave planning — with a few twists:
- Re-assess with the 7 R's. Treat each workload fresh. Some you'll rehost, some you'll re-architect to fit the new cloud's services. Full refresher on the 7 R's.
- Prefer portable technology. Containers (a way to package an app with everything it needs so it runs the same anywhere) and open standards travel between clouds with far less friction. See modernization.
- Mind the egress. Plan data transfer carefully — timing, method, and cost. Ellie never drops a box, but she also checks the toll before she leaves. More on moving data safely in data migration.
These pull in opposite directions, and that tension is the real decision. Re-architecting each workload onto the new cloud's native services gives you the best fit and price there — but it re-anchors you to that vendor. Leaning on portable containers keeps you free to move again later, at the cost of not using either cloud's fanciest managed offerings. There's no free lunch, only an honest choice per workload.
Hybrid cloud: one foot on the ground
☺ Like you're 10: You live in the Cloudville apartment, but you keep a storage unit back at the old house — and there's a private tunnel between them so it all feels like one home.
What hybrid cloud is
Hybrid cloud means running on-premises infrastructure and public cloud together, connected so they behave as a single system. It's not a half-finished migration — for many organizations it's the intended, permanent design. The goal isn't to finish moving; it's to put each workload wherever it truly belongs and let the two halves cooperate as one.
Connectivity: the private bridge
The two halves are joined by dedicated connectivity: a private, reliable network link (often a VPN or a dedicated connection) so data and apps flow between them securely. Without that bridge the on-prem and cloud sides are just two separate islands; with it, they act as one network where an app on either side can reach the data it needs. That bridge-building is exactly Pip the Hummingbird's job on architecture patterns.
Common use cases
☺ Like you're 10: Some things have a real reason to stay near the old house — the law, the clock, or just wanting to move carefully.
Common reasons to run hybrid on purpose:
- Regulated data. Some data must legally stay on-prem or in a specific place, while everything else enjoys the cloud.
- Latency. A factory floor or hospital may need computing physically close by so responses are instant — the cloud is too far away in milliseconds.
- Gradual migration. Hybrid lets you move piece by piece over months or years, keeping the old and new halves working together the whole time. It's a safety-first path — Timmy the Turtle approves.
That last case is worth underlining: nearly every large migration passes through a hybrid phase, even when the end goal is all-cloud. While the waves are still landing, some apps live in the cloud and some are still in Fort Rusty — and they have to keep talking over that private bridge until the final wave arrives.
Multi-cloud: living in two districts at once
☺ Like you're 10: Some families rent apartments in two districts on purpose — one has a great pool, the other a great school. Handy, but now you're paying two rents and learning two sets of house rules.
Why go multi-cloud
Multi-cloud means deliberately using two or more public cloud providers at the same time. (Hybrid is on-prem plus cloud; multi-cloud is cloud plus cloud.) Teams choose it for:
- Resilience. If one provider has an outage, workloads on another keep running.
- Best-of-breed. Pick each provider's strongest service — one cloud's data tools, another's machine learning.
- Avoiding lock-in. Spreading across vendors keeps your bargaining power and your options open.
Learning one provider well makes the second far less daunting: the AWS, Azure, and Google Cloud tours each teach the same ideas under different names, and that cross-fluency is exactly what a multi-cloud team lives on.
The multi-cloud tax
☺ Like you're 10: Two apartments means two rents, two sets of keys, and two lots of rules to remember — the convenience isn't free.
Multi-cloud has a price called the multi-cloud tax: extra complexity, more moving parts to secure and monitor, and teams that must master several clouds instead of one. The benefits are real, but so is the overhead — go multi-cloud for a reason, not for a buzzword.
The tax is mostly paid in skills and tooling: separate identity systems to keep in sync, separate monitoring and billing to reconcile, and engineers who have to stay fluent in more than one cloud at once. That's why best-of-breed only pays off when the benefit of each provider's standout service clearly outweighs the standing cost of running both.
Repatriation: moving back home
☺ Like you're 10: After a while, some families realize the fancy apartment costs more than it's worth for certain things — so they carry those boxes back to the old house. That's not a failure. That's just being smart with money.
What repatriation is
Repatriation (also called cloud repatriation) means moving workloads back from the public cloud to on-premises or a private data center. It's a mature, well-documented trend — not an admission of defeat. Sometimes the cloud is genuinely the wrong home for a specific workload, and moving it back is the grown-up decision.
Why teams repatriate
☺ Like you're 10: Usually it comes down to money, speed, or wanting to keep something safely in your own hands.
Common drivers:
- Cost at scale. For large, steady, predictable workloads, owning hardware can beat renting it month after month. The cloud's pay-as-you-go magic shines for variable demand, less so for a big constant load.
- Performance. Certain heavy or specialized workloads run faster or more consistently on dedicated hardware you control.
- Data control. Keeping sensitive data fully in-house for security or governance reasons.
- Compliance. New regulations may require data to live somewhere the cloud can't satisfy.
Repatriation is usually selective — a few specific workloads come home while the rest stay in the cloud, which is really just hybrid by another name. The lesson: the cloud is a choice per workload, not a religion. Do the honest math (Sol the Sloth's specialty — see provisions for TCO) and let the numbers decide.
There is no single "right" direction. Up, across, hybrid, and back are all valid moves. The mature question isn't "cloud or not?" — it's "what is the right home for this workload, given cost, performance, compliance, and portability?"
Gizmo: Cloud-to-cloud? Easy! It's already in a cloud — just copy-paste it to the other one. Ten minutes, tops!
Ellie: Ah. And the managed database that only exists on Cloud A? The IAM roles? The egress bill for pulling ten terabytes out the door?
Benny: And every line of infrastructure code is written for Cloud A's networking. I'd be rebuilding the plumbing from scratch, Gizmo.
Foxy: Wait — so is it easier if we'd used containers from the start?
Mira: Much easier! Portable tech travels between clouds like a butterfly between flowers. Lock-in is what makes it heavy.
Timmy: Fact-check: and if the numbers say bring it back home instead? That's repatriation — a real, smart strategy, not a defeat.
Pick one app you know (a website, a game backend, a database). For that one app, sketch a quick table: (1) what would make you move it to a different cloud? (2) what proprietary managed services would be hard to replace? (3) would you ever bring it back on-prem — and what would trigger that? You've just done a mini portability assessment.
1. Name three reasons a team might do a cloud-to-cloud migration. 2. Why don't managed services map 1:1 between clouds, and what is an egress fee? 3. What's the difference between hybrid cloud and multi-cloud? 4. What is repatriation, and name one driver for it?
Check your answers
- Any three of: cost, better services/features, mergers & acquisitions, reducing vendor lock-in, compliance/data residency, or exiting a provider.
- Each cloud builds its own proprietary managed services (databases, queues, functions) that behave differently, so there's no identical twin on another cloud. An egress fee is the charge a provider bills for moving data out of its cloud — the "toll at the door."
- Hybrid cloud = on-premises plus public cloud connected as one system. Multi-cloud = using two or more public cloud providers together. (Hybrid mixes ground and sky; multi-cloud mixes sky and sky.)
- Repatriation is moving workloads back from public cloud to on-prem or a private data center. Drivers include cost at scale, performance, data control, or compliance — and it's a mature strategy, not a failure.