Repatriation is the most drastic cost lever and the most debated. Six cases sit at the far end of the spectrum: 37signals (a $3.2M-a-year cloud bill cut to $1.3M, with $10M+ projected over five years), Dropbox (a $74.6M operating-expense reduction over two years from building its own storage system), X (a claimed 60% monthly cut, unverified), Prerender.io ($1M to $200K a year), OneUptime (a 28-node cluster moved to bare metal for $230K a year saved) and GEICO, the cautionary tale, whose cloud bills grew 2.5x after a decade of lift-and-shift. They are included not as a recommendation but as calibration: they show which workload shapes and organisational conditions make owned infrastructure cheaper, and what happens when a migration skips modernisation. This part ends with a scoring checklist and a total-cost-of-ownership model you can fill in before you consider leaving.
Get the full report. This series expands the research report Cutting the AWS Bill: 28 Case Studies (53 pages, PDF, 780 KB). One click starts the download.
⬇ Download PDF1. Repatriation as calibration, not a recommendation
Every previous part accepts that you run on AWS and asks how to pay less for it. This one asks the question underneath: what is the cloud premium actually buying you? The answer is different for a company whose load is steady and predictable and which already runs racks (37signals), for one whose entire product is storage (Dropbox), for one that is a bandwidth-and-storage business (Prerender.io), and for one that lifted and shifted a legacy estate (GEICO).
The cases are included as calibration, not as a nudge to leave. They show which workload shapes and organisational conditions make owned infrastructure cheaper, and what happens when cloud migrations skip modernisation. Pattern P14 in Part 1 states the principle: know what the cloud premium is buying. Elasticity, managed operations and speed are worth paying for; for steady, storage-heavy loads with in-house skills they may not be.
Fig. 1 - Fit for repatriation depends on the workload and on operations skills, not on ideology.
2. CS-23 37signals (Basecamp, HEY): the most public cloud exit
| Field | Detail |
|---|---|
| Business | SaaS (Basecamp, HEY and older apps) |
| Before | $3.2M a year cloud run-rate (2022) |
| Hardware | ~$700K of Dell servers; 18 PB Pure Storage |
| Timeline | 2022-2025 |
| Result | $10M+ projected savings over five years |
37signals argued it was paying a large premium for elasticity it rarely used: its load was steady and predictable, and it already had data-centre space and operations skills.
- Moved compute home. Seven cloud applications, including HEY, were moved from AWS to owned hardware in existing colocation racks. About $700K of new Dell servers was fully recouped during 2023 as cloud commitments rolled off.
- Fit inside existing power and racks. Squeezing new hardware into existing rack and power allowances made savings larger than the original $7M five-year estimate.
- Then left S3. The remaining ~10 PB in S3 (about $1.5M a year) is being moved to a dual-data-centre Pure Storage array with 18 PB of capacity costing under $200K per year to run. AWS waived an egress bill of about $250K under its exit-fee policy.
The thinking pattern. Compare the cloud's premium with what it buys you. For steady, predictable workloads run by a team that can operate hardware, elasticity is an insurance policy you may not need.
Lessons to steal. Model total cost including people, power, hardware refresh and redundancy, not just server prices. Exit costs have fallen: since March 2024 AWS waives data-transfer-out fees for customers moving data off AWS (on request). Wait for commitments to expire, because stranded RIs and Savings Plans erase early savings.
The payback maths is the report's own example: roughly $700K of hardware against about $160K per month of reduced cloud spend, recouped within 2023. That is a payback of about four to five months, which puts it in the "easy yes" band from Part 3's rule of thumb (under six months is usually a yes; above eighteen needs a strategic reason).
3. CS-24 Dropbox: Magic Pocket, when storage is the product
| Field | Detail |
|---|---|
| Business | Cloud file storage |
| Change | Most user data from S3 to custom storage in colocation |
| Completed | Q4 2016 |
| Evidence | 2018 S-1 filing |
| Result | $74.6M operating-expense reduction over two years |
Dropbox originally stored file contents in S3 and metadata in its own data centres. As storage became the core of the business, it built its own storage system, Magic Pocket, with custom hardware and software. Over roughly two and a half years it built Magic Pocket and moved about 90% of user files onto it, running both systems in parallel during the move, and kept AWS for some workloads and regions.
The thinking pattern. The CTO summed up the logic in one line: "Nobody is running a cloud business as a charity." At sufficient scale, a commodity you consume heavily is worth building yourself. Lessons: repatriation makes sense when a workload is huge, steady, specialised and central to the product; budget for the double-running period during migration, because it temporarily raises costs.
The S-1 arithmetic is a good template for how to report a repatriation honestly. Gross savings on third-party spend ($92.5M) are reduced by the new owned costs (depreciation and facilities, $53M) to reach the net figure ($39.5M). A claim that quotes only the gross number overstates the result; the net-of-ownership figure is the one to compare against a cloud bill.
4. CS-25 X (formerly Twitter): blob storage out, data processing slimmed down
| Field | Detail |
|---|---|
| Claim date | October 2023 |
| Change | Media and blob artefacts moved on-prem; cloud processing optimised |
| Evidence | Company engineering post |
| Result | ~60% lower monthly cloud cost (company claim) |
Under severe cost pressure and amid publicised disputes with cloud vendors, X's engineering team reported a year of infrastructure changes. All media and blob artefacts were moved out of the cloud, cutting cloud storage size by about 60%, and cloud data-processing costs were reported to be down about 75%. The monthly cloud cost was reportedly down 60%.
The thinking pattern. Blob storage and heavy data processing are the two cloud line items with the largest gap between rental and ownership cost. Lessons: if you already own data centres, moving bulk storage back is often the biggest single lever; separate claims from verified outcomes, because public statements rarely include total cost of ownership.
5. CS-26 Prerender.io: a data-transfer-heavy workload that outgrew AWS pricing
| Field | Detail |
|---|---|
| Business | Pre-rendering JavaScript pages for crawlers |
| Load | ~70,000 pages a minute; ~560M cached pages |
| Change | AWS to in-house infrastructure, completed late 2022 |
| Result | $1M to $200K annual server cost (-80%) |
Prerender caches and serves rendered HTML. Its costs were dominated by servers, storage and data transfer, all of which grow with customer traffic. Because downtime would hurt customers' search rankings, the team planned the migration in stages, moving caching, storage and rendering to owned infrastructure over a little more than three months. Annual costs fell from a projected $1M+ to about $200K, saving roughly $800K a year.
The thinking pattern. Workloads whose bill is mostly bandwidth and storage, with little need for managed services, get the least value from cloud premiums. Lessons: look at what share of your bill is egress and raw storage, since those are where alternatives are cheapest; migrate in stages with rollback paths, because SEO-sensitive services cannot tolerate long outages. Watch-out: the savings figures come from the company's own account.
6. CS-27 OneUptime: a 28-node Kubernetes cluster moved to bare metal
| Field | Detail |
|---|---|
| Business | Open-source observability and status pages |
| Before | $456K+ a year for a 28-node AWS Kubernetes cluster |
| After | Colocated bare metal, MicroK8s, Ceph |
| Published | 2023, with a two-year follow-up |
| Result | $230K saved per year (55%+) |
Because the product already ran on Kubernetes with Helm, the cluster was portable. Modern tooling (Docker, Kubernetes, Ceph) made running on bare metal far easier than it had been a decade earlier. The team did a phased cutover: MicroK8s on bare metal was tested with a subset of traffic, more workloads were shifted over weeks while being monitored, and all traffic was routed over once stable. A two-year follow-up addressed common objections: whether Reserved Instances would have closed the gap, how to fail over a single rack, and the people cost.
The thinking pattern. Kubernetes is a portability layer; if you already pay the complexity cost of running it, the cost of moving the underlying machines drops sharply. Lessons: compare against the best cloud price (with Savings Plans and Spot), not the On-Demand list price; plan for rack-level and site-level failure explicitly when leaving multi-AZ cloud. Watch-out: a small company with strong infrastructure skills; results depend heavily on in-house expertise.
7. CS-28 GEICO: a decade of lift-and-shift, then a costly reversal
| Field | Detail |
|---|---|
| Business | US auto insurer |
| Cloud footprint | Multiple providers; ~$300M annual cloud bill |
| Change | Repatriating to an OCP-based private cloud (OpenStack, Kubernetes) |
| Reported | 2024-2025 |
| Result | 2.5x growth in cloud bills after ten years of migration |
GEICO moved to public cloud to cut cost and complexity, largely by lifting and shifting legacy applications across several providers. Ten years in, not everything had migrated, bills had risen about 2.5 times, and reliability problems had increased. Running legacy applications unchanged in the cloud proved very expensive; storage was singled out as one of the costliest things to do in the cloud. GEICO is building private cloud capacity on Open Compute Project hardware with open-source software, repatriating many workloads.
The thinking pattern. Lift-and-shift preserves on-prem inefficiencies and adds cloud prices on top. The cloud rewards applications re-designed for elasticity; it punishes static, always-on legacy systems. Lessons: do not migrate without a modernisation plan (right-size and re-architect as you move); spreading workloads across many clouds without a clear reason multiplies complexity and cost; storage-heavy, compliance-driven retention is a prime candidate for tiering or on-prem. Watch-out: GEICO's situation spans several cloud providers, not only AWS, and its unit-cost figures are self-reported.
8. The six cases side by side
| Case | Why it worked (or did not) | Key precondition | Headline |
|---|---|---|---|
| 37signals | Steady load, elasticity rarely used | Racks, contracts, ops staff already in place | $3.2M to $1.3M a year |
| Dropbox | Storage is the product; enormous, steady | Scale to justify a dedicated infra team | $74.6M over two years |
| X | Blob storage and heavy processing off cloud | Owned data centres; claim unverified | ~60% monthly (claim) |
| Prerender.io | Bandwidth and raw storage dominate | Staged migration with rollback | $1M to $200K a year |
| OneUptime | Already on Kubernetes; portable | Strong in-house infra skills | $230K a year (55%+) |
| GEICO | Lift-and-shift preserved inefficiency | Modernisation plan (was missing) | 2.5x bill growth, then reversal |
Three things recur among the successes. The workload was steady and predictable, so elasticity was an unused premium. The bill was dominated by storage, egress or raw compute rather than managed services. And the organisation already had, or could hire, the operations skills. The failure case (GEICO) is the mirror image: an estate full of static legacy systems moved unchanged into an environment priced for elasticity.
9. Would leaving pay off? A scoring checklist
The report offers a short checklist for the decision. Treat each unchecked line as a reason to keep optimising on AWS instead.
| Question | Favours leaving if... |
|---|---|
| Is the load steady and predictable? | Yes: you are paying for elasticity you do not use |
| Do storage and egress dominate the bill? | Yes: these have the widest rental-versus-ownership gap |
| Few managed-service dependencies? | Yes: little to rebuild |
| In-house operations and hardware skills? | Yes: you can run it safely |
| Existing racks, power and contracts? | Yes: fixed costs are already paid |
| Already portable (Kubernetes, Helm)? | Yes: the move is a machine move, not a rewrite |
| Have you compared with the best AWS price? | Yes: Savings Plans, Spot, Graviton, right-sizing all applied |
9.1 A total-cost-of-ownership skeleton
Before any move, fill in a table like this over a five-year horizon for both options. The point is to force every hidden cost onto the page. The rows below are a template, not numbers from any case.
| Cost line | Stay on AWS (best price) | Owned or colocated |
|---|---|---|
| Compute (after right-size, Graviton, Spot, commitments) | modelled | servers, amortised over refresh cycle |
| Storage | S3 tiers and versioning | arrays, media, replication overhead |
| Network and egress | data transfer, NAT, endpoints | transit, cross-connects, second site |
| Managed services replaced | included in price | engineering time to run yourself |
| People | platform engineers | plus hardware and on-call operations |
| Power, space, cooling | none | colocation contract |
| Redundancy and DR | multi-AZ, multi-region as needed | second site, rack- and site-level failover |
| Migration one-off and double-running | none | Dropbox's parallel-run period; egress (may be waived) |
| Stranded commitments | none | RIs and Savings Plans until they expire |
10. The middle path: keep the cloud, exit selectively
Every success in this part left part of AWS. 37signals kept S3 until its own array was ready; Dropbox kept AWS for some workloads and regions; X moved blobs but kept cloud processing. The pattern is to move the class of workload with the widest premium (bulk storage, steady compute) and keep what benefits from elasticity and managed services (spiky workloads, managed databases, global reach). That is also a reasonable answer for a team in the middle of the spectrum: exhaust Parts 2 to 6 first, then price one workload class, not the whole estate.
Is cloud repatriation a trend I should follow?
Not by default. These six cases are calibration. They worked where the workload was steady, storage- or bandwidth-heavy, and the organisation had operations skills. GEICO shows the opposite failure. Compare against your best AWS price first.
What about egress fees when leaving?
Since March 2024 AWS waives data-transfer-out fees for customers moving data off AWS, on request (37signals had about $250K waived). You still pay for double-running, hardware and engineering, so model those.
Why did GEICO's bills grow 2.5x?
Lift-and-shift preserved on-prem inefficiencies and added cloud prices on top. Legacy static systems were moved unchanged into an environment priced for elasticity, storage was especially costly, and workloads spread over several providers added complexity.
Takeaways
- Know what the premium buys. Elasticity is insurance you may not need for steady loads.
- Storage and egress have the widest rental-versus-ownership gap (Dropbox, X, Prerender.io, 37signals' S3 move).
- Compare with the best AWS price, not On-Demand list price (the OneUptime critics' point).
- Report net of ownership costs. Dropbox's $92.5M gross became $39.5M net in year one.
- Budget for double-running, wait for commitments to expire, and plan rack-level and site-level failover.
- Never lift and shift without modernising. GEICO's bills grew 2.5x.
References & further reading
- Cutting the AWS Bill: 28 Case Studies (PDF) - chapter G (CS-23 to CS-28) and section 6.9 (checklists).
- 37signals - our cloud exit savings will top ten million over five years · DCD - S3 exit
- Dropbox S-1 (2018) · Data Center Knowledge - Dropbox savings
- DCD - X/Twitter claims
- Prerender.io - reduced annual server costs by 80%
- OneUptime - moving from AWS to bare metal
- The New Stack - GEICO and cloud repatriation · The Stack - GEICO interview
Keep it offline. The complete 28-case report, with the scoreboard, lever matrix and 90-day playbook, is one PDF.
⬇ Download PDF