How to write a cloud exit plan (with a checklist)

To write a cloud exit plan, you need to document six things: what triggers an exit, a complete inventory of your cloud services and dependencies, a target provider mapping, a technical runbook for moving state and traffic, a timeline with named owners, and a way to test the plan at least once a year. A useful exit strategy is not a legal binder written to sit on a shelf. It is an operational runbook that explains how your company can move its infrastructure, data, and deployments from a current cloud provider (such as AWS, Google Cloud, or Azure) to an alternative provider within a known timeframe and cost budget, while keeping data intact and service interruptions predictable.

Key takeaways

Regulators and enterprise customers increasingly expect written exit plans. Under DORA (Regulation (EU) 2022/2554), financial entities and many of their technology suppliers must maintain tested exit strategies for critical ICT services.
The EU Data Act changes the economics of switching. Under Article 29 of Regulation (EU) 2023/2854, cloud switching charges—including data egress fees for switching—are capped at the provider’s direct cost until 12 January 2027, and banned entirely from 12 January 2027.
Data gravity and proprietary services are the main bottlenecks. Virtual machines and standard PostgreSQL databases move easily; proprietary NoSQL databases, identity rules, and undocumented network configurations take the longest to untangle.
An untested plan is only a guess. You do not need to migrate your entire production environment every year to validate your plan, but you do need to test restoring data and deploying your application to a secondary environment.

Why European companies need a real cloud exit plan

For years, cloud exit plans were treated as theoretical exercises. Only heavily regulated banks wrote them, and engineers rarely read them. Today, three practical pressures make a real exit plan necessary for 10-to-300-person European companies.

The first is regulatory compliance. The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied since 17 January 2025. Under Article 28(8), financial entities must establish exit strategies for ICT services that support critical or important functions. Even if your company is not a licensed financial institution, selling software to European banks, insurers, or fintechs means their procurement teams will ask for your cloud exit documentation during vendor due diligence. Similarly, organizations subject to the NIS2 Directive (Directive (EU) 2022/2555) face stricter supply chain and business continuity expectations.

The second is commercial leverage and cost control. Cloud pricing structures change, startup credit programs expire, and US-dollar billing introduces currency risk for Euro-denominated budgets. Having a documented, realistic path off your current hyperscaler turns contract renewals into genuine negotiations. Furthermore, the EU Data Act (Regulation (EU) 2023/2854), which became applicable in September 2025, mandates contractual and technical rules that make switching cloud providers easier. Specifically, Article 29 limits switching charges (such as data egress fees incurred when moving to another provider) to no more than the provider’s actual cost until 12 January 2027, and bans those charges completely starting 12 January 2027.

The third is sovereignty and jurisdictional risk. Many European boards and customers want to reduce reliance on non-EU cloud providers subject to US extraterritorial laws. Note that while offerings like the AWS European Sovereign Cloud keep data and operations inside the European Union, the provider remains Amazon, a US company. If your board or a major public-sector customer requires moving to an EU-owned cloud provider (such as UpCloud, Scaleway, Hetzner, OVHcloud, STACKIT, IONOS, or Exoscale), an existing exit plan saves weeks of initial discovery.

The six components of a practical cloud exit plan

A readable cloud exit plan should be five to ten pages long, plus links to living technical inventories (like your Infrastructure as Code repository). Structure your document around the following six sections.

1. Scope, triggers, and governance

Start by defining what the plan covers and when you would actually use it. Do not write a vague statement about “business continuity.” List specific, measurable trigger events. Common triggers include:

Commercial triggers: A price increase above a certain percentage, or the expiration of a committed-use discount where renewal terms are unacceptable.
Regulatory or customer triggers: A mandate from a regulator or a key customer requiring infrastructure to be hosted on an EU-owned cloud.
Operational triggers: Repeated multi-hour outages in your primary region, or termination of a specific cloud service your product relies on.
Legal triggers: Changes in data transfer laws, sanctions, or insolvency of a provider.

Assign two clear roles: an Executive Owner (usually the CEO, CFO, or COO) who has the authority to approve the budget and trigger the exit, and a Technical Lead (CTO, VP of Engineering, or Lead DevOps Engineer) responsible for keeping the technical inventory accurate and running the migration.

2. Asset and dependency inventory

You cannot move what you have not mapped. Most teams know where their main application servers and primary database live, but production cutovers fail because of forgotten background workers, hardcoded IP addresses, or managed security policies.

