Cloud Exit Strategy — Avoiding Vendor Lock-in 2026

Vendor lock-in was long considered an academic problem — until 2024, when several large European companies migrated out of a single hyperscaler at costs running into the tens of millions, managing re-engineering projects that lasted six to nine months. Since January 2025, DORA has required financial services firms and insurers to maintain a documented and testable exit plan for every critical cloud provider. The EU Data Strategy and the Data Act deepen this obligation in 2026 for additional industries; KRITIS operators are also covered under NIS2. For management boards, CFOs, and IT leadership this is no longer an optional architecture topic but a regulatory necessity with direct personal liability. This article explains what an effective cloud exit strategy looks like, what lock-in tiers exist, how a realistic exit plan is structured, which architecture decisions make an exit possible in the first place, and what costs to expect. For the broader strategic picture, see our Cloud & DevOps Guide for the Mid-Market.

Why DORA and the EU Data Strategy Make Cloud Exit Mandatory in 2026

The regulatory landscape has changed dramatically over the past 18 months. Three levers are operating simultaneously and create an obligation for a large part of the German mid-market that barely existed a few years ago.

First, DORA — the Digital Operational Resilience Act has been directly applicable EU law since 17 January 2025 for banks, insurers, payment service providers, crypto-asset providers, and a large segment of the financial mid-market. Article 28 requires a written, tested exit plan for every critical ICT third-party service provider, including a transition architecture. Hyperscalers such as AWS, Azure, and Google Cloud are classified as critical third-party service providers as soon as they support core business functions. In 2025 Germany's BaFin conducted several supervisory conversations about missing exit plans — consequences range from formal requirements to special audits.

Second, the EU Data Strategy and the Data Act, which has been fully applicable since September 2025. Articles 23 to 31 of the Data Act govern provider switching for data processing services and explicitly require "functional equivalence" and "switchability" — changing a cloud provider must genuinely be possible within an agreed timeframe, data must be made available in a structured, commonly used, machine-readable format, and switching fees will be banned from 2027 onwards. For affected companies this means: no more architectures that make a switch practically impossible.

Third, KRITIS and NIS2. Operators of critical infrastructure — energy, water, healthcare, transport, finance, telecommunications — are required under the BSI Act and the NIS2 transposition to manage their dependencies on individual service providers and to demonstrate resilience concepts. A purely single-cloud architecture without an exit plan is no longer acceptable for KRITIS audits.

Operationally, a second wave adds further pressure — not regulatory, but economically decisive: cyber-insurers now explicitly ask about reversibility, supplier audits by major industrial customers include standard questions on exit plans, and investors treat cloud lock-in as a risk factor in due-diligence processes. A company without an exit strategy pays higher premiums, loses contracts, or receives lower valuations.

Understanding the Four Lock-in Tiers

"Vendor lock-in" is not a binary state but is distributed across four distinct dimensions. Anyone planning an exit without separating these tiers is planning around the wrong problem.

Tier	What it means	Typical symptoms
Workload lock-in	Applications use proprietary services of the provider — Lambda, Step Functions, EventBridge, Azure Functions, Cloud Run-specific triggers	Code cannot be run on another platform without re-engineering
Data lock-in	Data resides in proprietary formats or databases — DynamoDB, Cosmos DB, BigQuery, Aurora-specific features, S3 Glacier structures	Migration requires export–transform–reimport and schema adjustments; egress costs are substantial
Skill lock-in	The team only knows one provider's tools; all automation is written in vendor-specific CLIs and SDKs	Migration fails due to re-skilling effort and the cost of porting an established tooling landscape
Contract lock-in	Multi-year reserved-instance bookings, enterprise discount programmes, marketplace contracts tied to a single provider	Termination results in residual-value loss and contractual penalties; switching is economically unattractive

An effective exit strategy addresses all four tiers. From our consulting practice, workload lock-in is the most common bottleneck — many mid-market companies have made intensive use of proprietary managed services in recent years because they were more productive in the short term. Data lock-in is the most expensive bottleneck, because egress costs and schema transformations quickly reach six-figure sums. Skill lock-in is the underestimated bottleneck — even if the architecture is portable, an exit fails if nobody on the team can operate the alternative platform. Contract lock-in is the easiest bottleneck — it can be avoided by keeping contract terms short and consciously limiting reserved-instance bookings.

Which Services Are Particularly High-Lock-in

Not all cloud services are equally problematic. From an exit perspective, hyperscaler offerings broadly fall into three classes.

Highly lock-in-prone — deliberate avoidance recommended. These services bind so deeply to the provider that switching means months of re-engineering.

