Cloud repatriation is a workload decision, not a philosophy. Moving a system back on-premises can be the right financial call when utilization is high, demand is predictable, data gravity is strong, and the team already knows how to operate owned infrastructure. It becomes a $10M mistake when the business case compares an unoptimized cloud bill against a hardware quote and ignores talent, refresh cycles, elasticity, and reversal cost.
The repatriation argument became serious because some real companies saved real money. 37signals is the cleanest public example: after its cloud exit, David Heinemeier Hansson wrote that savings would now top $10M over five years, above the original $7M projection [1]. That story matters. It also gets misused. Their workloads were steady, their team could operate the stack, and the company had already squeezed cloud waste hard before leaving [2].
Most enterprise AI portfolios do not look like that. Training spikes, evaluation batches, vector indexing jobs, inference experiments, and seasonal data-processing runs create jagged demand. If you buy for the peak, hardware sits idle. If you buy for the average, the work queues. The right answer is usually a hybrid: optimize cloud first, repatriate narrow steady-state candidates, and keep bursty AI capacity elastic.
The Spreadsheet That Makes Repatriation Look Obvious
The classic repatriation business case is too simple. One column shows annual cloud spend. The next column shows servers, storage, colocation, network, and support. The second column is smaller, so the decision appears obvious.
That model hides the expensive part. Cloud pricing bundles operations, redundancy, refresh, managed service labor, and instant capacity. Owned infrastructure unbundles those costs. They do not disappear. They move into headcount, planning, depreciation, spares, incident response, and opportunity cost.
The first correction is to replace the invoice comparison with a workload-level TCO model.
| Cost line | Cloud model | Repatriated model | Common modeling mistake |
|---|---|---|---|
| Compute | Pay for reserved, on-demand, or spot usage | Buy or lease capacity ahead of demand | Compare peak hardware to current cloud waste |
| Operations | Shared across managed services and platform team | Bare-metal, network, storage, firmware, backup, and incident ownership | Assume the same team absorbs the work |
| Refresh | Provider handles lifecycle | Hardware refresh every 3-5 years | Treat purchase as one-time capex |
| Elasticity | Rent spikes by the hour | Provision for peak or accept queues | Model average utilization instead of peak |
| Reversal | Change instance family, region, or service | Migrate back after contracts, depreciation, and architecture drift | Ignore the cost of being wrong |
The right question is not, "Can we buy equivalent machines for less?" The right question is, "After we optimize the cloud baseline, which workloads still show a risk-adjusted three-year advantage after talent, refresh, downtime, and reversal cost?"
Why 37signals Worked, And Why That Does Not Generalize
37signals deserves attention because the math was public and the exit appears operationally successful. The company originally described a $3.2M annual cloud bill, a large server purchase, two data centers, and a projected $7M five-year savings [2]. In 2024, the company updated that estimate and said savings would top $10M over five years [1].
That does not mean every enterprise should leave the cloud. It means their workload shape and operating model fit the move.
Steady SaaS workloads are good candidates. They have predictable traffic, high utilization, clear databases, known storage patterns, and limited need for sudden 10x bursts. If an app runs hot all month on capacity you can forecast, owning hardware can beat renting.
AI workloads are different. A model training job may need hundreds of GPUs for two days, then need almost none for two weeks. A synthetic-data generation batch may run at month end. A vector re-index may spike after a content migration. A customer-facing inference service may be steady during business hours and uneven during product launches.
Owning the peak makes those economics ugly. Renting the peak is expensive per hour, but it can still be cheaper than buying accelerators that sit idle. This is why Tactical Edge usually treats repatriation as one option inside a broader cloud modernization strategy, not as the strategy itself.
The Flexera numbers explain the tension. Cloud waste remains high, but AI usage in cloud is also mainstream. That combination makes repatriation tempting and dangerous. A big bill is not proof that owned infrastructure is cheaper. It may only prove that cost allocation, rightsizing, commitments, and AI usage controls are weak.
Build The Optimized Baseline First
Never compare repatriation against the invoice you have today. Compare it against the cloud bill you would have after basic FinOps discipline.
Start with attribution. If the cloud bill cannot be tied to workloads, teams, environments, and products, the repatriation model will be guesswork. A CFO may know the total spend, but the CTO needs to know which workloads are steady, which are bursty, which are idle, and which create value.
Here is a simple Athena-style query pattern for AWS Cost and Usage Report analysis. It is not the whole model, but it forces the first question: what does each workload actually cost by month and usage type?
SELECT
line_item_usage_account_id AS account_id,
resource_tags_user_workload AS workload,
product_product_name AS service,
pricing_term,
DATE_TRUNC('month', line_item_usage_start_date) AS month,
SUM(line_item_unblended_cost) AS cost_usd
FROM cost_and_usage_report
WHERE line_item_usage_start_date >= DATE_ADD('day', -90, CURRENT_DATE)
GROUP BY 1, 2, 3, 4, 5
ORDER BY month DESC, cost_usd DESC;Then optimize the cloud state before modeling an exit:
- 1Delete unattached volumes, idle load balancers, unused snapshots, and abandoned dev resources.
- 2Rightsize instances and databases against actual utilization.
- 3Apply Savings Plans or reserved capacity to the predictable baseline.
- 4Use spot or lower-priority queues for interruptible batch work.
- 5Move cold data into cheaper storage classes.
- 6Add unit economics, such as cost per inference, cost per transaction, or cost per active customer.
FinOps Foundation's 2025 framework update explicitly broadened FinOps into a Cloud+ model that can include public cloud, SaaS, licensing, private cloud, and data center cost scopes [4]. That matters because the board should not compare "cloud cost" with "server cost." It should compare full technology cost per unit of business value across all hosting models.
Score Workloads, Not The Whole Company
Repatriation fails when leaders average everything together. A fleet can show 60% blended utilization while hiding one database at 85% and one AI training pipeline at 12%. Those two workloads should not get the same hosting answer.
Use a scorecard with five dimensions:
| Dimension | Good repatriation signal | Bad repatriation signal | Evidence to collect |
|---|---|---|---|
| Utilization | Sustained above 65% | Below 40% or highly variable | 90-day CPU, memory, storage, and GPU usage |
| Burst dependency | Little need for rapid scale-up | Frequent 5x-10x bursts | Job queue, traffic, and launch history |
| Data gravity | Large stable data with low external egress | Data moves often across services or regions | Egress, replication, and transfer patterns |
| Operations capability | Existing infra team and runbooks | Cloud-only team with no hardware ownership | On-call skills, hiring plan, vendor support |
| Reversal risk | Isolated workload and clean interfaces | Deep service coupling and unclear rollback | Dependency map and migration plan |
Green workloads are steady, highly utilized, and operationally boring. Yellow workloads should be optimized first and revisited later. Red workloads need elasticity, frequent experimentation, or cloud-managed services badly enough that repatriation is a distraction.
The Hidden Ledger For Board Approval
A board-ready TCO model needs more than hardware. It needs the hidden ledger that determines whether the move is reversible and survivable.
Talent is the first line. Bare-metal operations require skills many teams have not hired for in years: firmware, storage, rack-level failure modes, network redundancy, data center vendors, backup restoration, and capacity planning. If the team needs three senior infrastructure hires, that cost belongs in the model.
Refresh is the second line. Servers, storage, and accelerators age. GPU economics can change fast. A three-year model that does not reserve budget for refresh is not conservative. It is incomplete.
Elasticity is the third line. AI has made this more important, not less. If training, evaluation, or inference spikes force you to buy for peak, idle hardware becomes the new cloud waste.
Downtime and reversal are the fourth line. If the move underperforms, how hard is it to go back? Have contracts locked the organization in? Has the architecture diverged? Are data pipelines now tied to private infrastructure? Those costs are rarely in the initial deck because they make the decision look less clean.
The output should be a three-year comparison against optimized cloud, not current cloud:
| TCO area | Include in model | Minimum evidence |
|---|---|---|
| Optimized cloud baseline | Rightsized services, commitments, storage tiering, spot strategy | 90-day cost export plus optimization plan |
| Repatriated platform | Hardware, colo, network, storage, backup, monitoring, support | Vendor quotes and architecture bill of materials |
| People | Hiring, training, on-call, escalation, vendor management | Named owners and costed staffing plan |
| Risk | Downtime exposure, reversal path, security controls, compliance evidence | Runbooks, RTO/RPO, and control mapping |
| Business value | Unit economics and product impact | Cost per transaction, inference, customer, or workload |
If the repatriated model does not beat optimized cloud by at least 20% over three years, the decision probably lacks enough margin for execution risk.
Practical Controls Before You Move Anything
Before buying hardware, create the controls that make either path defensible. The same controls improve cloud cost today and reduce repatriation risk tomorrow.
required_tags:
- team
- product
- workload
- environment
- owner
- cost_center
workload_tiers:
green:
utilization: "65%+ sustained"
burst_dependency: "low"
action: "model repatriation after optimization"
yellow:
utilization: "40-65% or occasional bursts"
burst_dependency: "moderate"
action: "optimize in cloud, revisit in two quarters"
red:
utilization: "below 40% or high burst dependency"
burst_dependency: "high"
action: "keep elastic, improve controls"
commitment_policy:
baseline_only: true
avoid_committing_to_spikes: true
review_cadence: "monthly"This policy does three useful things. It forces attribution, separates steady workloads from bursty ones, and prevents teams from buying commitments for usage that may vanish. It also gives finance, platform, and product teams the same vocabulary.
AWS Savings Plans documentation is useful here because it clarifies how commitments trade flexibility for lower rates [5]. Google Cloud rightsizing guidance makes the same core point from another provider angle: recommendations should be based on observed utilization and machine fit, not hope [6]. The provider differs, but the discipline is the same.
FAQ
Is cloud repatriation a good idea in 2026? Yes, for specific workloads. It is most defensible for steady systems with high utilization, low burst needs, strong data gravity, and a team that can operate owned infrastructure. It is weak for spiky AI workloads, dev/test fleets, and systems that rely heavily on managed cloud services.
Should AI workloads move on-prem? Sometimes, but do not generalize. Steady inference with predictable volume may be a candidate. Training, evaluation, synthetic data generation, and re-indexing jobs often need burst capacity that is cheaper to rent than to own.
What should be optimized before repatriation? Attribution, rightsizing, storage tiering, idle resource cleanup, commitment coverage, spot usage for interruptible jobs, and unit economics. Repatriation should compete against that optimized baseline.
What is the biggest hidden cost? Talent. If the organization has been cloud-native for years, the people who can operate private infrastructure safely may not be on the team.
What should the board ask for? A workload-level scorecard, a three-year TCO model, an optimized cloud baseline, named operational owners, a rollback plan, and a unit-economics metric.
Summary And Next Steps
Cloud repatriation is not wrong. Treating it as a movement is wrong. 37signals made a rational decision for its workload and operating model. A company running uneven AI workloads, unmanaged cloud tags, weak cost attribution, and no hardware operations bench has a different problem.
In the next 30 minutes, pull the last 90 days of cost by workload. If more than 20% is untagged or unattributed, stop the repatriation deck and fix visibility first.
This week, pick one unit-economics metric: cost per inference, cost per transaction, cost per active customer, or cost per pipeline run. A cloud bill is only too high when it rises faster than the value it produces.
Then score workloads one by one. Keep bursty AI capacity elastic. Optimize cloud waste before comparing. Repatriate only the boring, steady, high-utilization systems that still win after the hidden ledger is included.
References
[1] David Heinemeier Hansson, "Our cloud-exit savings will now top ten million over five years," 37signals, 2024. https://world.hey.com/dhh/our-cloud-exit-savings-will-now-top-ten-million-over-five-years-c7d9b5bd
[2] David Heinemeier Hansson, "The Big Cloud Exit FAQ," 37signals, 2023. https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010
[3] Flexera, "Flexera 2026 State of the Cloud Report: The convergence of cloud and value," 2026. https://www.flexera.com/blog/finops/flexera-2026-state-of-the-cloud-report-the-convergence-of-cloud-and-value/
[4] FinOps Foundation, "FinOps Framework 2025," 2025. https://www.finops.org/insights/2025-finops-framework/
[5] Amazon Web Services, "Savings Plans User Guide," 2026. https://docs.aws.amazon.com/savingsplans/latest/userguide/
[6] Google Cloud, "Rightsizing recommendations for Compute Engine instances," 2026. https://cloud.google.com/compute/docs/instances/apply-machine-type-recommendations-for-instances