What Cloud Repatriation Actually Costs
Moving from AWS or Azure back to on-premises is not a sticker price — it is a total-cost-of-ownership decision. This guide breaks down the real cost categories, the trade-offs nobody puts on the slide, and how to tell when repatriation genuinely pays off.
So, what does it cost to move from the cloud to on-premises?
There is no single number — and anyone who quotes one is selling something. The real answer is a total-cost-of-ownership comparison over a 3–5 year horizon. You weigh the cloud costs you eliminate (compute hours, data egress, managed-service premiums, over-provisioning) against the on-prem costs you take on (hardware, colocation and power, networking, licensing, resilience, and operations), plus a one-time migration project. For steady, always-on workloads, owned infrastructure is usually cheaper and far more predictable. For spiky or experimental workloads, the cloud's elasticity often still wins. The rest of this guide gives you the framework to work out which side of that line your workloads sit on.
The Costs You Eliminate
Repatriation removes — or sharply reduces — several of the least predictable lines on a cloud bill. These are the savings that build the business case.
Compute & Instance Hours
On-demand and reserved instance charges disappear for the workloads you move. For steady, always-on systems this is usually the single largest line item you reclaim — you stop renting capacity by the hour for machines that run 24/7 anyway.
Data Egress & Transfer Fees
Cross-region and internet egress charges are among the least predictable cloud costs. Data-heavy and analytics workloads that move terabytes routinely can carry egress bills that rival compute. Repatriated traffic that stays inside your own network is effectively free.
Managed-Service Premiums
Managed databases, queues, search, and Kubernetes control planes carry a convenience premium over the raw infrastructure. Running the open-source equivalents on hardware you own removes that markup — at the cost of operating them yourself.
Over-Provisioning & Idle Waste
Cloud makes it easy to leave oversized instances, orphaned volumes, and forgotten environments running. Repatriation forces a rightsizing exercise, and owned capacity is sized once to real demand rather than paying a premium for elasticity you rarely use.
The Costs You Take On
Ownership means taking back everything the cloud quietly bundled into its price. A credible cost model accounts for all of it — especially operations, the line most business cases underestimate.
Hardware (CapEx or Lease)
Servers, storage arrays, GPUs, and network gear — bought outright or leased. This is the headline number, but it is amortised over a typical 3–5 year refresh cycle, which is what makes owned infrastructure competitive for stable workloads.
Colocation, Power & Cooling
Rack space, power draw, cooling, and cross-connects in a colocation facility — or the equivalent if you run your own room. Power and cooling are recurring operational costs that scale with how hard your hardware works.
Networking & Connectivity
Internet transit, redundant links, load balancers, firewalls, and any private connectivity back to remaining cloud services. Bandwidth is bought as committed capacity rather than metered per gigabyte.
Operations & Staffing
The cloud bundles a lot of undifferentiated ops into the price. On-prem, patching, monitoring, capacity planning, and hardware replacement become your responsibility — either added headcount or a managed-services partner. This is the cost most repatriation business cases underestimate.
Resilience & Disaster Recovery
High availability and DR that a cloud region gave you for a fee must now be engineered: redundant hardware, a second site or availability zone, backups, and tested failover. Skipping it is not a saving — it is deferred risk.
Software & Licensing
Hypervisors, operating systems, database licences, and support contracts that were folded into managed-service pricing become separate line items. Open-source stacks reduce this, but enterprise support is rarely free.
One-Time Migration Costs
Separate the project from the run-rate. Migration is a capital cost you pay once; the savings recur. You only start saving once the cloud environment is actually switched off — not just idle.
Assessment & TCO Modelling
Inventorying workloads, mapping dependencies, and building the side-by-side cost model that proves — or disproves — the business case before anything moves.
Target Build & Procurement
Lead time and cost of procuring hardware, standing up the destination environment, and configuring networking, storage, and security before the first workload lands.
Migration & Parallel Running
Engineering effort to move data and applications, plus the period where you pay for both cloud and on-prem at once while you validate the target and cut over safely.
Validation, Cutover & Decommission
Testing, phased cutover, and formally switching off cloud resources. Repatriation only saves money once the old environment is actually decommissioned — not just idle.
How to Model the Cost Honestly
A defensible cloud repatriation business case comes down to a simple structure. Build it per workload, over the life of the hardware, and resist the temptation to compare only hardware price against instance hours.
Set the horizon
Model over 3–5 years — the realistic life of the hardware — so a one-time capital outlay is compared fairly against recurring cloud spend.
Establish the cloud baseline
Pull 12 months of actual cloud spend for the workloads in scope, broken down by compute, storage, egress, and managed services. Use real usage, not list price.
Build the on-prem run-rate
Amortise hardware across the horizon and add colocation/power, networking, licensing, resilience/DR, and — critically — operations and staffing or a managed-services fee.
Add the one-time migration cost
Assessment, procurement lead time, migration engineering, and the parallel-running window where you pay for both environments at once.
Compare and find the break-even
Divide the migration cost by the monthly run-rate saving to find payback. If break-even lands well inside the hardware life with margin to spare, the case is strong.
When Repatriation Pays Off — And When It Doesn't
Repatriation usually wins for…
- Steady, always-on workloads with predictable capacity — databases, internal platforms, and batch systems that never scale to zero.
- Data-heavy or high-egress systems where transfer fees dominate the bill.
- Regulated or sovereignty-bound data that must stay in a specific jurisdiction or on infrastructure you control.
- Private AI/ML inference and training where GPU rental is expensive and data sensitivity is high.
- Mature workloads with a 3–5 year horizon, so hardware can be amortised and utilisation kept high.
The cloud usually wins for…
- Spiky, seasonal, or unpredictable demand that genuinely benefits from elastic scale-to-zero.
- Early-stage products still finding fit, where flexibility matters more than unit cost.
- Small footprints where owned hardware can never reach high enough utilisation to beat pay-as-you-go.
- Teams without the ops capability — or a partner — to run infrastructure to the reliability the business needs.
- Workloads that lean heavily on differentiated cloud-native services with no practical on-prem equivalent.
Cloud Repatriation Cost FAQs
The questions buyers ask before committing to a cloud exit
There is no single figure — the honest answer is a total-cost-of-ownership comparison over 3–5 years, not a sticker price. You model two things: the ongoing run-rate (cloud compute, egress, and managed-service fees you eliminate, versus on-prem hardware amortisation, colocation, power, networking, licensing, and operations you take on) and the one-time migration project (assessment, procurement, migration effort, and a period of parallel running). For steady, always-on workloads the on-prem run-rate is typically lower and far more predictable; the migration is a capital project that pays back over the equipment life.
Think in three buckets. First, cloud costs you eliminate: compute hours, data egress, managed-service premiums, and over-provisioning waste. Second, on-prem costs you take on: hardware (capex or lease, amortised over 3–5 years), colocation or facility power and cooling, networking, software licensing, resilience and DR, and — the one most business cases miss — operations and staffing. Third, one-time migration costs: assessment and TCO modelling, target build and procurement, the migration itself, and a parallel-running window before you decommission the cloud environment.
Repatriation tends to pay off for steady, always-on, data-heavy, or regulated workloads with a multi-year horizon — where you can size owned hardware to real demand and keep utilisation high. It rarely pays off for spiky or seasonal demand that benefits from scaling to zero, for small footprints that cannot reach high utilisation, or for teams without the operations capability to run infrastructure reliably. The deciding factor is usually workload stability and utilisation, not cloud versus on-prem as an ideology.
The biggest is operations and staffing — the cloud bundles patching, monitoring, capacity planning, and hardware replacement into its price, and those become your responsibility on-prem. Others include resilience and disaster recovery (redundant hardware and a tested second site), software and support licensing that was previously folded into managed-service pricing, hardware refresh at end of life, and the cost of running both environments in parallel during migration. A credible TCO model includes all of these, not just hardware versus instance hours.
Payback depends on the size of the one-time migration cost relative to the monthly run-rate saving. Because the migration is a capital project and the savings are recurring, most business cases are framed over the hardware life — commonly a 3–5 year window. The clearer and more stable the workload, the shorter and more reliable the payback. Volatile or under-utilised workloads can take so long to break even that the cloud remains the cheaper option.
Selective repatriation is usually the right answer. Most organisations run a hybrid estate: steady, data-heavy, or regulated workloads move to owned infrastructure, while spiky, experimental, or cloud-native-dependent workloads stay in the cloud. The cost exercise is done workload by workload — you repatriate the ones where the numbers clearly favour ownership and leave the rest where elasticity earns its premium.
We start with a fixed-scope assessment: a full inventory of your cloud workloads, data volumes, and dependencies, and a side-by-side TCO model that compares your current cloud run-rate against a realistic on-prem or private-cloud build — including operations, resilience, and one-time migration costs. You get a clear-eyed business case grounded in your real usage before any decision to move, and if the numbers favour repatriation we plan and deliver the migration with zero data loss and minimal downtime.
Want the real number for your workloads?
Book a fixed-scope assessment. Our engineers inventory your cloud estate, model the true on-prem TCO — operations and all — and hand you a business case grounded in your own usage, not a vendor's spreadsheet.
Get a repatriation cost assessmentGet your repatriation cost assessment — free
Tell us where your workloads run. A senior engineer sends back a TCO model and a fixed-scope plan — within two business days, no obligation.