Repatriation proposals usually arrive with one number and no model. The number is the current cloud bill, the model is missing, and the decision lands as a matter of temperament: either leadership believes in owning hardware or it does not. That is a bad way to spend seven figures.
The decision is arithmetic, and the arithmetic is knowable in a week. What follows is a break-even model for leaving a hyperscaler, with every input labeled, plus the conditions under which the model says stay. The most useful public reference point is 37signals, which published its reasoning: $3.2 million of cloud spend in 2022, about $1 million of it storing roughly 8 petabytes of files in S3 across several regions, and a projection of about $7 million saved over five years without changing the size of its operations team.
What actually drives the savings
Cloud bills are not one thing. Compute, storage, network, managed services, and support each behave differently when a workload moves to owned hardware. Compute is where rental premiums are largest relative to owned capacity, because a reserved instance still carries a margin over the underlying server. Storage is where the gap closes or reverses: replicated object storage is genuinely hard to beat on a price-per-durable-gigabyte basis once you price three copies, cross-region redundancy, and the staff to operate it.
Managed services are the part that repatriation proposals understate. A managed relational database bundles backups, point-in-time recovery, failover, patching, and a control plane in its price. Replacing it means building or operating those functions. The honest framing is not "cloud is expensive" but "which of these five lines is priced above what it would cost us to run, including the people?"
A break-even model with five lines
Compare two annual run rates, then divide the one-time migration cost by the annual difference to get a payback period. The repatriated run rate has five components:
- Hardware amortization. Total purchase price divided by the useful life you are willing to defend, typically four years for servers and three for GPUs.
- Facilities. Colocation space, power, cooling, and cross-connects, usually quoted per rack per month.
- Incremental staff. The people you must add or reassign to run what the vendor used to run.
- Network. Transit, peering, load balancers, and the reduced but nonzero egress you still pay.
- Software. Virtualization, backup, monitoring, and the licenses that used to be bundled into the managed service.
The one-time side is migration labor, parallel running during cutover, and the depreciation hit on any cloud commitments you cannot escape. Payback in months equals one-time cost divided by monthly savings. If that number exceeds the hardware refresh cycle, the project cannot pay back, because you will be buying hardware again before you finish saving on the first purchase.
Egress is real, and rarely the reason
AWS charges about nine cents per gigabyte for data transfer out to the internet for the first ten terabytes a month in US regions, after 100 GB free, and inbound transfer is free. That asymmetry is why egress shows up in every repatriation deck. It is also why so many of those decks overstate the case: most internal workloads move modest amounts of data outward. A service that stores 200 TB and serves 2 TB a month to users pays roughly $180 a month in egress, not a budget line that justifies a data center.
Egress dominates when the workload is a media origin, a public API with large payloads, or a cross-region replication pattern. For those, the alternative is not necessarily owning hardware; object storage providers with zero egress fees change the comparison entirely, and so does moving the delivery path to a CDN with committed pricing. Price the egress separately and ask whether repatriation is the cheapest way to eliminate it. Often it is the fourth-cheapest.
Committed spend is the exit tax
The bill you compare against is not the list price. AWS advertises savings of up to 72% with Savings Plans, and most large accounts also carry a private pricing agreement with volume discounts and a spend commitment. Two consequences follow. First, the baseline you are trying to beat is the discounted bill, not the on-demand one, which makes the hurdle higher than the proposal assumes. Second, leaving mid-term can strand a commitment or require a negotiation, and the remaining term is a real cost of the move.
There is a counter-move available before any hardware is ordered: ask the account team for a re-quote on the specific workloads you are about to move. A vendor that knows the alternative is a colo rack will often find margin it did not offer during the renewal. If the re-quote closes most of the gap, the honest conclusion is to stay and take the discount.
Staff and refresh are the swing factors
Every repatriation model is sensitive to two inputs that are easy to fudge. The first is headcount. Cloud providers hide labor inside the bill; owned infrastructure makes it explicit, and good infrastructure engineers are expensive. The second is refresh discipline. A model that assumes hardware lasts six years and needs no spare capacity is not a model, it is a hope.
A useful stress test: double the incremental staff assumption and shorten the hardware life by a year. If the project still pays back inside three years, it survives the two inputs most likely to be wrong. If it only works with the optimistic values, the case is a preference dressed as a spreadsheet.
One input the spreadsheet usually omits is how the money is accounted for. Cloud spend is operating expense, approved annually and revisable. A hardware purchase is capital expense with a depreciation schedule, a refresh obligation, and an approval process that competes with every other capital request. Moving from one to the other does not just change the total, it changes who must approve it and when it can be cut. Finance teams care about that difference as much as about the number, and a repatriation case that ignores it gets sent back for a rewrite.
Worked example: a $1.8 million estate
All figures below are assumptions for illustration. Substitute your own contract rates before acting.
| Line | Stay on AWS | Repatriated | Note |
|---|---|---|---|
| Compute | $1,050,000 | $275,000 | Hardware amortized over four years |
| Storage and databases | $250,000 | $180,000 | Owned disks plus backup target |
| Egress and network | $120,000 | $80,000 | Transit and reduced egress |
| Managed services | $380,000 | $0 | Replaced by self-operated software |
| Facilities | $0 | $180,000 | Colocation, power, cooling |
| Incremental staff | $0 | $550,000 | 2.5 engineers fully loaded |
| Annual total | $1,800,000 | $1,265,000 | Gross saving $535,000 a year |
One-time cost: about $300,000 in contracted migration help, four months of parallel running at roughly $600,000, and internal engineering time. Call it $900,000. Payback is $900,000 divided by $535,000, or about 20 months. That is a defensible project, provided three conditions hold: the hardware really costs what the quote says, utilization stays high enough that you are not buying idle capacity, and you actually reduce the managed-services line rather than running both stacks indefinitely.
Now change one input. If the workload needs five incremental engineers instead of 2.5, staff cost rises by $550,000 and the annual saving drops to roughly zero. The project is no longer marginal; it is negative. That is the entire argument in one line: repatriation is a labor arbitrage question more than a hardware question, and it only works when the estate is large enough that a small team operates a lot of capacity.
Where the plan breaks
Four failure patterns recur. Lifting and shifting virtual machines without changing the operational model, so the team inherits cloud complexity without cloud elasticity. Underestimating durability work, because three copies, integrity checks, and restore drills used to be someone else's job. Forgetting the refresh cycle, so year five arrives with aging disks and no capital. And losing the on-call rotation, because a 2 a.m. page used to reach a vendor and now reaches a person who also has a product deadline.
What to do next
- Get the real discounted bill, by service, for the last twelve months. The list-price comparison is fiction.
- Build the five-line repatriated run rate with a named engineer count, and stress it by doubling staff.
- Separate egress from the rest of the case, then price the cheaper fixes for egress alone.
- Ask for a re-quote on the workloads you intend to move before signing a hardware order.
- Set a decision date and a kill criterion, so a stalled migration does not become a permanent double-cost program.