Cloud repatriation is best treated as 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 can become an expensive mistake when the business case compares an unoptimized cloud bill against a hardware quote and ignores talent, refresh cycles, elasticity, and reversal cost.
Public company accounts show that repatriation can produce savings in a suitable context. One well-documented example is 37signals: after its cloud exit, David Heinemeier Hansson wrote that savings would top $10M over five years, above the original $7M projection [1]. Its comparatively predictable workload and its team's ability to operate the stack are important parts of that story [2]. Use it as a case study, then build the decision from your own workload data.
Many enterprise AI portfolios may have a different demand shape. Training spikes, evaluation batches, vector indexing jobs, inference experiments, and seasonal data-processing runs can create uneven demand. Buying for the peak can leave hardware idle, while buying for the average can create queues. A hybrid model is therefore a useful hypothesis to test: optimize cloud first, evaluate narrow steady-state candidates for repatriation, and compare bursty AI capacity across elastic and owned options.
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 | Customer-defined hardware refresh cycle | 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 may be candidates when they have predictable traffic, high utilization, clear databases, known storage patterns, and limited need for sudden bursts. If an application runs consistently on capacity the team can forecast, owned hardware may compare favorably with renting after full operating costs are included.
Some AI workloads have a different profile. A training job may use substantial GPU capacity for a short period and little capacity between runs. 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. Use workload telemetry to determine which pattern you actually have.
Owning peak capacity can weaken those economics. Renting the peak can carry a higher hourly rate, but it may still compare favorably with buying accelerators that sit idle. Tactical Edge treats repatriation as one option inside a broader cloud modernization strategy, with the decision based on customer telemetry and constraints.
The Flexera sample illustrates the tension. Respondents reported both cloud waste and substantial use of generative AI as a public cloud service [3]. That combination can make repatriation tempting without proving that owned infrastructure is cheaper. A large bill may instead point to weak cost allocation, rightsizing, commitments, or AI usage controls.
Build The Optimized Baseline First
For a decision-quality comparison, evaluate repatriation against an optimized cloud baseline rather than only the current invoice.
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
A portfolio-level repatriation decision can mislead when leaders average unlike workloads together. A steady database and an occasional AI training pipeline can disappear inside the same blended utilization number even though they need different capacity models. Evaluate them separately.
Use a scorecard with five dimensions, then set thresholds from workload telemetry, service levels, depreciation policy, and risk tolerance.
| Dimension | Good repatriation signal | Bad repatriation signal | Evidence to collect |
|---|---|---|---|
| Utilization | High and stable across the relevant business cycle | Low or highly variable | CPU, memory, storage, and GPU usage across representative periods |
| Burst dependency | Little need for rapid scale-up | Frequent material bursts against the baseline | 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 additional 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 compare the full planning horizon against optimized cloud, not the current cloud bill:
| TCO area | Include in model | Minimum evidence |
|---|---|---|
| Optimized cloud baseline | Rightsized services, commitments, storage tiering, spot strategy | Customer-selected cost window 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 |
Set a minimum advantage large enough to justify execution risk before comparing options. Finance and operations leaders should choose that threshold together.
Practical Controls Before You Move Anything
Before buying hardware, create the controls that make either path measurable. The same controls improve cloud cost today and reduce repatriation risk tomorrow.
The YAML below shows a simple qualitative policy. Add the thresholds and review cadence that fit your workload telemetry and operating process.
required_tags:
- team
- product
- workload
- environment
- owner
- cost_center
workload_tiers:
green:
utilization: "high and stable"
burst_dependency: "low"
action: "model repatriation after optimization"
yellow:
utilization: "variable or seasonal"
burst_dependency: "moderate"
action: "optimize in cloud and review again"
red:
utilization: "low or highly variable"
burst_dependency: "high"
action: "keep elastic, improve controls"
commitment_policy:
baseline_only: true
avoid_committing_to_spikes: true
review_cadence: "monthly"This policy creates attribution, separates steady workloads from bursty ones, and discourages commitments for usage that may vanish. Set its review cadence and thresholds from your telemetry, contracts, and operating process.
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.
Frequently Asked Questions
Is cloud repatriation a good idea in 2026?
It can be for specific workloads. The case may be stronger for steady systems with high utilization, low burst needs, strong data gravity, and a team that can operate owned infrastructure. The case may be weaker for spiky AI workloads, dev/test fleets, and systems that rely heavily on managed cloud services.
Should AI workloads move on-prem?
Sometimes, but the answer should come from workload telemetry and a full cost model. Steady inference with predictable volume may be a candidate. Training, evaluation, synthetic data generation, and re-indexing jobs can require burst capacity whose rented and owned economics should be compared for the specific environment.
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 a commonly missed cost?
Talent can be material. If the organization has been cloud-native for years, the people who can operate private infrastructure 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.
Where does cloud modernization fit alongside a repatriation review?
A workload-level review may lead to modernization rather than a wholesale move. Our AWS cloud modernization and migration practice covers workload assessment, landing-zone design, and the migration patterns referenced above, and the enterprise data analytics practice covers the cost-attribution and unit-economics reporting the scorecard depends on.
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.
As a practical first exercise, pull cost by workload across a period that captures both normal operations and seasonal demand. If a meaningful share is untagged or unattributed, improve visibility before relying on the repatriation model.
This week, pick one unit-economics metric: cost per inference, cost per transaction, cost per active customer, or cost per pipeline run. Evaluate the cloud bill in the context of the value and service level it supports.
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