Create a complete inventory of your current cloud footprint. If you use Terraform, OpenTofu, or Pulumi, your state files are a strong starting point, though you should still check the cloud billing console for resources created manually in the UI (“ClickOps”). Group every resource into one of three portability tiers:

Standard and portable: Linux virtual machines, Docker containers, standard Kubernetes workloads, managed PostgreSQL or MySQL databases, Redis-compatible caches, and S3-compatible object storage.
Moderate coupling (requires refactoring or configuration translation): Cloud-specific load balancer annotations, managed message queues (like AWS SQS or Google Cloud Pub/Sub), serverless functions (AWS Lambda), and managed DNS (Route 53).
High lock-in (requires architectural redesign): Proprietary NoSQL databases (DynamoDB, Firestore, Cosmos DB), proprietary data warehouses (BigQuery, Redshift, Synapse), and deep integrations with cloud-native identity systems (IAM roles baked into application logic).

Component Category	Typical Hyperscaler Service	EU Cloud Equivalent (e.g., UpCloud, Scaleway, OVHcloud)	Exit Effort
Compute & Containers	EC2, EKS, GKE, AKS	Managed Kubernetes or standard Linux VMs	Low (if containerized)
Relational Databases	RDS, Aurora, Cloud SQL	Managed PostgreSQL / MySQL (or self-hosted on VMs)	Low to Medium (depends on data size)
Caching	ElastiCache, Memorystore	Managed Redis / Valkey	Low
Object Storage	Amazon S3, Cloud Storage	S3-compatible Object Storage	Low (requires checksum verification)
Queues & Serverless	SQS, Lambda, Cloud Functions	RabbitMQ / Kafka on VMs, or provider serverless offerings	Medium (requires code/config changes)
Proprietary Data	DynamoDB, BigQuery, Firestore	Open-source alternatives (ClickHouse, MongoDB, Postgres)	High (requires schema & app rewrite)

3. Target provider selection and mapping

An exit plan must name a specific alternative provider, or at least a primary and secondary candidate. Writing “we will move to another cloud” hides technical incompatibilities.

When choosing an EU-owned cloud target, match the provider’s product catalog to your team’s operational skills:

If your team relies on managed databases, managed Kubernetes, and S3-compatible object storage out of the box, providers like UpCloud, Scaleway, OVHcloud, STACKIT, IONOS, and Exoscale offer managed equivalents for core primitives.
If your team prefers raw price-performance and is comfortable managing software on bare metal or standard virtual machines, Hetzner is a popular choice. However, your exit plan must note that Hetzner does not offer managed databases or managed Kubernetes, meaning your team (or your migration tooling) will need to configure and maintain PostgreSQL, MySQL, and Kubernetes on virtual servers directly.

Document the exact instance sizes, storage classes, and network topologies you will use on the target provider, along with an estimated monthly run-rate cost based on public list prices.

4. Data migration and synchronization strategy

Code is stateless and easy to redeploy; data has gravity. Your exit plan must explain how you will move gigabytes or terabytes of state without corrupting records or taking your business offline for days.

Break your data strategy down by storage type:

Relational databases (PostgreSQL, MySQL): Taking a static pg_dump or snapshot and restoring it on the new cloud works only if your database is small and your business can afford several hours of downtime. For most production systems, specify logical replication. You set up the target database on the new cloud, copy the initial snapshot, and stream ongoing writes in real time until the new database is less than a few seconds behind the source.
Object storage (S3, GCS): Specify a tool (such as rclone) that copies buckets using standard S3 APIs. Because object buckets often hold millions of user files or invoices, your plan must require checksum verification on all transferred files and continuous delta syncs leading up to the cutover date.
Encryption keys and secrets: Document how TLS certificates, database credentials, and encryption keys stored in services like AWS KMS or Secrets Manager will be exported and injected into the target environment.

5. Cutover, rollback, and cleanup runbook

The cutover section is the step-by-step sequence your engineering team will follow on migration day. Keep it chronological and explicit:

