Key Takeaways
- Cloud exit strategies document data extraction, application migration and operational continuity; in the EU, DORA requires them for ICT services supporting critical or important functions, and the UK PRA and the ECB set further supervisory expectations
- Technical barriers include proprietary API dependencies, data format incompatibilities, and performance optimization ties that require architectural changes during migration
- Risk reduction strategies include multi-cloud architectures, open-source technology adoption, container deployment, and API abstraction layers to minimize provider dependency
A cloud exit strategy is a documented plan for migrating data, applications, and workloads out of a cloud provider's environment while maintaining operational continuity. It covers data extraction, application portability, contract termination procedures, and reverse migration sequencing. Financial institutions need exit strategies to meet supervisory rules and expectations, limit vendor lock-in risk, and keep services running if a provider relationship ends.
What constitutes a comprehensive cloud exit strategy?
A complete exit strategy covers five core components. Data portability requirements specify extraction formats, transfer protocols, and timeline guarantees. Application migration procedures document dependencies, configuration requirements, and testing protocols for moving workloads to alternative environments.
Contract exit provisions define termination notice periods, data deletion timelines, and assistance obligations. Operational continuity plans ensure service availability during migration, including fallback procedures and rollback options.
Risk assessment frameworks identify potential exit barriers, cost implications, and regulatory compliance requirements. Supervisors expect that assessment early: the PRA's SS2/21 asks firms to begin exit plans in the pre-outsourcing phase once they judge an arrangement material, and the ECB's cloud guide expects exit strategies to be in place before systems supporting critical or important functions go live.
How do financial institutions implement data portability requirements?
Data portability implementation begins with comprehensive data mapping. Institutions catalog data locations, formats, dependencies, and regulatory classifications across cloud environments. This mapping identifies personal data that may fall under the GDPR's portability right and trading data required for MiFID II compliance.
Technical specifications define extraction formats and transfer mechanisms. Formats might include JSON for configuration data, Parquet for analytical datasets, and SQL dumps for relational databases. Transfer protocols specify bandwidth requirements, encryption standards, and integrity verification procedures.
Testing procedures validate extraction and import processes periodically, which shows whether data can actually leave and identifies process gaps.
What are the main technical barriers to cloud exit?
Proprietary API dependencies are one of the main technical barriers (interpretation). Cloud providers offer native services like AWS Lambda, Azure Cosmos DB, or Google BigQuery that lack direct equivalents in other environments. Applications using these services require architectural changes for migration.
Data format incompatibilities complicate migration between different database systems. Moving from Amazon DynamoDB's NoSQL structure to Oracle's relational format requires data transformation and application logic updates.
Integration complexity increases with multi-cloud deployments. Financial institutions using Salesforce Financial Services Cloud alongside AWS infrastructure face additional integration challenges when exiting either platform.
Performance optimization dependencies tie applications to specific cloud architectures. Trading systems optimized for AWS's placement groups or Azure's proximity placement groups may require performance re-engineering in alternative environments.
How do regulatory requirements affect cloud exit planning?
The PRA's supervisory statement SS2/21, Outsourcing and third party risk management, covers UK banks, building societies and PRA-designated investment firms, Solvency II insurers, and UK branches of overseas banks and insurers. It sets out expectations: "For each material outsourcing arrangement, the PRA expects firms to develop, maintain, and test a" business continuity plan and a documented exit strategy that distinguishes a stressed exit, such as the provider's failure or insolvency, from a planned, non-stressed exit. The version in force is dated November 2024; an update published in March 2026, which keeps this paragraph, takes effect on 18 March 2027.
The European Central Bank's Guide on outsourcing cloud services to cloud service providers (July 2025) sets out the ECB's expectations on DORA's requirements for the banks it supervises, and says it "does not lay down legally binding requirements, practices, or rules". It expects exit strategies "with clearly defined roles and responsibilities and estimated costs" before cloud services supporting critical or important functions go live, and considers it good practice for each exit plan to include "the critical milestones, a description of the tasks and skillsets that are required to perform the exit, and a rough estimate of the time required, and the costs involved".
The binding EU rule on exit is DORA's; the PRA's statement and the ECB's guide set supervisory expectations alongside it.
GDPR Article 20 gives individuals the right to receive personal data they provided to a controller "in a structured, commonly used and machine-readable format" and to transmit it to another controller, where the processing is based on consent or a contract and is carried out by automated means. The right belongs to the customer and applies wherever the data is held, including in a cloud; it is a separate obligation from the institution's own exit (interpretation).
The Digital Operational Resilience Act (Regulation (EU) 2022/2554, applicable from 17 January 2025) is the binding EU rule. Article 28(8) states: "For ICT services supporting critical or important functions, financial entities shall put in place exit strategies." Exit plans must be comprehensive and documented and "shall be sufficiently tested and reviewed periodically", and firms must develop transition plans to move the services and data to alternative providers or back in-house. For those services, DORA requires financial entities to be able to exit the contract without disrupting their business, limiting their regulatory compliance or harming the continuity and quality of services to clients. Article 29 separately requires firms to consider ICT concentration risk, including whether a provider is "not easily substitutable", before contracting for ICT services that support critical or important functions.
What costs should institutions factor into exit planning?
Data egress charges are a direct cost of exit. In the EU, the Data Act (Regulation (EU) 2023/2854) limits what providers of cloud and other data processing services may charge for switching, a term it defines as "including data egress charges". From 11 January 2024 to 12 January 2027, reduced switching charges "shall not exceed the costs incurred by the provider of data processing services that are directly linked to the switching process concerned", and Article 29 then states: "From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process." Article 31 exempts services mostly custom-built for one customer and not offered at broad commercial scale, and time-limited test versions, and under Article 34 a provider of a service used in parallel with another may still pass on egress costs without exceeding them. Where the Data Act does not apply, egress remains a cost that grows with the volume of data moved (interpretation).
Application re-architecture costs vary by cloud service dependency.
Dual-running costs occur during migration periods.
Legal and consulting fees include contract renegotiation, compliance validation, and technical advisory services.
How can institutions reduce vendor lock-in risks?
Multi-cloud architecture strategies distribute workloads across providers to reduce single-vendor dependency. Institutions can implement consistent deployment patterns using tools like Terraform or Kubernetes that function across AWS, Azure, and Google Cloud.
Open-source technology adoption minimizes proprietary service dependencies. Running open-source PostgreSQL rather than a provider-specific database, or Apache Kafka rather than Amazon Kinesis, enables easier migration between cloud providers.
Container-based deployment strategies package applications with dependencies, enabling movement between environments. The ECB's cloud guide gives "virtual machine and container-based applications" as examples of portable infrastructure technologies.
API abstraction layers isolate applications from cloud-specific services. Institutions can build internal APIs that translate between cloud provider services, enabling backend changes without application modifications.
What documentation and testing requirements exist?
Exit documentation should include detailed runbooks with step-by-step procedures, technical specifications, and responsible parties (interpretation). Once an outsourcing arrangement is in place, the PRA expects firms to "test their business continuity and exit plans on a risk-based approach".
None of these sources sets a testing frequency. DORA ties testing to proportionality, and the ECB guide says exit plans should be "reviewed and tested on a regular basis" and considers it good practice, at a minimum, to "perform an in-depth desktop review". Setting the frequency by the criticality of the function is our recommendation (interpretation). Each test should validate data extraction, application deployment, and operational readiness in target environments.
Change management procedures ensure exit strategies remain current as cloud deployments evolve.
For institutions seeking comprehensive cloud exit planning resources, detailed assessment frameworks and regulatory compliance checklists provide structured approaches to developing exit strategies.
For a structured framework to support this work, explore the Infrastructure and Technology Platforms Capabilities Map — used by financial services teams for assessment and transformation planning.
Frequently Asked Questions
What is the difference between a cloud exit strategy and disaster recovery?
A cloud exit strategy plans for leaving a provider for good, with data and applications moved to another provider or back in-house, whether in a planned exit or a stressed one such as the provider's failure (the distinction the PRA's SS2/21 draws). Disaster recovery focuses on temporary failover to maintain operations during outages, after which service resumes with the same provider.
Can institutions negotiate better exit terms in cloud contracts?
Yes, large financial institutions can negotiate enhanced exit provisions including extended data retention periods, migration assistance, and detailed handover procedures, and data egress allowances where the law does not already limit egress charges. In the EU, the Data Act bans switching charges, data egress included, from 12 January 2027 for the services it covers, and until then limits them to the provider's costs. Contracts can specify minimum notice periods, data format requirements, and provider cooperation obligations during exit processes.
What happens to data encryption keys during cloud exit?
Institutions should keep control of encryption keys so that data stays readable during and after an exit (interpretation). Keys held outside the provider's environment, for example in the institution's own hardware security modules, keep data decryptable after the provider relationship ends; data encrypted under a key held only in the provider's key service has to be decrypted or re-encrypted under a new key before the exit completes (interpretation). Provider-managed keys require coordination during exit to ensure data remains accessible throughout migration.
Do cloud exit strategies apply to SaaS applications?
Yes. DORA's exit-strategy rule covers ICT services that support critical or important functions, however they are delivered, so a SaaS platform in that category needs one. SaaS exits often involve API-based data extraction and recreating application workflows on alternative platforms, and the ECB's cloud guide notes that "portability aspects of PaaS and SaaS depend on the specific solutions".