Few cloud topics generate as many strong opinions as repatriation, the practice of moving workloads out of public cloud and back to on-premises data centers, colocation facilities or private clouds. Some commentators describe a great cloud exodus. Others dismiss repatriation as a niche move by a handful of companies with unusual economics. Neither view is very helpful to a technology leader who simply wants each workload running in the right place at the right cost.
This article looks at what recent surveys and analysis actually say, why repatriation has returned to the agenda, when it makes sense and when it does not, and how to replace the cloud-first versus cloud-exit debate with a disciplined workload placement framework that also informs your migration roadmap.
What the Data Actually Says
The best available evidence points to selective movement rather than wholesale reversal. A Node4 survey of 601 executives at mid-market firms, reported by ITPro in June 2025, found that 49 percent planned to move a few applications and workloads off public cloud over the following year and 43 percent planned to move a significant number, while only 5 percent wanted to repatriate everything. In other words, almost nobody was planning a full exit. The reasons cited were varied: performance and latency led, followed by data sovereignty (30 percent), risk management (29 percent), technical limitations (27 percent), cost (26 percent), compliance (26 percent) and security (21 percent).
At the same time, public cloud use keeps growing. Flexera’s 2026 State of the Cloud Report, based on a survey of more than 750 cloud decision-makers and users and published in March 2026, found that 73 percent of organizations operate hybrid environments and that 76 percent of large enterprises spend more than $5 million a month on cloud services. It also reported that wasted cloud spend rose to 29 percent, the first increase in five years, which Flexera linked to surging cloud-based AI workloads, and that 85 percent of respondents say managing cloud spend is a top challenge.
Put together, these findings describe a world in which public cloud remains central, hybrid is the norm and organizations are increasingly willing to move specific workloads when the economics, performance or regulatory picture changes. That is not an exodus. It is the maturing of cloud strategy from a destination into a portfolio decision.
Repatriation is not the opposite of cloud strategy. It is one possible outcome of a good one: placing each workload where cost, control and service quality align, and keeping the option to move again.
Why Repatriation Is Back on the Agenda
Several forces have converged to make placement decisions more prominent in 2025 and 2026.
- Cost scrutiny: cloud spend is now large enough to attract board-level attention, and rising waste, particularly from AI workloads, has intensified the pressure.
- Data gravity and egress: data-intensive services that move large volumes between zones, regions or providers can incur significant network charges that were not visible in the original business case.
- Regulation and sovereignty: rules such as DORA for EU financial entities require documented exit strategies and evidence of resilience, while sovereignty concerns push some organizations to reconsider where sensitive workloads run.
- Virtualization licensing changes: changes to licensing for on-premises virtualization platforms have forced many organizations to revisit their private infrastructure strategy anyway, opening the door to broader placement reviews.
- AI infrastructure: GPU availability and cost have led some organizations to evaluate dedicated infrastructure, specialized GPU clouds or colocation for steady, predictable AI workloads.
When Repatriation Makes Sense and When It Does Not
In a September 2025 opinion piece for CIO.com, Antony Panteli of LTIMindtree described repatriation as a selective move suited to cases where cost, performance, jurisdiction or exit constraints favor private infrastructure, and explicitly not a retreat from the cloud. He also identified situations in which repatriation tends to underperform. Combining that analysis with common industry experience gives a useful set of signals.
Signals that favor moving a workload off public cloud
- Steady, predictable utilization with little need for elasticity, such as a large, stable database or a constant batch processing load.
- Very high data volumes with heavy egress or cross-zone traffic that cannot be reduced through architecture changes.
- Latency requirements tied to physical proximity, such as manufacturing systems or trading platforms.
- Regulatory or contractual requirements that cannot be met by the provider’s sovereign or regional options.
- An organization that already runs mature, efficient private infrastructure with the skills and automation to operate it.
Signals that favor staying in public cloud
- Elastic or seasonal workloads where paying for peak capacity on premises would be wasteful.
- Services that depend heavily on managed offerings, such as serverless functions, managed AI services or analytics platforms, which would need to be rebuilt.
- Organizations without mature private platform operations, where repatriation would shift effort and risk onto teams that are not ready.
- Situations where the real problem is poor cost hygiene: missing tags, idle resources or low discount coverage. Fixing those usually delivers savings faster than moving.
A Workload Placement Framework
Rather than debating repatriation in the abstract, evaluate workloads individually against a consistent set of criteria. The following framework works for both migration planning and periodic placement reviews.
Step 1: Segment the portfolio
Group workloads by characteristics that drive placement: utilization pattern (steady or variable), data intensity, latency sensitivity, regulatory classification, dependency on managed services and business criticality. Most portfolios fall into a handful of clusters, and placement decisions can be made at cluster level for all but the largest workloads.
Step 2: Model total cost over a realistic horizon
Compare options over a 12 to 36 month horizon, as Panteli recommends, including all relevant costs. For public cloud, include compute, storage, managed service premiums, egress and support, after realistic optimization. For private or colocation options, include hardware, facilities, power, licensing, staffing, refresh cycles and the one-time cost of moving. Compare the optimized cloud cost, not the current bill: many repatriation business cases compare an unoptimized cloud estate with an idealized private one.
Step 3: Score non-financial criteria
- Performance and latency: can the workload meet its objectives in each location?
- Resilience: what recovery capabilities are available, and how would they be tested?
- Regulation and sovereignty: where must data be stored and processed, and who can access it? Remember that legal reach is a separate question from data residency.
- Agility: how quickly does the team need to experiment, scale or adopt new services, including AI?
- Operational capability: does the organization have the skills and automation to run the workload well in each environment?
- Exit and portability: how hard would it be to move again later?
Step 4: Decide and design for optionality
Record the placement decision and its rationale. Wherever practical, design the workload to remain portable using open formats and interfaces such as Kubernetes, standard data formats and event streaming platforms, so the decision can be revisited if circumstances change.
Step 5: Rehearse the move
Before committing to any placement change, especially one that involves leaving a provider, rehearse the exit or migration with a non-critical subset. Panteli recommends pairing any placement change with an exit rehearsal; regulators increasingly expect documented and tested exit plans for critical services as well.
Step 6: Review periodically
Placement is not a one-time decision. Review the largest workloads annually, or when a significant trigger occurs: a major price change, a new regulation, a new provider capability or a change in usage patterns.
AI Workloads: A Special Case for Placement
AI deserves separate attention because it has changed the placement conversation more than any other workload type. Flexera’s 2026 research found that public cloud generative AI service usage rose from 50 to 58 percent of respondents, the largest increase across cloud services, while cost unpredictability was cited by 30 percent as a challenge in scaling AI. Those two findings capture the tension well: managed AI services are the fastest way to experiment and ship, but their costs can be hard to forecast.
A practical placement approach for AI separates workloads by phase and pattern:
- Experimentation and early production: managed model services and serverless inference in public cloud usually win, because speed matters more than unit cost and demand is uncertain.
- Bursty training and fine-tuning: on-demand or reserved capacity from a cloud provider or specialized GPU cloud avoids owning expensive hardware that sits idle between runs.
- Steady, high-volume inference: once demand is predictable, compare managed services with self-hosted models on reserved cloud capacity, dedicated infrastructure or colocation. This is where placement analysis most often changes the answer.
- Sensitive data and regulated use cases: sovereignty and data protection requirements may point to sovereign cloud regions, private deployments or customer-managed keys.
Whatever the choice, keep the application layer decoupled from a specific model endpoint through an abstraction such as an AI gateway, so models and hosting locations can change without rewriting applications.
What This Means for Migration Programs
The rise of placement thinking has practical implications for organizations still migrating to the cloud. First, not every workload needs to move. A portfolio assessment should explicitly allow a retain or relocate-to-private outcome, rather than treating anything left on premises as a failure. Second, the target architecture for migrated workloads should favor portability where it costs little, so future placement changes remain possible. Third, migration business cases should include ongoing optimization assumptions and governance, because the most common reason for disappointment with cloud economics is not the cloud itself but the absence of cost discipline after migration.
A Hypothetical Example
Consider a hypothetical media company that migrated most of its estate to public cloud four years ago. Cloud spend has grown steadily, and the CFO has asked whether moving back to colocation would save money.
A placement review segments the portfolio into four clusters. Customer-facing web and mobile services are highly variable, with traffic spikes during major events, and rely on managed services; they clearly stay in public cloud. The content analytics platform uses managed data and AI services heavily and also stays. The video transcoding farm runs at a steady, high utilization and moves large volumes of data; after modeling, colocation with dedicated hardware shows a meaningful cost advantage over three years even after including staff and refresh costs. An archive of older media is already in low-cost cloud storage tiers; moving it would incur egress charges that outweigh any savings.
The company decides to move only the transcoding farm, using a containerized pipeline that can run in either environment, and to rehearse the move with a subset of jobs first. At the same time, it launches a cost optimization effort on the remaining cloud estate, which addresses idle development environments and improves commitment coverage. The final outcome is a hybrid estate in which each cluster runs where it makes the most sense, with documented reasons and a review date.
Pitfalls to Avoid
- Comparing unoptimized cloud with idealized on premises. Optimize first, then compare.
- Ignoring the cost of people and refresh cycles. Private infrastructure requires ongoing investment in staff, hardware and facilities.
- Underestimating managed service dependencies. Rebuilding capabilities that a provider offered as a service can be expensive and slow.
- Moving without rehearsal. Untested moves create outages and erode trust.
- Treating placement as ideology. Neither cloud-first nor cloud-exit is a strategy. Workload-level evidence is.
Outlook
Between 2027 and 2030, workload placement is likely to become a routine part of cloud governance rather than an occasional controversy. Sovereign cloud offerings, dedicated and on-premises extensions from the major providers, specialized AI infrastructure providers and improving portability standards all widen the range of options. Regulators’ emphasis on exit planning and resilience will make documented placement decisions a compliance expectation in more sectors. The organizations that do best will be those that treat placement as a continuous, evidence-based decision supported by good cost data and portable architectures.
Conclusion
Cloud repatriation is real but selective. Surveys show that most organizations plan to move some workloads, not all, and that hybrid estates are now the norm. The right response is not to choose a side in a cloud-versus-on-premises debate but to adopt a workload placement framework: segment the portfolio, model realistic costs over a meaningful horizon, weigh performance, regulation, agility and operational capability, design for portability, rehearse any move and review regularly. That discipline delivers better outcomes whether a workload stays, moves or migrates for the first time.
How Hanoi Technology Can Help
Hanoi Technology helps organizations assess workload placement, model total cost and plan migrations or moves between environments, through projects, dedicated teams or managed services.