Pre-cutover preparation (24–48 hours prior): Lower DNS Time-To-Live (TTL) values to 60 or 300 seconds so DNS changes propagate quickly across the internet. Verify that database logical replication lag is consistently near zero and object storage delta syncs are complete.
Deployment pipeline alignment: Update your CI/CD pipelines (GitHub Actions, GitLab CI, etc.) so your team can deploy the exact same application build to both the old and new environments.
The switch window: Put the application into maintenance mode or pause database writes on the old cloud. Wait until replication lag reaches zero (typically under 5 seconds). Run automated health and data integrity checks on the target database.
DNS cutover: Point your DNS records (or external load balancer) to the new EU cloud environment and enable writes.
Rollback window (Day 1 to Day 30): Never delete the old cloud environment immediately after switching DNS. A robust exit plan keeps the old environment alive and sets up reverse replication—streaming new writes from the new EU cloud back to the old cloud for 14 to 30 days. If an unexpected network or performance issue appears in the new environment, you can switch DNS back without losing data written after the migration.
Decommissioning: Once the rollback period passes without critical issues, stop reverse replication, take a final archival backup, delete data on the old cloud according to GDPR and contractual rules, and close the account.

6. Testing, maintenance, and cost estimation

Under DORA and standard ISO 27001 business continuity rules, an exit plan must be reviewed and tested regularly. Include a schedule in your document:

Every 6 months: Update the resource inventory, verify that new cloud services introduced by product teams are logged in the portability table, and check target cloud pricing.
Every 12 months: Run a tabletop exercise with engineering and ops leads, or perform a technical dry run where you spin up the target infrastructure from your Terraform code, restore a database backup, and deploy the staging application.

Finally, include a realistic budget estimate for executing the exit. Break costs into three buckets:

Parallel run costs: Paying for both the old cloud and the new target cloud simultaneously during the testing, replication, and 30-day rollback window (typically 1 to 2 months of duplicate infrastructure spend).
Switching and egress fees: Note that under EU Data Act Article 29, providers may only charge at-cost fees for data egress related to switching until 12 January 2027, and €0 after that date. However, you should check your current provider’s specific waiver request process, as hyperscalers often require you to open a support ticket before migrating to qualify for reduced or waived egress fees.
Engineering time or external tooling: Estimate the internal staff hours required to rewrite cloud-specific configurations, or the fixed cost of using an automated migration service.

Cloud exit plan checklist

Use this checklist to audit your draft plan before submitting it to your board, auditor, or enterprise customer.

Frequently asked questions

Does DORA require a cloud exit plan for SaaS companies that are not banks?

DORA applies directly to regulated financial entities in the EU, but those entities are legally required to manage third-party ICT risk across their supply chain. If you provide critical software or infrastructure to banks, insurers, or investment firms, their compliance teams will usually require you to demonstrate a documented business continuity and cloud exit strategy as part of your contract.

Can we still be charged egress fees when leaving AWS, Google Cloud, or Azure?

Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers cannot charge switching fees—including data egress fees for moving to another provider—that exceed their direct technical cost of facilitating the switch. Starting 12 January 2027, all switching and egress charges for changing providers are completely banned in the EU. Keep in mind that you usually must notify your current provider in advance and follow their documented switching procedure rather than simply downloading data without notice.

How long should a realistic cloud exit take for a 50-person company?

If your infrastructure relies on standard workloads—such as Linux VMs, Kubernetes, PostgreSQL/MySQL, and S3-compatible object storage—executing a well-prepared exit plan typically takes two to four weeks of setup and synchronization, followed by a short planned cutover window and a 30-day rollback period. If your application is tightly coupled to proprietary services like DynamoDB or hundreds of serverless functions, refactoring the application code can add two to six months to the timeline.

Should we build a multi-cloud active-active architecture to make exiting easier?

For most 10-to-300-person companies, running an active-active architecture across two cloud providers simultaneously is too expensive and operationally complex. It doubles your networking and monitoring overhead and introduces cross-cloud latency. A much more practical approach is portable single-cloud: run on one provider at a time, use standard open-source databases and containers, keep your infrastructure in Terraform, and maintain a tested exit plan so you can move when necessary.

How MoveInfra can help

Writing an exit plan is much easier when you have an exact inventory of your current cloud footprint and a concrete cost and architecture mapping for an EU alternative. MoveInfra analyzes your AWS, Google Cloud, Azure, or DigitalOcean setup from a billing export or read-only access to produce a complete resource inventory, a fixed migration price, and your projected monthly cost on EU-owned clouds like UpCloud, Scaleway, Hetzner, or OVHcloud. When you are ready to test or execute your exit, we rebuild your infrastructure as Terraform code, sync your databases and object storage, and manage the cutover with a 30-day reverse-replication rollback window.