• Managed AI and ML — SageMaker, Azure ML, Vertex AI, Bedrock with provider-specific models
• Proprietary databases — DynamoDB, Cosmos DB, BigQuery, Aurora-specific features, Spanner
• Vendor auth — Cognito, Azure AD B2C, Firebase Auth — hard to replace because they seep deep into application logic
• Serverless with provider-specific triggers — Lambda with EventBridge patterns, Logic Apps, Cloud Run with specific Pub/Sub bindings
• Proprietary data analytics stacks — Redshift, Synapse, BigQuery — migration effort is substantial

Moderately lock-in-prone — acceptable with a reversibility wrapper. These services can be replaced with manageable effort if the abstraction is kept clean.

• Managed Postgres and Managed MySQL — RDS, Azure Database, Cloud SQL — switching to an open self-managed variant is feasible
• Managed Kubernetes — EKS, AKS, GKE — the cluster itself is portable; add-ons (IAM, load balancers) must each be rewired
• Object storage — S3, Blob Storage, Cloud Storage — largely compatible via the S3 API; migratable with tools like rclone
• Managed message queues with open protocols — Managed Kafka, RabbitMQ

Low lock-in risk — use without concern. These services are essentially standardised building blocks.

• VMs and container hosting with OCI standard — EC2, Azure VMs, Compute Engine
• Standard Kubernetes without vendor-specific operators
• Standard network building blocks — VPCs, subnets, load balancers in standard Layer 4/7 configuration

Building Blocks of a Robust Exit Plan

An exit plan is not a Word document that gets signed off by an auditor once a year, but a living, multi-part construct comprising an inventory, mapping, architecture decisions, and test restores. The following five building blocks belong in every DORA-compliant plan.

• Workload inventory with criticality classificationA complete list of all cloud workloads, classified by business criticality, data protection class, and lock-in depth. Without this inventory, no exit can be planned — and it is regularly the biggest gap in DORA audits. Each workload receives an RTO and RPO target and a destination provider in the event of exit.
• Data repatriation planA documented export path for every data asset — format, tool, estimated duration, egress costs. Particularly important: backup data in proprietary formats (S3 Glacier, Azure Archive) requires pre-defined restore paths, otherwise it is lost in an exit scenario or dramatically increases its cost.
• Service substitution mappingA table naming an open or cross-provider alternative for every proprietary service in use — Lambda to OpenFaaS or Knative, DynamoDB to Postgres with JSONB, Cognito to Keycloak, Aurora to PostgreSQL with Patroni. The mapping is the basis for effort estimates.
• Architecture reversibility principlesWritten architecture rules that limit lock-in — OCI containers instead of vendor-specific serverless, Postgres instead of proprietary databases, Kubernetes instead of ECS or Fargate, OIDC standard instead of vendor auth. These principles belong in the Architecture Decision Record of every new application.
• Tested restore to a second cloudAt least once a year, a critical workload is actually restored in a second cloud environment — either at a second hyperscaler or at a German provider such as OVHcloud, IONOS, or Stackit. Without this test the plan is neither DORA-compliant nor robust.

Data Migration Paths

The data layer is by far the most expensive and slowest part of an exit. Three migration patterns have proven themselves in practice.

Online migration with Change Data Capture. Suitable for databases with high availability requirements. Tools such as Debezium or pgAudit replicate changes in real time to the target database, which becomes consistent after a multi-day sync run. The cut-over moment is a brief read lock. Advantage: minimal downtime. Disadvantage: complex preparation, double licensing costs during migration.

Snapshot restore with controlled cut-over. Suitable for databases with a plannable maintenance window. Export a snapshot, restore in the target environment, cut over with a DNS switch or load-balancer change. Advantage: simple, easy to test. Disadvantage: longer downtime, typically 2 to 12 hours.

Bulk export with format transformation. Necessary for proprietary databases such as DynamoDB, Cosmos DB, or BigQuery. Export to CSV or Parquet, transform the schema to a relational or document-based target structure, bulk import. Advantage: the only option for deep lock-in. Disadvantage: complex, error-prone, significant downtime.

Egress costs are a central line item. Hyperscalers historically charge between 0.02 and 0.09 euros per gigabyte of outbound traffic — for a 50-terabyte dataset that is 1,000 to 4,500 euros per full export. The Data Act will ease this from 2027, but the costs are still real today and must be included in every business case.

Architecture Decisions That Guarantee Reversibility

The most important insight from completed exits: reversibility is not created at the time of exit, but at the time of build. Architecture decisions made consciously today determine whether an exit in three years costs 200,000 or 2 million euros.

