Cloud repatriation: How to take back control

Cloud repatriation is defined as the migration of applications and associated data from cloud hyperscalers back to on-premise private clouds or data centres. Some organisations choose to repatriate someworkloads that they have already migrated to the cloud for several reasons; for example, regulatory changes, digital and data sovereignty, or the need to lower latency and have more control over performance. 

The cost benefit of migrating to cloud can be overestimated for pure lift and shift migrations. To realise the cost benefits the implementation often requires application modernisation to make use of cloud–native services. Although the ease of provisioning and scaling cloud resources is an obvious benefit, it can lead to high costs due to decentralised provisioning led by application teams, and lack of proper controls to limit sprawl. Moving all workloads to the cloud can sometimes increase spending if not properly controlled. 

The IDC Survey Cloud Trends in Europe survey 2023 showed a declining trend in complete public cloud migration, with 71% of respondents planning partial or full repatriation. The most common reasons for repatriating workloads are to reduce costs, improve performance and increase security. 

The solution for many – a hybrid model providing both cloud benefits and physical control 

For example Google Cloud’s Open Infrastructure Cloud can be used to implement the desired hybrid model. Google Cloud believes that openness and flexibility are essential for cloud computing. They want to give customers the choice to run their workloads where and how they want, and to retain control over their infrastructure and data. Google Cloud’s Open Infrastructure Cloud initiative commits Google to providing services that give their customers choice and flexibility. It provides customers with more control and security over their infrastructure and security, and offers greater openness and interoperability. 

Many financial services organisations have turned to using the likes of Google Cloud Open Infrastructure Cloud to run their mission-critical applications in a highly secure environment, retain control over their data and meet strict regulatory compliance requirements. 

Five steps to repatriating workloads 

1. Assessment: Assess the current cloud hosted workloads to identify those that need to be repatriated, based on factors such as: cost benefit, performance, security, integration and interdependencies, disaster recovery, operational resilience, and regulatory compliance. 
2. Planning: Once the workloads have been identified, a plan must be developed. This must include a timeline, budget, and resource planning. 
3. Migration: First migrate any non-production environments that are representative of the production environment hosted in the cloud. For example, migrate staging and / or performance to the on-premise environment and test sufficiently to determine that the predicted repatriation benefits are realised. Once satisfied that all functional and non-functional requirements have been met, proceed to migrating the production workloads. 
4. Testing: Once the workloads have been migrated, test and test again to verify that they are functioning properly. Include operational resilience, monitoring & logging platforms, DevOps tooling, disaster recovery and business continuity plans. 
5. Support: Once the workloads have been repatriated to the on-premise environment the workloads need to be supported. This will include monitoring, troubleshooting, and maintenance. Ensure that support staff have the tools and training to support the repatriated workloads.