Every repatriation story starts with a shocking invoice. The ones that end well start with a workload audit instead. Moving off a hyperscaler is not a moral position; it is a capital decision with a long tail.
We spoke to platform teams that moved between 40 and 900 virtual machines out of public cloud, and to several that tried and moved back. The difference between the two groups was rarely technical skill. It was whether they counted the costs that do not appear on the cloud bill.
The bill that starts the conversation
Public cloud pricing is honest about compute and storage and quietly expensive at the edges. Egress, cross-zone traffic, managed NAT gateways, log ingestion and premium support can add 30 to 50 percent to a bill that looked reasonable at the architecture review. When a finance team sees that number, repatriation suddenly has an executive sponsor.
But the invoice is a symptom, not a diagnosis. A team paying too much for cloud is often paying for idle capacity, oversized databases or logs nobody reads. Rip those out first. Moving a badly tuned stack into a colo rack simply relocates the waste and adds a hardware lease.
What repatriation actually costs
The credible comparison runs over three to five years and includes five lines that cloud calculators ignore. First, servers and storage, refreshed on a realistic cycle rather than run until failure. Second, the rack, power and cross-connects, which are monthly forever. Third, staff or a managed provider to cover nights and weekends. Fourth, migration and the productivity dip while engineers rebuild what the cloud did automatically. Fifth, the option value of giving up elastic capacity.
On paper, a steady-state workload with predictable load often lands 35 to 55 percent cheaper over five years in owned hardware. A spiky, experimental or globally distributed workload usually does not. The overlap is where most businesses actually live, which is why the answer is usually hybrid rather than a clean exit.
The workloads that fit, and the ones that do not
Good candidates share three traits: stable demand, large and growing storage, and low tolerance for per-request pricing. Internal APIs, media archives, build runners, backup targets and analytics clusters fit that profile. They run hot all day, store a lot, and do not need to appear in a new region by Friday.
Bad candidates change shape every quarter. Customer-facing products with seasonal peaks, machine-learning training jobs and anything with an unknown growth curve benefit from the cloud's ability to absorb a bad forecast. Paying for idle hardware during a quiet quarter is just a different kind of bill.
Repatriation is not a way to make infrastructure cheap. It is a way to make infrastructure predictable, and predictability has a price of its own.
A three-step test before you move
Start with a line-by-line bill for the last twelve months, not a sample month. Group it by service and tag every line to a team. Most organisations find that two or three workloads account for the majority of spend, and at least one of them is a forgotten proof of concept.
Second, model the owned alternative with a five-year refresh, power at your actual tariff and a realistic on-call rota. Include the migration cost as a one-off and the loss of engineer time as a recurring tax. If the saving survives a 20 percent error bar in both directions, it is real.
Third, run a pilot with an exit ramp. Move one bounded service, keep the cloud version warm for ninety days, and measure latency, incident rate and engineer satisfaction alongside the bill. A pilot that only tracks cost will miss the operational cost that shows up in month seven.
Key facts
- Egress, NAT and logging can add 30-50% to a headline cloud bill.
- Steady workloads often save 35-55% over five years on owned hardware.
- Spiky or experimental workloads usually stay cheaper in public cloud.
- Five-year refresh, power and on-call staff belong in every model.
- A pilot with a ninety-day exit ramp beats a big-bang migration.
The hybrid answer most teams choose
The teams that reported the best outcome kept a small cloud footprint for burst capacity, disaster recovery and anything customer-facing that might go viral. They moved the boring, heavy, predictable parts home. That split preserves elasticity where it matters and removes per-request pricing where it does not.
It also changes how the team buys hardware. Instead of a five-year bet on one vendor, they buy refurbished or commodity nodes for the stable tier and reserve premium cloud capacity for peak events. The finance model becomes easier to explain, and the architecture becomes easier to defend.
If you are still choosing a host for a smaller stack, our guide to shared, VPS and managed WordPress hosting covers the decision below the enterprise tier. For the analytics side of the same bill, see why warehouse costs spike in December.
Bottom line
Moving off AWS can save real money, but only when the workload is stable, the storage is heavy and the team can run infrastructure without heroics. Do the audit first. If the saving survives staffing, power and refresh, repatriate. If it only survives in a spreadsheet, negotiate a committed-use discount instead.