Area	Lock-in variant	Portable alternative
Compute	Lambda, Azure Functions, Cloud Run with vendor-specific triggers	OCI containers on Kubernetes or Knative, with standardised event sources
Database	Aurora-specific features, DynamoDB, Cosmos DB, BigQuery	PostgreSQL with standard extensions, Postgres with JSONB instead of NoSQL, ClickHouse for analytics
Container orchestration	ECS, Fargate, Azure Container Apps	Standard Kubernetes (EKS, AKS, GKE, or self-managed) with identical manifests
Identity	Cognito, Azure AD B2C, Firebase Auth	Keycloak or Authentik, OIDC standard, portable between clouds
Messaging	EventBridge, Azure Service Bus with proprietary filters	Apache Kafka, NATS, RabbitMQ
Infrastructure as Code	CloudFormation, ARM Templates, Deployment Manager	Terraform or OpenTofu with cross-provider modules

Portable architecture typically costs 5 to 15 percent more to operate than an architecture fully tailored to a single provider — self-managed database operations, self-managed authentication, your own Kafka cluster instead of managed eventing. These additional costs are the insurance premium for reversibility. For more detail on IaC decisions see our cluster on Terraform IaC Best Practices, for the fundamental provider choice our comparison of AWS vs. Azure vs. GCP, and for the multi-cloud discussion Multi-Cloud vs. Single-Cloud.

Contract Clauses That Should Be in Every Cloud Contract

The legal side of an exit is underestimated in many mid-market contracts — standard terms and conditions from hyperscalers are not DORA-compliant and do not contain adequate exit guarantees. At least five clauses belong in every negotiating mandate.

• Data repatriation in an open format. A contractually guaranteed right to export all customer data in a structured, commonly used, machine-readable format — at no extra cost, with adequate bandwidth, within a defined timeframe.
• Guaranteed exit period. At least six months' transition phase from termination during which data and services remain available — DORA requires 12 months for critical services.
• Data deletion with proof. Complete, documented deletion of all data after exit completion with written confirmation — relevant for GDPR and for supplier audits.
• Service discontinuation notice. An obligation to provide advance notice of service discontinuation or major price increases with sufficient lead time — typically 12 to 24 months for critical services.
• Audit and sub-contractor transparency. Access to audit reports (SOC 2, ISO 27001), disclosure of all sub-contractors and their locations, obligation to notify on sub-contractor changes — DORA requires this explicitly.

Testing the Exit — Otherwise It Doesn't Exist

The biggest difference between a Word-document exit plan and a robust exit plan is the test. DORA explicitly requires that exit plans be regularly "tested, reviewed, and updated" — and the BaFin takes this seriously. In practice this means at least one annual exit test at one of these three depths.

Tier 1: Tabletop exercise. Management and IT leadership walk through the exit plan in a multi-hour workshop — who does what, when, with which tools. Effort: 1 to 2 person-days. Benefit: reveals gaps in the plan, validates responsibilities. Sufficient for low criticality.

Tier 2: Partial restore of a workload. A non-critical workload is actually restored in the second cloud — end-to-end, with data and application layer. Effort: 5 to 15 person-days. Benefit: validates data paths and architecture assumptions. Standard for DORA-compliant programmes.

Tier 3: Full failover exercise with load. A critical workload is fully operated in the second cloud, including production load and cut-over. Effort: 20 to 60 person-days. Benefit: validates the real exit path including performance and costs. Recommended every two to three years for KRITIS- and DORA-regulated entities.

What Does a Real Cloud Exit Cost?

The cost of a full cloud exit depends heavily on lock-in depth, data volume, and time pressure. The table below shows typical ranges for mid-market companies — intended as guidance; precise estimates require an inventory workshop.

Exit scenario	Total one-time cost	Duration	External person-days
Container and Postgres stack without proprietary services (50–200 employees)	120,000–280,000 €	6–9 months	60–140
Standard mix with moderate managed-service usage (200–500 employees)	280,000–620,000 €	9–15 months	140–320
Deep lock-in with serverless and proprietary DBs (500–1,500 employees)	620,000–1,400,000 €	15–24 months	320–700
Pure reversibility preparation without an actual exit	40,000–120,000 €	3–6 months	20–60

The main cost items are re-engineering proprietary services, parallel operations during migration, data egress charges, external consulting, and internal personnel. The ongoing additional cost of a portable architecture compared to one fully tailored to a single provider is around 5 to 15 percent of operating costs. That is the insurance premium for reversibility — and compared to the one-time cost of an unplanned exit under pressure, it is always the cheaper option.

Reepa Cloud Exit Audit

We offer a structured cloud exit audit that evaluates the DORA and Data Act compliance of your current cloud architecture in three to six weeks. The audit covers a complete workload inventory with lock-in classification, a service substitution mapping, an assessment of existing contracts against the five key clauses, a written exit plan in a DORA-compliant structure, and a one-page management report with risk assessment and effort estimate. Optionally, we conduct the first Tier 2 test in a second cloud.

Frequently Asked Questions