The decade from 2013–2023 was "cloud by default" for most workloads. Cheap AWS credits, exponential capacity growth, and a generation of engineers who hadn't operated bare metal made the cloud the obvious answer to almost any infrastructure question.
That era is over. Cloud bills have grown faster than revenue at most mid-market and enterprise companies. A new generation of "cloud repatriation" has produced credible case studies (Dropbox, Basecamp, Ahrefs) of moving workloads back to on-prem or colocation and saving significant money.
The 2026 question isn't "should we be in the cloud?" It's "which workloads belong in cloud, which on-prem, and which at the edge?" And the answer requires honest unit economics most companies have avoided.
Below is the framework I use for cloud migration and repatriation decisions.
Three migration patterns
Cloud "migration" is shorthand for three structurally different operations. Most projects mix them, but the cost profiles diverge.
Lift-and-shift
Take the on-prem application as-is and run it on cloud VMs. Same architecture, same software, just running on EC2 instead of your datacenter.
Pros: fast. 3–6 months for most workloads. Low engineering risk.
Cons: doesn't capture any cloud-native benefits. Often more expensive than the on-prem version because cloud pricing assumes elasticity you're not using.
When it fits: tactical needs — your datacenter lease is ending, you need geographic redundancy fast, you're behind on hardware refresh and the capex is hard to justify.
Refactor
Move to the cloud and gradually replace components with cloud-native services. Move databases to managed services (RDS, Aurora), queues to SQS, file storage to S3, but keep the application logic largely intact.
Pros: meaningful cost and operational improvements (managed services have lower ops burden). Sets up for further modernization.
Cons: 9–18 months. Real engineering work. Vendor lock-in starts accumulating.
When it fits: most enterprise migrations. The middle ground that balances near-term cost with operational gains.
Rebuild (cloud-native from scratch)
Throw out the existing architecture; rewrite for cloud-native patterns — serverless, containerized microservices, event-driven architecture.
Pros: lowest long-term cost per unit, most operational agility, genuine cloud-native benefits.
Cons: 18–36 months. Highest engineering risk. The rebuild projects that fail are usually trying to do this while also maintaining the legacy system at full feature velocity.
When it fits: rare. Only when the existing system is so broken that a rewrite was needed anyway, and cloud is the obvious target.
The pattern most companies follow that works: lift-and-shift to unblock the immediate need, then refactor over 18–24 months as operational maturity grows. Rebuild only when there's no other path.
When cloud wins on cost
The cloud is cheaper for these workload profiles:
- Variable demand. Workloads that 10x during peak hours then drop to baseline. Cloud's elasticity makes the average utilization much better than dedicated hardware.
- Spiky compute (batch jobs, ML training, render farms). Pay only when running, instead of owning capacity for peak.
- Geographic distribution. CDN edge nodes, multi-region redundancy, global low-latency serving. Buying this on-prem is prohibitive for almost everyone.
- New workloads that haven't found a stable pattern yet. The optionality of cloud is worth the premium when you don't know what the steady state looks like.
When cloud loses on cost
Cloud is more expensive than well-operated on-prem or colocation for these profiles:
- Steady, predictable, high-utilization compute. Running 24/7 at 70%+ utilization. Cloud's pay-as-you-go model is dramatically more expensive than owning the hardware at that utilization.
- Large-scale storage. S3 at scale ($23/TB/month) vs. owning the same storage at $3–5/TB/month amortized over 4 years.
- High-bandwidth egress workloads. Cloud egress fees ($0.05– 0.09/GB) make any bandwidth-heavy service expensive. CDN-served video, file delivery, large-asset APIs.
- Mature, stable applications where the operational benefits of managed services don't justify the cost premium.
The Dropbox and Basecamp case studies got the headlines, but the math holds at the scale where they made the decision: high utilization, predictable load, large storage footprint, sophisticated in-house infrastructure team. At smaller scale, the operational overhead of running your own infrastructure usually eats the savings.
The real cost math
To know whether cloud is winning or losing on cost, you need a total cost of ownership (TCO) comparison that's honest about both sides.
Cloud TCO includes:
- Compute (instance hours)
- Storage (per GB per month, plus operations cost)
- Network (data transfer in/out, NAT gateway, load balancers)
- Managed services (RDS, ELB, CloudWatch, etc.)
- Cloud egress fees (often the largest hidden cost)
- Reserved instance / savings plan commitments
- Engineering time spent on cloud-specific complexity (FinOps, multi-account governance)
On-prem TCO includes:
- Hardware (servers, storage, networking)
- Datacenter colocation or facility costs
- Power and cooling
- Hardware lifecycle (3–5 year refresh)
- Engineering time for hardware operations
- Backup datacenter / disaster recovery infrastructure
- Software licenses (often higher on-prem because cloud bundles)
Both sides include engineering time. The honest comparison includes fully loaded engineer cost, not just the ones who'd be hired or freed by the decision.
A common pattern in mid-market companies (~$50–200M ARR): cloud TCO is 1.8–2.5x the on-prem TCO at steady-state high-utilization workloads. Cloud wins when you include cloud-only capabilities (auto- scaling, global serving, managed databases) that are operationally prohibitive on-prem.
A practical 2026 decision matrix
For each workload, score on three axes:
| Factor | Score 1 (favors cloud) | Score 5 (favors on-prem) |
|---|---|---|
| Demand variability | Highly variable | Steady, predictable |
| Utilization at peak | Sub-30% steady-state | 70%+ steady-state |
| Bandwidth profile | Low egress | High egress |
| Operational sophistication | No infra team | Mature infra team |
| Compliance / data sovereignty | None | Strict requirements |
| Cost of being wrong | Optionality matters | Lock-in acceptable |
Sum the scores. 1–10 → cloud. 11–20 → could go either way; do the TCO math. 21–30 → on-prem or hybrid.
The mistake: applying one verdict to all workloads. A mature company should have a heterogeneous infrastructure — variable workloads in cloud, steady high-utilization on-prem, edge content delivery on a CDN, regulatory-sensitive data in a private cloud or on-prem.
What "cloud repatriation" actually looks like
The repatriation pattern that works:
- Start with the highest-cost cloud workloads identified by FinOps analysis. Usually 3–5 specific services account for 60–80% of the cloud bill.
- For each, evaluate: lift to on-prem (if utilization is high and predictable) or re-architect to be more cloud-efficient (better reserved instance utilization, removing waste).
- Don't do a full repatriation as a single project. Move one workload at a time over 12–24 months.
- Keep the cloud presence for the workloads where it makes sense — new development, variable demand, global serving.
The companies doing this well end up at hybrid architectures by choice, not legacy. The companies doing it badly try to repatriate everything and find themselves rebuilding operational capabilities they'd lost over 8 years of cloud-by-default.
The 2026 infrastructure decision is more nuanced than 2018. Cloud is no longer the default answer; on-prem is no longer dead. The answer depends on workload profile, organizational capability, and an honest TCO analysis. Most mid-market companies will end up with a hybrid architecture that costs significantly less than pure cloud and gives them more operational flexibility — but only if they take the time to do the math.
For the tech-stack discipline that prevents bad infrastructure decisions in the first place, see Choosing Your Tech Stack.
