For a decade the advice was simple: put everything in the cloud and never look
back. In 2026 that consensus is cracking. A Barclays survey found 83% of
enterprises plan to repatriate at least some workloads from public cloud to
private infrastructure, and IDC puts the share expecting to move compute or
storage within the year near 80%. The most-cited example is still 37signals, the
team behind Basecamp, who left the public cloud and reported saving roughly $7
million over five years.
It is tempting to read those numbers as "cloud was a mistake." It was not. The
cloud is still the right home for spiky, unpredictable, early-stage workloads
where you are buying speed and optionality. What changed is that a lot of
companies have now run the same steady, predictable workload on rented hardware
for years, paying a premium for flexibility they stopped using. Repatriation is
not a reversal of cloud strategy. It is the correction that comes after the bill
gets big enough to read carefully. The question worth answering is not "should we
leave the cloud" but "which specific workloads no longer earn their cloud
premium," and that is a question you can answer with numbers.
What is actually driving the move
Cost is the headline, and it is real. Organizations that repatriate the right
workloads commonly report 30 to 60% lower infrastructure spend for those
workloads, because on-demand cloud pricing carries a large convenience margin
that only makes sense when your usage is genuinely variable. Run a database at a
steady 60% utilization every day for three years and you are paying a premium for
elasticity you never touch.
But cost is not the only force. Just over half of organizations name data
security and privacy as a top driver, and in Europe the regulatory pressure is
sharper than the cost case. Frameworks like DORA are already enforceable, and
regulators increasingly want evidence of control over where data physically
lives, not just a contractual promise from a hyperscaler. For a company handling
EU personal or financial data, "we know exactly which rack this runs on" has
become a feature, not a quirk.
Repatriation rarely means leaving entirely
For most companies this is not all-or-nothing. The common destination is a
hybrid posture: steady, predictable, sensitive workloads on owned or colocated
hardware, and spiky or experimental ones left in the cloud where elasticity is
worth paying for. The win is putting each workload where it is cheapest to run.
The workloads worth repatriating, and the ones to leave
Not every workload saves money off the cloud. The ones that do share a profile,
and so do the ones that do not.
Strong candidates to repatriate:
Steady-state compute. Anything running at high, predictable utilization
around the clock, where you are paying on-demand rates for a baseline that
never moves.Large, stable datasets with heavy egress. Cloud data-transfer charges are
brutal at scale. A workload that constantly pushes data out to users or other
systems often costs more in egress than in compute.GPU and ML inference at volume. Rented accelerators are expensive enough
that owned or colocated hardware can pay for itself in months at steady load.Data with hard residency requirements. When the law dictates where bytes
must sit, control is worth the operational overhead.
Leave it in the cloud when:
Traffic is spiky or seasonal. If you scale 10x for a launch or a sale,
elasticity is exactly what you are paying for, and it is worth it.You are pre-product-market-fit. Early-stage teams should buy speed, not
save pennies on hardware they may not need next quarter.The service is genuinely managed-value. A managed database that saves you a
full-time operator may be cheaper all-in than self-hosting, once you count the
people you would need to run it.
Count the total cost, not just the invoice
The mistake that sinks repatriation projects is comparing the cloud bill to the
hardware quote and stopping there. Owned infrastructure has costs the invoice
never shows: rack space and power, hardware refresh every few years, redundancy
and spare capacity, and, most expensive of all, the engineering time to run it.
The cloud bill is high partly because it bundles all of that into one line.
So build the comparison on total cost of ownership over three to five years, with
both options on the same axis. Put the cloud number and the all-in owned number,
hardware, hosting, networking, and the loaded cost of the people who operate it,
side by side. The repatriation case is real when the steady-state workload is
large enough that the owned option wins even after you have honestly priced the
operational burden. If it only wins when you pretend ops is free, it does not
win.
The hidden line item is people
Self-hosting trades a predictable cloud bill for an on-call rotation, patching,
and capacity planning. If repatriating means hiring or pulling engineers off the
product to babysit hardware, fold that fully loaded cost into the comparison.
Plenty of repatriation business cases evaporate the moment ops is priced
honestly.
How to move without a big-bang migration
The safe way to repatriate looks a lot like the safe way to modernize a legacy
system: in slices, with a fast path back. Do not schedule a weekend where
everything moves at once.
Measure first. Tag and meter your spend until you can name the few
workloads carrying the most cost and the most steady load. Repatriation is a
targeting exercise, and the targets are usually a handful of services, not the
whole estate.Pick one boring workload. Move something with steady load and tolerant
users first, a batch pipeline, an internal tool, a stable database replica.
Prove the operational model on something where a mistake is cheap.Keep a hybrid bridge. Run the workload in both places long enough to
compare cost and reliability with real traffic, and keep a tested rollback to
the cloud until you trust the new home.Standardize so you are not locked in either direction. Containers and
infrastructure-as-code keep workloads portable, so the choice stays "where is
this cheapest to run" rather than "where are we trapped."
Done this way, repatriation is a series of measured, reversible moves, each one
justified by its own numbers, rather than one nervous leap off a cliff.
Where to start
Repatriation is having a moment for good reasons, but the trend is not the
argument. Your bill is. Meter your spend, find the steady high-cost workloads,
price the owned option honestly including the people to run it, and move one
slice at a time. For most companies the answer is not "leave the cloud" or "stay
in the cloud" but a deliberate split that puts each workload where it actually
costs least. If you want a sharper read on the cloud side of that ledger first,
our startup FinOps playbook
covers the optimizations worth doing before you move anything at all.
The Lusivision team designs cloud and hybrid architectures for a living, and we
have no incentive to sell you hardware or hyperscaler credits, only the setup
that costs you least to run. If you are staring at a cloud bill that keeps
climbing and want a straight answer on what to move and what to leave, talk to
us. The first consultation is free and we reply within 24 hours.
Top comments (0)