Cloud Repatriation: When Moving Back In-House Pays Off

For a decade, the public cloud was the default answer to every infrastructure question. Now many companies are examining the return trip – not out of principle, but because for certain loads the math no longer works out. “Cloud repatriation” means exactly that: moving individual workloads out of the public cloud back into your own data center or into a private environment. This is not a rejection of the cloud, but a correction where it was the wrong tool.

What matters is a sober reading of the numbers. The often-cited figure from the Barclays CIO survey – around 83% of the companies surveyed plan to move at least some workloads back – does not mean 83% are leaving the cloud. It counts companies, not loads: if each of these companies brings back a single application, the statement is correct – and the hyperscalers’ cloud revenues still keep rising. IDC puts the hard core correspondingly low: only about 8 to 9% of organizations plan a full repatriation. The trend is real, but selective. It is about the right loads in the right place, not a roll backward.

Why steady loads become expensive in the cloud

The public cloud pays off where elasticity has genuine value: with fluctuating load, short peaks, projects with an uncertain outcome. You pay for capacity by consumption and don’t have to keep it on standby. This very model reverses as soon as a load is predictable and permanent. A database server running around the clock at stable utilization, a file service, an ERP backend – such systems run 8,760 hours a year. For permanently reserved capacity, you pay a surcharge in the cloud for a flexibility you never draw on.

Then there are costs that tend to be missing from the first calculation. The single biggest trigger for repatriation analyses is egress fees – the cost of data leaving the cloud again. For data-intensive workloads, companies report 50,000 to 500,000 US dollars annually in outbound traffic alone. On top of that comes the quiet waste: on average, around 21% of cloud spend goes to unused or oversized resources. That is not a cloud failure, but the nature of a model that makes provisioning easy and decommissioning hard.

A prominent worked example comes from the software company 37signals. After exiting AWS, the annual infrastructure bill fell from around 3.2 million US dollars to well under one million. The compute migration to its own Dell servers for around 700,000 US dollars brought about two million US dollars in annual savings; the subsequent storage move to its own hardware for around 1.5 million US dollars (18 petabytes) lowered running costs to under 200,000 US dollars a year. This is an extreme case with very large, stable data volumes – but it shows the pattern: the steadier and more data-heavy the load, the sooner purchased capacity beats rented.

Not just cost: data residency, latency, control

Economics is the most frequent, but not the only reason for the return trip. Three further motives often weigh more heavily in the mid-market than a pure cost table shows.

Data residency and regulation. Where data physically resides and who can legally access it has long since ceased to be a side issue. For regulated industries and for companies within the scope of NIS-2, the demonstrable location of the data and control over the processing chain is a solid argument – one that is easier to make in your own or a clearly assigned environment than in a shared public cloud region.
Latency and proximity to production. Control systems, measurement technology, and production-adjacent applications do not tolerate fluctuating round trips over the internet. Where milliseconds count or a plant must not halt on a lost connection, processing belongs close to the place where it is needed.
Control and predictability. Owned capacity costs a steady, predictable amount; a consumption-based cloud bill only partly does. For businesses that must budget their IT costs over years, predictability is itself a value.

None of these points is a blanket argument against the cloud. They are criteria by which each individual load can be classified.

How to decide cleanly: workload profiling and TCO over 3–5 years

Repatriation is a portfolio decision, not a question of principle. The path there runs through two steps.

First: profile your workloads. Sort your loads by load profile and requirements. Elastic and fluctuating – campaigns, development environments, seasonal peaks – as a rule stays better in the cloud. Steady, data-heavy, latency-sensitive, or regulatorily bound – those are the candidates for in-house. Only this profile tells you what is even worth calculating.

Second: compute TCO over three to five years, not over a month. The honest comparison sets against the cloud bill not just the hardware price, but the full on-prem cost over the depreciation period: servers and storage including amortization, power and floor space or colocation, maintenance, licenses, and the operational effort. On the cloud side, egress, data transfer between zones, and the real waste belong in – not the list price of an optimally utilized reserved instance. Compute over the period in which the hardware actually runs. For permanently stable loads, the break-even in many cases lies around one and a half years; over three to five years the actual gap then emerges. The number that counts is not the hourly price, but the total cost over the useful life.

What matters is honesty in both directions: an on-prem calculation that omits staffing and operational effort is just as worthless as a cloud calculation without egress. In the end there is no worldview, but a table per workload.

The hybrid answer: the best of both worlds

For most mid-market companies, the answer is not “everything back,” but “the right thing in the right place.” A hybrid model is designed for exactly that: steady, data-intensive, or regulatorily bound systems run in-house – on request on premises on your own server and storage hardware or in a professionally operated data center. Elastic loads stay where elasticity counts. And data protection is replicated across site boundaries, so that an outage in one place does not hit the entire company.

sector7 delivers these options from a single source. You can operate systems on your own premises – as an HPE partner we plan and deliver server and storage infrastructure; Dell, Fujitsu, or special configurations we procure on request. Or you move the load into our own German server park, which was modernized in 2018, 2022, and 2026 and carries private as well as hybrid cloud and IaaS offerings. Backup and disaster recovery we replicate on the basis of Veeam into our server park – the second copy off-site, without you having to maintain a second location yourself. This way control over data and location stays with you, while the operational load lies with us.

How sector7 helps

We begin with the honest stocktaking: workload profiling of your environment and a TCO analysis over three to five years that fairly compares the cloud bill and the on-prem total cost. From this comes no dogma, but an assignment – which load stays in the cloud, which belongs in your own data center or in our private/hybrid cloud, which is only replicated for data protection. As an owner-led business in Solingen with vendor-certified engineering practice (Juniper, Cisco, HPE, F5, Fortinet, Palo Alto Networks), we plan, migrate, and operate the target environment, secure it with Veeam, and monitor operations around the clock through our NOC – on request at predictable flat monthly rates.