Cloud repatriation makes sense when moving a workload out of public cloud offers a demonstrable improvement in cost, performance, control or resilience. The case should account for the engineering work required to move it and the capability needed to operate it in the proposed environment.
For some workloads, on-premises infrastructure or dedicated hosting may provide a stronger long-term foundation. Others may benefit more from cloud optimisation, application modernisation or a hybrid approach.
For CIOs and CTOs, the decision starts with what each workload needs to support the business now and in the future. Compare realistic options against those requirements, establish the full costs and dependencies and determine whether the expected benefits justify the investment and delivery risk.
What is cloud repatriation?
Cloud repatriation is the process of moving applications, data or infrastructure workloads from public cloud to on-premises infrastructure, privately operated infrastructure in a co-location facility, or dedicated hosting. The destination may use a private cloud operating model.
It can involve moving an entire application or selected components while others remain in public cloud. The workload does not need to have previously operated outside public cloud.
An organisation might move a predictable, resource-intensive workload to dedicated infrastructure while continuing to use public cloud where elastic capacity or managed services meet its requirements.
The FinOps Foundation’s workload-placement framework recommends reviewing placement decisions as usage, pricing and business requirements evolve, considering financial outcomes alongside performance, availability and operational capability.
Why organisations consider cloud repatriation
Unexpected costs, performance limitations, operational constraints or critical dependencies can prompt an organisation to reassess where its workloads should run. Changes in demand and future business requirements may also make a different environment worth considering.
Cloud costs warrant reassessment
Public cloud provides infrastructure and managed services without requiring the organisation to purchase and maintain the underlying hardware. Elastic capacity can be particularly valuable when demand varies substantially.
For workloads that consume significant resources continuously, dedicated infrastructure may offer competitive economics. The comparison needs to account for actual utilisation, expected growth, service requirements and the full cost of operating each environment.
First, establish what the workload could cost in an optimised cloud environment. Oversized resources, unnecessary environments, inefficient processing and unclear responsibility for spending can all inflate the current bill. Right-sizing, architectural improvements and appropriate pricing commitments may address these costs without relocation.
Our guide to cloud cost optimisation explores how engineering and operating practices affect cloud expenditure.
Use that optimised baseline to assess whether repatriation offers a sustainable advantage after migration, ongoing support and future capacity costs are included.
Performance requirements favour another environment
Some applications may perform better when located closer to dependent systems or given access to dedicated hardware. Establish where the current bottleneck sits and how the proposed environment would address it.
Measure response times, processing throughput and the contribution of network latency under representative demand. Test the proposed architecture against those requirements, including its connections to services that will remain elsewhere.
Where application design, inefficient queries or processing logic cause the limitation, targeted engineering improvements may deliver more value than relocation. Repatriation is justified on performance grounds when evidence shows that the proposed environment can deliver the required improvement.
Critical dependencies need reassessment
Public cloud transfers responsibility for much of the underlying infrastructure to the provider. Applications may then depend on its managed services, identity controls, regional availability and contractual arrangements.
Assess which dependencies could interrupt an important service, limit future changes or make it difficult to move the workload. Repatriation may provide greater control over particular components, while introducing dependencies on hardware suppliers, software vendors, data centre facilities and specialist support.
Compare how each option would address the specific dependency and what operational responsibilities it would create. For financial services firms within scope, the FCA’s outsourcing and operational resilience guidance sets expectations for managing outsourcing and third-party risks. Our article on the UK Critical Third Party regime and cloud concentration risk explores the implications of provider concentration.
Possible responses include repatriating selected components, improving resilience within the existing platform, using another provider for defined capabilities or developing and testing an exit plan. Multi-cloud arrangements need particular scrutiny. Shared identity, networking, data or tooling can leave a service dependent on one provider even when workloads span several.
The preferred approach should demonstrate how the relevant dependency will be reduced or managed, with testing proportionate to the importance of the service.
Sovereignty requirements need explicit assessment
Some workloads require particular control over where data is stored and processed, who can access it and which legal jurisdictions apply to the provider and its operations.
Distinguish data residency from wider sovereignty requirements. Selecting a UK data centre establishes a location, but the assessment must also consider administrative access, support arrangements, subcontractors, encryption-key control and dependencies on externally operated services.
Repatriation may help meet these requirements, but privately hosted infrastructure can still rely on overseas support, software licensing or remote management. Compare the actual controls and dependencies of each proposed environment, including public cloud options.
Define the requirements for the workload, establish which arrangements meet them and identify the evidence needed to verify this before approving a move.
Data and AI workloads change the economics
For data-intensive applications, placement affects both processing and the cost of moving information between systems. Assess where data is generated, stored and used, how frequently it moves and which network charges apply. Keeping processing close to the data may reduce transfer costs and latency.
GPU-intensive AI workloads with sustained demand may justify comparing cloud pricing with dedicated capacity. The assessment needs to establish whether the proposed hardware provides the GPU memory, interconnect performance, storage throughput and software compatibility the workload requires.
Model expected utilisation across training, inference and idle periods. Include power, cooling, maintenance, specialist support and the capacity needed as models and demand evolve. Dedicated hardware should meet foreseeable requirements over its expected useful life, with upgrade and replacement costs included.
Software licensing and support terms can also affect the comparison. Confirm how these apply in each environment and whether relocation would change charges or access to essential capabilities.
Our guide to on-premises and air-gapped private AI deployment explores the infrastructure and operating requirements in more detail. Our article on cloud migration strategy as a risk trade examines how placement decisions change costs, responsibilities and dependencies.
Which workloads should be considered for repatriation?
Prioritise workloads where a different environment could address a specific cost, performance or operational constraint. Use the characteristics below to identify candidates and establish what evidence is needed to assess them.
| Workload characteristic | Why it warrants assessment | Evidence to collect |
|---|---|---|
| Stable demand and sustained utilisation | Dedicated capacity may offer competitive economics where demand requires limited elasticity. | Utilisation over a representative period, including seasonal peaks; growth forecasts; capacity headroom; existing cloud commitments; and potential optimisation savings. |
| Significant data movement costs | Placing processing closer to the data may reduce transfer charges and latency. | Data sources and destinations, transfer volumes and frequency, network charges, access patterns and integration dependencies. |
| Latency-sensitive processing | Proximity to dependent systems or access to dedicated resources may improve performance. | Measured bottlenecks, response-time requirements and target-environment tests under representative demand. |
| Limited reliance on cloud-managed services | Fewer provider-specific dependencies may reduce the engineering work required to relocate. | Architecture, managed-service dependencies, licensing terms and the cost of providing equivalent capabilities. |
| A defined provider dependency to address | Alternative placement may improve control or reduce exposure to a particular service or provider. | Dependency maps, credible disruption scenarios, continuity requirements and evidence that the alternative addresses the identified risk. |
| Available infrastructure and operating capability | Existing facilities, skills, DevOp practices and support arrangements may make the destination more practical to operate. | Available capacity, staffing, security and support processes, DevOps practices, recovery capability, hardware lifecycle costs and any additional investment required. |
| Defined sovereignty requirements | Alternative placement may provide the required jurisdictional, access or operational controls. | Data locations, provider and subcontractor jurisdictions, administrative access, support locations, encryption-key control and external service dependencies. |
Consider a legacy application with steady demand and a substantial cloud bill. Dedicated infrastructure may look attractive, but the application could also rely on managed databases, identity services, monitoring and integrations with systems remaining in cloud.
The assessment must account for how those capabilities would be provided, what application changes would be required and who would operate them. These dependencies can materially change the cost and feasibility of relocation.
Our cloud migration assessment guidance provides a starting point for mapping the workload and its dependencies.
Use the findings to shortlist realistic placement options and identify the assumptions that need testing before a migration decision.
When cloud repatriation is the right call
A workload becomes a credible candidate for repatriation when the assessment demonstrates a worthwhile benefit and a practical route to delivering it. Before approving the move, establish five things.
- The destination meets business and service requirements. Evidence shows that the proposed environment meets functionality, performance, security, capacity and recovery requirements, including any defined sovereignty requirements and expected changes in demand.
- The benefit holds against realistic alternatives. Compare repatriation with an optimised cloud environment over the same period. A sufficient cost advantage can justify the move, as can a measurable improvement in performance, control or resilience.
- The transition is affordable and achievable. Include application changes, replacement of managed services, data migration, testing, parallel operation and decommissioning. Identify dependencies and how service continuity will be maintained as the work progresses.
- The organisation can sustain the operating model. People, facilities, support arrangements, infrastructure automation and delivery pipelines are in place or funded to deploy, operate, secure, monitor and maintain the workload. Capacity growth and hardware replacement are included in the plan.
- The critical assumptions have been tested. Validate the factors most likely to change the decision, such as target performance, data transfer times or the effort required to replace a managed service. Define measurable outcomes and acceptance criteria before delivery begins.
Together, these findings provide the basis for an accountable investment decision and a controlled migration plan.
When retaining or optimising public cloud is the better choice
The assessment may show that the workload’s current environment provides a stronger foundation, particularly where:
- Elastic capacity meets a genuine need. Highly variable or unpredictable demand may favour cloud capacity that can scale with usage. Dedicated infrastructure would need sufficient headroom for peaks, with the associated cost and capacity planning.
- Managed services provide substantial value. Cloud databases, analytics, messaging or other managed capabilities may reduce development and operating effort. Include the cost of providing equivalent functionality, support and resilience elsewhere.
- The proposed operating model has unresolved gaps. Staffing, maintenance, security, monitoring and recovery responsibilities must be funded and assigned. Where those arrangements cannot be established, relocation would introduce operational risk.
- The financial advantage disappears under realistic assumptions. Test the case against lower utilisation, demand growth, additional support costs and greater migration effort. If modest changes remove the expected benefit, optimisation may offer a more dependable return.
- Application design is the main constraint. Tight coupling, inefficient processing or poor test coverage may require engineering improvements whichever environment hosts the workload. Assess whether modernisation in the existing cloud environment would deliver the required outcome more effectively.
Use these findings to direct investment towards the changes that best support the workload’s future requirements. That may mean improving its cloud architecture, modernising the application or continuing to operate it with appropriate maintenance and review.
How to calculate the business case for cloud repatriation
Compare three realistic options over the same period:
- Continue operating the workload in its current public cloud environment, including expected changes in demand and pricing.
- Optimise the workload while retaining it in public cloud.
- Move it to the proposed on-premises infrastructure, co-located infrastructure or dedicated hosting environment.
Use consistent assumptions about functionality, demand, performance, security, availability and recovery. Where options provide different outcomes, explain those differences alongside the costs.
For public cloud, include compute, storage, networking, managed services, software licensing, support, security, monitoring and operations. Model achievable optimisation savings and any pricing commitments required to obtain them.
For the proposed destination, include hardware or hosting, capacity headroom, facilities, power, cooling, networking, licensing, staffing, recruitment, training, maintenance, security, backup, disaster recovery and future replacement. Include the platform engineering required to recreate automation and operational capabilities previously supplied by the cloud provider.
For the transition, include application changes, replacement of managed services, data transfer, testing, specialist engineering, parallel operation and decommissioning. Include any provider data egress charges for transferring data out of public cloud, checking applicable rates and migration-related waivers. Account for cloud commitments and contractual charges that would continue after the workload moves.
Make the costing method explicit. Distinguish additional expenditure from allocations of existing shared costs. State how hardware purchases, financing, useful life and residual value are treated and avoid counting both purchase costs and depreciation in the same comparison. Show when expenditure occurs so affordability can be assessed alongside the total.
An illustrative three-year comparison
The following figures represent a hypothetical workload. They are illustrative, rather than Catapult CX project results or industry averages.
| Cost category | Current public cloud | Optimised public cloud | Repatriated environment |
|---|---|---|---|
| Infrastructure and platform | £330,000 | £255,000 | £190,000 |
| Operations, support and security | £90,000 | £90,000 | £135,000 |
| Optimisation, migration and transition | £0 | £15,000 | £55,000 |
| Three-year total | £420,000 | £360,000 | £380,000 |
For this simplified example:
- All options meet equivalent functionality, capacity, security, availability and recovery requirements.
- The repatriated infrastructure figure includes the full hardware purchase and associated platform costs within the three-year period. No residual value is credited and no hardware replacement is assumed during that period.
- Operations figures include the staffing, support and security resources needed for each option.
- Transition figures include implementation, data movement, testing, parallel operation and decommissioning.
- No unused cloud commitments or additional exit charges remain after migration.
- Figures are undiscounted and exclude VAT.
Repatriation reduces the modelled cost by £40,000 compared with continuing unchanged. Cloud optimisation produces the lowest total, saving £60,000 against the same baseline.
Repatriation is £20,000, or approximately 5.6%, more expensive than optimisation. In this example, where the options meet equivalent service requirements, optimisation provides the lowest modelled cost. If repatriation is expected to deliver additional performance, control or resilience benefits, quantify those separately and explain how they justify the £20,000 difference.
The FinOps Foundation’s workload-placement framework supports comparing financial outcomes alongside performance, availability and operational requirements.
Test scenarios including demand growth, lower hardware utilisation, earlier replacement, additional engineering work and higher support costs. Establish which assumptions could change the preferred option and gather further evidence where the decision depends on them.
What should determine the final decision?
Use the financial comparison alongside evidence about service requirements, dependencies and operating capability. Agree the criteria for proceeding and who has authority to approve the investment.
| Decision | What the evidence should demonstrate |
|---|---|
| Proceed with repatriation | The proposed environment meets business and service requirements, offers a worthwhile benefit over realistic alternatives and has an affordable transition plan with funded operational ownership. Critical assumptions have been validated and remaining risks explicitly accepted. |
| Investigate further | A potential benefit exists, but specific uncertainties could change the decision. Define the tests needed to resolve them, with owners, costs and a decision date. |
| Retain, optimise or modernise in cloud | The existing environment can meet future requirements more effectively, or changes to the application or its cloud configuration offer better value than relocation. |
Set the required benefit in the context of the workload’s importance, expected life and delivery complexity. A cost saving may justify one move; another may warrant investment to meet a performance or resilience requirement.
Record the recommendation, supporting evidence, assumptions, remaining risks and accountable decision owner. Define how costs, performance and service outcomes will be measured after implementation and when the placement decision will be reviewed.
This gives the organisation a clear basis for approval and a benchmark for assessing whether the investment delivers its intended value.
Cloud repatriation and hybrid cloud. How they fit together
Repatriating selected workloads can form part of a hybrid cloud strategy. An organisation may use public cloud where elasticity and managed services offer value, while operating other workloads on private or on-premises infrastructure.
The decision should account for how those environments work together. Applications split across them need reliable connectivity, clear data ownership, consistent access controls and monitoring that supports the whole service.
Multi-cloud is a separate consideration. It uses services from more than one public cloud provider. It may meet specific technical or commercial requirements, but requires its own justification for the additional skills, integration and management involved.
Where resilience is the objective, establish whether the proposed design can maintain the required service during the disruption being considered. Dependencies on shared identity, networking, data or tooling can affect both hybrid and multi-cloud arrangements.
For financial services firms within scope, the FCA’s outsourcing and operational resilience guidance addresses the management of dependencies supporting important business services, including third parties. Cloud services are permitted where applicable requirements are met. Assess each environment against the relevant security, governance and resilience obligations.
How to plan cloud repatriation
Once the business case supports relocation, develop a delivery plan that maintains service continuity and validates the proposed environment before each stage proceeds.
Our Assess. Map. Move. migration methodology provides a structure for this work.
Assess. Confirm the requirements and delivery scope
Define the business outcome, baseline measures and evidence needed to demonstrate improvement.
Confirm current and expected demand, operating costs, dependencies, data flows, performance requirements, security controls and recovery objectives. Identify the cloud services the application uses and how equivalent capabilities will be provided in the destination.
Use the findings to confirm which components will move, which will remain in cloud and what engineering work is required. Resolve any uncertainties that could materially change the scope or business case.
Map. Design the destination and transition
Design the infrastructure, software, integrations and controls needed to meet the agreed requirements. Establish capacity, backup, disaster recovery, access management, monitoring and operational ownership before migration begins.
Plan how applications and data will operate during the transition. Temporary connections, additional identities and parallel services need defined security controls, responsibilities and removal dates.
Our guide to cloud migration security and Zero Trust explains how to control these transition arrangements.
Set validation checkpoints, data reconciliation procedures, acceptable service interruption and operational acceptance criteria. Agree how issues will be corrected, how service continuity will be maintained and what evidence is required before the next stage proceeds.
Move. Migrate, validate and improve
Where practical, begin with a clearly defined workload or migration stage that tests the critical assumptions.
Validate data integrity, performance, access controls, integrations and recovery capability against the acceptance criteria. Resolve discrepancies and confirm operational readiness before progressing to wider production use.
Once the workload is established in the destination, measure costs, performance and service reliability against the business case. Confirm whether the targeted dependencies have been reduced and whether the operating team can support the service effectively.
After acceptance, decommission superseded cloud resources, remove temporary connections and identities and end unnecessary services or licensing commitments where contracts allow. Confirm that required data remains accessible and dependent services continue functioning.
Use the results to refine subsequent migration stages and guide future capacity, architecture and operating decisions.
Cloud repatriation. What CTOs and CIOs should do next
Start with one workload where cost, performance or a critical dependency warrants reassessment. Define what needs to improve and use the evidence to compare cloud optimisation, application modernisation and alternative placement.
The outcome should be a clear recommendation, with the expected benefit, investment required and next steps for validation or delivery.
Discuss the right environment for your workload
Tell us which application or service is becoming expensive, slow or difficult to operate and what you need it to support in the future. You don’t need a complete assessment to start the conversation.
Catapult CX’s Migrations service helps organisations understand dependencies, assess placement options and deliver controlled changes across infrastructure, applications and data.
Talk to us about your workload
Cloud repatriation FAQs
What is cloud repatriation?
Cloud repatriation moves applications, data or infrastructure workloads from public cloud to on-premises infrastructure, privately operated infrastructure in a colocation facility or dedicated hosting. It can involve an entire application or selected components. The workload does not need to have previously operated outside public cloud.
Is on-premises infrastructure cheaper than public cloud?
It can be, particularly for sustained workloads that use dedicated capacity efficiently. Compare the full cost against an optimised cloud environment, including hardware, staffing, facilities, licensing, security, recovery, migration and future replacement. Existing cloud commitments may also create costs after the workload moves.
Which workloads are suitable for cloud repatriation?
Candidates may include workloads with sustained utilisation, significant data-transfer costs, specific latency requirements or a provider dependency that needs addressing. These characteristics justify assessment. The decision depends on whether the alternative meets service requirements and offers sufficient benefit after transition and operating costs are included.
What are the main risks of cloud repatriation and how are they managed?
Risks include underestimated engineering work, unresolved dependencies, inconsistent data, service interruption and gaps in capacity or operational support. Manage them through dependency mapping, representative testing, data reconciliation and staged delivery where practical. Set acceptance criteria and resolve issues before progressing to the next stage.
Can cloud-native applications be repatriated?
Yes, but applications that rely heavily on provider-specific services may need substantial changes. Assess how databases, messaging, identity, monitoring and other capabilities would be provided and supported in the destination. Include that engineering and operational effort in the business case.
Does moving on-premises improve compliance?
Compliance depends on the applicable obligations and how the environment is designed, secured, governed and operated. Location may help meet a specific requirement, but it does not establish compliance by itself. Assess data handling, access controls, audit evidence, supplier arrangements and service resilience in each proposed environment.
How does cloud repatriation fit with hybrid cloud?
Moving selected workloads out of public cloud can form part of a hybrid strategy. Other components may remain in cloud where managed services or elasticity provide value. Assess connectivity, data flows, access controls and operational ownership across the combined environment.
How do you measure whether repatriation has succeeded?
Compare actual results with the agreed baseline and business case. Measure full operating costs, performance, availability, recovery capability and the dependencies the move was intended to address. Confirm that superseded resources and temporary arrangements have been removed, then review whether the environment continues to meet future requirements.
Does cloud repatriation guarantee data sovereignty?
No. Moving a workload changes its hosting location, but control also depends on provider jurisdictions, administrative access, support arrangements, encryption keys and external services. Assess these against the workload’s specific requirements. Public cloud and privately hosted options should both be evaluated on the controls they actually provide.
What DevOps and platform engineering skills are needed for cloud repatriation?
The operating team needs the skills to build and maintain infrastructure as code, deployment pipelines, monitoring, patching, capacity planning, security operations and hardware lifecycle management. Assess which capabilities cloud-managed services currently supply and what must be established in the destination.
A Build. Operate. Transfer. (BOT) model can help develop this capability. A delivery partner builds the platform and automation, operates it while practices are established, then transfers responsibility through documentation, hands-on training and shared operation. Agree acceptance criteria so the receiving team can demonstrate it can deploy, secure, maintain and support the environment before taking ownership.
