Tales from other movers
Real and realistic migrations — what they did, what went wrong, and the one lesson worth stealing from each. They’re grouped into famous real-world moves, cloud-repatriation stories, and archetypal scenarios you’ll recognise.
Before a big trip, it helps to hear how other families moved — who packed smart, who forgot the cat, who spent too much. These are those stories, so you learn from other people’s moves instead of your own mistakes.
Public migration stories get simplified in the retelling. Treat the famous cases as illustrative — the shape is right, but verify specifics against primary sources before quoting numbers.
Real-world migrations
☺ Like you’re 10: These really happened — learn from how other people moved.
Famous moves you may have read about — the shape of each is what matters, so treat specifics as illustrative.
Netflix — The Seven-Year Rebuild (Refactor / Re-architect)
The situation. In August 2008, a database corruption at Netflix halted DVD shipments for three days. That fragile single-building 'monolith' (one giant bundled program) convinced Netflix it could not keep running its own Fort Rusty data center while streaming demand exploded. It set out to move entirely to AWS (Amazon Web Services, Amazon's cloud).
The move. A pure Refactor — a cloud-native rebuild, NOT a lift-and-shift. Netflix broke the monolith into hundreds of microservices, switched to NoSQL databases (databases built to scale across many machines rather than one big server), denormalized its data model, and adopted continuous delivery (shipping software changes frequently and automatically). It even built resilience tools like Chaos Monkey that randomly kill servers to prove the system survives. Netflix publicly explained why it refused a simple lift-and-shift: doing so would just 'move all the problems and limitations of the data center along with it.'
Outcome. The migration ran from 2008 to early January 2016 — about seven years. Over that span Netflix grew roughly eight times more streaming members, expanded to over 130 countries, reached higher availability (approaching 'four nines,' i.e. ~99.99% uptime), and drove cost per streaming start down to a fraction of the data-center cost.
Refactoring is the slowest and most expensive R, but for a core, fast-growing product it can pay off enormously. And heed Netflix's warning — don't haul your old junk to the new house. Gizmo the Gremlin loves it when you lift-and-shift a mess and call it modernization.
Capital One — A Bank Goes All-In and Closes the Basement
The situation. Capital One, a major U.S. bank in a heavily regulated industry, decided it needed cloud speed and scale to compete in a digital-first world. Over roughly eight years it migrated its estate and, in 2020, closed its last data centers — going 'all-in' on AWS with no data centers of its own, a landmark move for a large bank.
The move. A portfolio mix across the 7 Rs: rehost some apps, replatform and refactor others, retire dead ones — combined with heavy investment in security automation, governance tooling (Capital One open-sourced Cloud Custodian, a policy-enforcement tool), and a very large in-house engineering organization.
Outcome. Capital One exited eight on-premises data centers and became a widely cited reference for cloud adoption in a regulated industry. Closing its final data centers even involved recycling tons of copper, steel, and millions of feet of cable.
Even highly regulated organizations can go all-in — but security and compliance must be engineered in from the start. The cloud operates on a shared responsibility model: the provider secures the cloud itself, while you remain responsible for securing what you put in it. (Capital One's well-publicized 2019 data breach underscored exactly this point.)
GE — The Giant's Ambitious Consolidation
The situation. General Electric, a sprawling industrial conglomerate with dozens of data centers and thousands of aging applications, set out around 2016 to migrate at massive scale to AWS and dramatically shrink its data-center footprint (a widely reported goal was cutting from about 34 data centers down to roughly 4). It also moved Predix, its industrial Internet-of-Things platform, to AWS to analyze sensor data from power-plant equipment.
The move. Large-scale portfolio migration — rehost and replatform many workloads at volume using a 'migration factory' style approach (a repeatable assembly-line process for moving many apps), plus refactoring for the Predix analytics platform. GE reported migrating on the order of 9,000 workloads.
Outcome. GE achieved substantial data-center consolidation and real analytics results — the cloud version of Predix ingested data from roughly 900 customer sites and streamed on the order of 500,000 sensor records per second. GE later restructured and scaled back some of its broader digital-platform ambitions.
Migrating at enormous scale is achievable, but pairing 'move the whole house' with 'and also launch a brand-new platform business' stacks risk on risk. Keep the migration goal and the reinvention goal honestly separated so one doesn't sink the other.
Cloud repatriation stories
☺ Like you’re 10: Sometimes a family moves back out of the apartment building — on purpose, with a plan — and it works out great.
Moving back from public cloud to owned infrastructure — a mature, deliberate choice, not a failure. The mechanics of leaving a provider are covered in Cloud-to-Cloud, Hybrid & Repatriation.
Dropbox — The Reverse Move (Cloud Repatriation)
The situation. Dropbox stored customer files on Amazon S3 (AWS's object-storage service). At hundreds of petabytes of scale, a company whose core product IS storage found that renting storage was more costly than owning it — and that owning it could become a competitive advantage.
The move. Cloud repatriation — moving workloads back out of public cloud. Beginning in 2013, Dropbox's 'Magic Pocket' project built custom storage hardware and software. Between roughly 2015 and 2016 it moved about 90% of an estimated 600 petabytes of user data onto its own infrastructure. Critically, it stayed hybrid — continuing to use S3 in regions and countries where it lacked the scale to justify building its own.
Outcome. Per Dropbox's pre-IPO filing with the U.S. Securities and Exchange Commission (SEC), the move saved roughly $75 million over two years and coincided with a substantial improvement in gross margins. The custom system was engineered for extreme durability (on the order of twelve nines).
The cloud is not automatically cheaper. At very large, steady, predictable scale — especially when infrastructure is your core competency — owning can win. But note Dropbox stayed hybrid: repatriation is rarely all-or-nothing.
37signals (Basecamp & HEY) — Leaving the Cloud on Price and Principle
The situation. 37signals, a small, profitable software company running steady and predictable workloads, found its cloud bill (about $3.2 million per year on AWS) hard to justify for apps that rarely needed sudden elastic bursts of capacity. In late 2022 its CTO, David Heinemeier Hansson (DHH), publicly announced the company would leave the cloud.
The move. Cloud repatriation. During 2023, 37signals moved Basecamp, HEY, and other apps onto their own servers housed in colocation data centers (facilities where you rent rack space and power but own the machines yourself) — reportedly around $600,000 of hardware — without adding headcount, using open-source tooling like their Kamal deployer.
Outcome. 37signals reported cutting its cloud bill dramatically (from roughly $3.2M/year toward the low-$1M range) and projected savings on the order of $7 million over five years.
For stable, predictable workloads at a company that values control, the cloud's pay-per-use premium may not pay off. Match the tool to the workload — sometimes Retain (keep it as-is) or full repatriation is the smart, not the lazy, choice.
Archetypal scenarios you’ll recognise
☺ Like you’re 10: Made-up but realistic examples, so you can practise spotting the right move.
Composite, true-to-life situations that map cleanly onto the patterns in this course.
Archetype — The Retailer Racing Black Friday (Rehost + Replatform)
The situation. ARCHETYPE (illustrative, not a specific company). An online retailer's on-prem servers buckle every holiday peak. With Black Friday only months away, there is no time for a ground-up rebuild — the business needs elasticity fast (elasticity = the ability to automatically add servers when traffic surges and remove them when it drops, paying only for what you use).
The move. Rehost most applications as-is to get onto the cloud quickly, then Replatform the specific pieces that block scaling — for example, moving the database onto a managed service (one the cloud provider runs and maintains for you) and adding auto-scaling plus a load balancer (which spreads incoming traffic across many servers).
Outcome. The retailer survives the traffic spike: capacity scales up for the weekend and back down afterward, avoiding both the annual meltdown and the cost of owning peak-sized hardware year-round.
When a hard deadline looms, speed-to-value beats perfection. Rehost first to capture elasticity, then modernize later. Don't let Gizmo talk you into a full refactor the week before your busiest day of the year.
Archetype — The Bank Rebuilding a Core System (Refactor + Strangler Fig)
The situation. ARCHETYPE (illustrative). A bank's decades-old core banking application — a monolith that moves real money — is expensive, brittle, and slow to change, yet it cannot suffer downtime.
The move. Refactor toward cloud-native microservices using the strangler fig pattern, a technique named by software thinker Martin Fowler: you build new services around the old system and gradually route traffic to them, piece by piece, until the old system can finally be switched off — instead of a risky overnight rewrite. (The name comes from strangler fig vines that grow around a tree and slowly replace it.)
Outcome. Modernization proceeds incrementally and safely, with old and new running side by side; feature delivery speeds up as functionality shifts to the new services.
For mission-critical systems, refactor gradually, never in one dangerous 'big bang' night. The strangler fig lets you replace the engine while the car keeps driving — exactly the caution Timmy preaches and Gizmo hates.
Archetype — The Startup Going Multicloud
The situation. ARCHETYPE (illustrative). A fast-growing startup wants to avoid vendor lock-in (becoming so dependent on one provider that switching later is painful and costly), needs a specialized AI service offered best by one cloud, and has customers whose data-residency rules are served best by another.
The move. A deliberate multicloud strategy — intentionally using more than one cloud provider (for example, AWS plus Google Cloud). This is usually built cloud-native and containerized (apps packaged with tools like Docker and orchestrated by Kubernetes so they run similarly on any provider). Note the contrast: multicloud = two or more public clouds; hybrid cloud = mixing public cloud with your own on-prem or private infrastructure.
Outcome. The startup gains flexibility, negotiating leverage, and best-of-breed services — at the cost of higher operational overhead: duplicated skills, harder cost tracking, cross-cloud networking, and extra egress fees.
Multicloud buys resilience and leverage but taxes you in complexity. Do it on purpose for concrete reasons — not by accident because teams drifted onto different clouds.
Archetype — Cloud-to-Cloud After an Acquisition (Relocate)
The situation. ARCHETYPE (illustrative). A company standardized on Microsoft Azure acquires a startup that runs entirely on AWS. Leadership wants to consolidate onto one provider to cut cost, simplify operations, and unify security.
The move. Relocate leads — moving whole environments (often VMware-based or containerized workloads) with minimal changes — supplemented by rehost or replatform where services don't map cleanly. This is a cloud-to-cloud migration (moving between two cloud providers, not from on-prem to cloud).
Outcome. A consolidated platform with simpler operations — but the move itself can be slow and surprisingly expensive, so some teams first choose Retain (leave the acquired system running where it is) and integrate, relocating deliberately later.
Cloud-to-cloud is neither free nor trivial: egress fees for leaving the source cloud, differing managed-service equivalents, and identity/permission remapping all bite. Sometimes the right first answer is Retain-and-integrate, then Relocate on a plan — not in a panic.
Pick any two stories above. For each: which of the 7 R’s did they lean on, what was the single biggest risk, and what would you do differently? If you can answer that, the case has done its job.