When a public cloud bill becomes difficult to predict, the useful question is which workloads still benefit from running there. Some companies are moving selected applications and data to private infrastructure, while continuing to use public cloud for other needs. In Flexera’s 2025 survey, organisations estimated that they had repatriated 21% of their cloud workloads. Its 2026 report recorded a further increase of two percentage points.
The figures describe a selective move: public cloud remains useful for applications with changing demand, short projects and services that would be difficult to operate independently. At the same time, a predictable workload that moves large volumes of data may have a stronger business case elsewhere. The decision depends on what the workload costs, what it needs to do and what the organisation is prepared to manage.
What is cloud repatriation?
Cloud repatriation means moving an application, data or computing capacity out of a public cloud such as AWS, Microsoft Azure or Google Cloud. The destination can be a private cloud, which provides resources dedicated to one organisation; colocation (or colo), where a company houses its own equipment in a third-party data centre; or an on-premises data centre operated at the company’s own site. The move is also called reverse cloud migration.
Repatriation rarely means moving everything back into a company-owned server room. More often, a company moves selected workloads, meaning applications or computing tasks and the resources they need to run. For example, it might relocate a database that runs continuously while keeping its customer-facing application in public cloud. Cloud migration is the broader term: it includes moves into cloud and between cloud providers. Repatriation specifically moves workloads out of public cloud. When the remaining public cloud services work alongside private infrastructure, the resulting architecture is hybrid cloud.
The workloads that move most often are complete applications, databases, backups, computing capacity and individual components with predictable resource needs.
Why companies are moving workloads off public cloud
Repatriation usually responds to the requirements of particular workloads. Cost is a common reason, but data location, performance and dependence on a provider also shape the decision. Uptime Institute reported in 2025 that cost was the leading reason for repatriation among the enterprises it studied, while public cloud use continued alongside private infrastructure.
1. Rising and unpredictable cloud costs
Public cloud charges for the resources used, which helps when demand changes. For an application running at a steady level around the clock, the monthly bill can make dedicated capacity worth evaluating, by analyzing the total cost of ownership (TCO), which compares all costs over several years rather than one month’s compute price. The comparison should include capital expenditure (capex), such as purchased hardware, and operating expenditure (opex), such as subscriptions, power, support and maintenance. It must also account for licences, replacement equipment and the staff needed to operate the new environment.
Andreessen Horowitz estimated in 2021 that repatriation costs one-third to one-half of running equivalent workloads in the cloud, based on large software companies’ spending. One company’s savings cannot serve as a general forecast. In a 2025 account of its own storage plans, 37signals reported spending almost $1.5 million a year on AWS S3 and projected savings from moving that data to equipment in its data centres. Those figures reflect its contracts, data volumes and existing facilities.
2. Egress and data transfer fees
An application that regularly sends large volumes of data to users, another provider or an internal system can accumulate egress fees, the charges for data leaving a public cloud service. Analytics, media delivery and backup workflows deserve particular attention because data movement can be a large part of their bill.
During repatriation, the organisation may also need to transfer a large volume of data once. Both ongoing traffic and migration costs belong in the TCO calculation. Adding them to the TCO model shows how data movement affects the business case for keeping the workload in public cloud.
3. AI and GPU workload costs
AI inference is the process in which a trained artificial intelligence model handles a new request, such as analysing an image or generating a response. Some inference systems rely heavily on graphics processing units (GPUs), and if they run continuously at a predictable level, dedicated GPU capacity is worth comparing with rented public cloud capacity. The result depends on utilisation. Hardware left idle for much of the day still costs money, while a cloud service can suit experiments and sharply changing demand. A comparison should include the complete system, its power and cooling needs, support, and the time needed to add capacity.
4. Data sovereignty and compliance
Data residency and sovereignty are also important aspects: the first one concerns where data is stored, while the second concerns the laws and jurisdiction that apply to it. Both can affect how an organisation chooses and documents its infrastructure, particularly when it processes sensitive information across borders.
GDPR, HIPAA and the EU’s Digital Operational Resilience Act (DORA has applied to the EU financial sector since 17 January 2025) shape how organisations protect data and manage technology risks. These requirements do not, by themselves, call for workloads to leave public cloud, so the decision to use private infrastructure should be based on the controls, contracts and recovery arrangements the organisation needs.
5. Performance and data gravity
Some applications work best close to the systems or people they serve. A production system exchanging data constantly with equipment at a factory, for example, has different needs from a public website used across several countries. Distance, network design and the time taken to transfer data all affect performance.
Data gravity describes a practical consequence of storing large datasets: moving the data is slow or expensive, so it often makes sense to place processing close to it. For a high-volume database or analytics workload, a network and storage assessment maps where the data is stored, how often it moves and which connections carry it.
6. Vendor lock-in
An application built around proprietary databases, APIs or managed services may require changes to its data layer, integrations or deployment process before it can leave public cloud. This dependence on a provider’s technology or commercial terms is known as vendor lock-in. Repatriation can give an organisation more control over its infrastructure, but it does not erase every dependency. Teams still need to consider software licences, hardware suppliers and the services they use in the new environment. Documenting these dependencies before the move makes later changes easier to plan.
Cloud repatriation by the numbers
Organisations are moving some workloads out of public cloud, while public cloud use and spending continue to grow. The percentages also measure different things: the share of workloads already moved is not the share of companies abandoning cloud services.
| Finding | Source and year | What it means |
|---|---|---|
| Organisations estimated that they had repatriated 21% of cloud workloads | Flexera, 2025 | Repatriation remains selective; most workloads remain in public cloud. |
| The estimated share of repatriated workloads rose by two percentage points | Flexera, 2026 | Repatriation continued at a similar pace into 2026. |
| 73% of organisations operated hybrid cloud environments | Flexera, 2026 | Hybrid infrastructure is the prevailing setup among respondents. |
| Worldwide spending on infrastructure as a service was forecast to grow 29.3% in 2026 | Gartner, July 2026 | Demand for public cloud infrastructure remains strong, alongside selective repatriation. |
A company can repatriate a database and increase its public cloud use elsewhere in the same year. That is why reports about the number of organisations planning at least one move should not be read as the percentage of all workloads leaving cloud providers. Uptime Institute’s 2025 analysis also found that repatriation had not reduced cloud usage across the enterprises it studied.
Company case studies reflect one company’s contracts, data volumes and facilities. 37signals reported in October 2024 that moving its compute out of the cloud saved almost $2 million a year (company figures). Dropbox recorded $75 million in savings over two years before its 2018 IPO, and its gross margin rose from 33% to 67% between 2015 and 2017, as a 2021 Andreessen Horowitz essay detailed.
Which workloads should move, and which should stay in public cloud?
A workload is a candidate for repatriation when its costs or operating requirements improve in a different environment. The categories below are starting points for analysis:
| Worth assessing for repatriation | Usually better left in public cloud |
|---|---|
| Applications running continuously with predictable resource needs | Applications with large or unpredictable demand peaks |
| Databases and analytics systems that move large amounts of data | Short-lived development, testing and experimental projects |
| Steady AI inference workloads with high GPU utilisation | AI projects whose capacity needs are still uncertain |
| Systems that need to run close to equipment, staff or large datasets | Services that need to be deployed quickly across many regions |
| Workloads subject to specific location or operational controls | Applications closely dependent on a provider’s managed services |
A stable application is not automatically cheaper outside public cloud, as its dedicated replacement still needs enough capacity for busy periods, suitable recovery arrangements and an operating team. Likewise, data subject to regulation is not automatically unsuitable for public cloud. The decisive questions concern the required controls and whether they can be implemented in each proposed environment.
Start with measurements: usage across the day, data transfer, storage growth, response times and the current bill. Then compare a realistic destination over several years. This prevents a costly move based on an unusually expensive month or an assumption that all cloud resources are priced alike.
Where do repatriated workloads go?
A repatriated workload can run in the organisation’s own data centre, in a private cloud hosted on-site or by a provider, or on servers housed in a colocation facility. If the organisation keeps other services in public cloud, the resulting setup is hybrid.
On-premises data centres
An on-premises data centre houses equipment at a site the organisation operates. This gives the company direct control over hardware and the facility, together with responsibility for power, cooling, physical security, maintenance and replacement cycles. It is easier to justify when suitable infrastructure and a capable operating team already exist.
Private cloud
A private cloud provides dedicated computing resources to a single organisation, with cloud-style provisioning and management, and it can be hosted internally or by a provider. This option suits workloads that benefit from dedicated capacity while the organisation retains a way to allocate resources between applications without managing each physical server separately.
The ownership and cost model depend on the contract. A provider-hosted private cloud does not necessarily require the organisation to buy the underlying hardware.
Colocation
With colocation, a company owns and manages its servers and network equipment but rents space in a third-party data centre. The provider supplies the facility, power, cooling, physical security and connectivity. The company remains responsible for the equipment and the applications running on it.
This suits an organisation that wants dedicated hardware without operating its own facility. M247 Global offers colocation space with power, cooling and connectivity, including options for direct connections to other networks. Its facilities are built to Tier 3 specifications, which means supporting infrastructure can undergo planned maintenance without shutting down IT equipment.
Hybrid as the end-state
After a selective move, stable workloads might run in colocation or private cloud while applications with variable demand remain in public cloud. Connecting those environments creates a hybrid architecture. If the organisation also uses two or more public cloud providers, the setup is multi-cloud as well.
| Consideration | Public cloud | Provider-hosted private cloud | Colocation | On-premises data centre |
|---|---|---|---|---|
| Typical cost model | Usage-based charges | Contracted dedicated resources | Space, power and services | Facility and equipment costs |
| Hardware control | Provider-owned | Dedicated, usually provider-owned | Customer-owned | Customer-owned |
| Data and compliance controls | Depend on service and configuration | Depend on contract and configuration | Customer controls its equipment | Customer controls equipment and site |
| Latency | Depends on region and network | Depends on hosting location and network | Depends on facility and connections | Depends on site and connections |
| Capital and operating costs | Mainly operating costs | Mainly operating costs | Hardware purchase plus recurring fees | Facility and hardware costs plus operations |
| Adding capacity | Provision resources within service limits | Requires available dedicated capacity | Requires equipment, space and power | Requires equipment and facility capacity |
The comparison cannot determine compliance or performance on its own, as the outcomes depend on the chosen location, network, contracts and technical controls.
Connectivity is another important aspect after a move. A cross-connect links equipment to another network within a data centre; a cloud connect service provides a private route to a public cloud provider. Where an organisation retains services in AWS, Microsoft Azure or Google Cloud,M247 Global’s Cloud Connect offers direct connections to those platforms. The application still needs appropriate security, capacity planning and monitoring across both environments.
The risks and challenges of cloud repatriation
Moving a workload out of public cloud involves migration costs and new operating responsibilities. Any projected savings need to survive a comparison with hardware, licences, staffing, connectivity and recovery costs over the equipment’s useful life. The main challenges are:
The migration approach also varies. Rehosting moves an application with relatively few changes. Replatforming changes parts of its underlying platform, while a larger redesign may be needed when the application depends heavily on proprietary services. A dependency assessment determines which approach fits each workload.
How to plan a cloud repatriation
Cloud repatriation works best as a series of decisions about individual workloads. The starting question is which applications are stable, data-intensive or constrained enough to justify a different home once all costs and responsibilities are counted. Public cloud can remain part of the resulting architecture. Where a move calls for customer-owned hardware and a connection back to public cloud services, colocation and private connectivity provide a practical route.