Vendor Lock-in and Exit Strategy
Last reviewed: August 2026
Why an Exit Strategy Matters
Section titled “Why an Exit Strategy Matters”The more deeply you integrate with a single vendor, the more your pricing leverage shrinks, and the more vulnerable you become to the vendor’s policy changes (price hikes, service discontinuation, regional withdrawal). Some jurisdictions, such as the EU’s DORA, mandate documented Exit Plans for the financial sector. In November 2025, the ESAs (EBA, EIOPA, ESMA) published the first list of designated CTPPs (Critical ICT Third-Party Providers) under DORA, requiring financial entities using designated CTPPs to demonstrate stricter exit readiness. Country-specific obligations are in the Korea, United States, EU, Japan, and Singapore guides.
An important misconception:
AWS Prescriptive Guidance states the same position — “Avoiding lock-in depends more on an organization’s people and processes than on technical decisions.”
Four Dimensions of Lock-in
Section titled “Four Dimensions of Lock-in”| Dimension | Description | Examples |
|---|---|---|
| Data lock-in | Data formats, storage, egress costs | S3-only formats, Cosmos DB-exclusive API, egress cost of petabyte-scale data |
| API lock-in | Code built around a specific vendor SDK/API | Lambda event objects, Azure Durable Functions state management |
| Architecture lock-in | Designs based on vendor-specific services | Step Functions workflows, Cosmos DB-exclusive features |
| Operational lock-in | Team skills and toolchain concentrated on one vendor | Teams that only use CloudFormation, Azure DevOps pipelines |
| AI/ML lock-in | Vendor dependency through fine-tuned models, embeddings, and vector DBs | Non-exportable vendor-specific fine-tuned models, vector indices tied to a specific embedding model, platform-dependent prompt/RAG pipelines |
Lock-in Levels and Trade-offs
Section titled “Lock-in Levels and Trade-offs”The degree of lock-in varies by service. Generally, the lower the layer (IaaS), the lower the lock-in; the higher the layer (managed services), the higher the lock-in.
| Level | Lock-in | Portability | Management Burden | Representative Examples |
|---|---|---|---|---|
| IaaS (VM) | Low | High | High | EC2, Azure VM, Compute Engine |
| Containers (Kubernetes) | Very low | Very high | Medium | EKS/AKS/GKE/OKE |
| Open-source managed | Medium | Medium | Low | Managed PostgreSQL/Valkey/Kafka |
| Cloud-native PaaS | High | Low | Very low | Aurora, Cosmos DB, BigQuery |
| Serverless (FaaS) | Very high | Very low | Very low | Lambda, Azure Functions, Cloud Run |
The choice is a trade-off between “reduced management burden vs. secured portability.” Most organizations don’t concentrate on a single point but mix multiple points depending on workload characteristics.
Design Principles for Portability
Section titled “Design Principles for Portability”1. Prefer Standard Open Source
Section titled “1. Prefer Standard Open Source”Where possible, choose industry-standard open-source interfaces.
| Category | Portable Choice | Less Portable Choice |
|---|---|---|
| Container orchestration | Kubernetes (EKS/AKS/GKE/OKE) | ECS, Service Fabric |
| Relational database | PostgreSQL/MySQL compatible (Aurora PostgreSQL, Cloud SQL) | Cosmos DB proprietary API, DynamoDB |
| Cache | Valkey/Redis compatible (ElastiCache, Cache for Redis) | Vendor-proprietary cache |
| Message queue | Kafka compatible (MSK, Event Hubs for Kafka) | SQS, Service Bus |
| Container images | OCI standard images (ECR, ACR, Artifact Registry) | Vendor-specific deployment formats |
| Authentication | OIDC/SAML | Vendor-specific SDK authentication |
2. Define Infrastructure as IaC
Section titled “2. Define Infrastructure as IaC”IaC is the foundation of portability. Terraform can manage multi-cloud definitions with a single tool, giving it the highest portability.
| Tool | Multi-cloud Support | Portability |
|---|---|---|
| Terraform / OpenTofu | Major vendors + 3rd party | Very high |
| Pulumi | Major vendors | High |
| Crossplane | Kubernetes-based abstraction | High |
| AWS CloudFormation | AWS only | Low |
| Azure Bicep / ARM | Azure only | Low |
| Google Cloud Deployment Manager | Google Cloud only | Low |
| OCI Resource Manager | OCI only (Terraform-based) | Medium |
3. Abstraction Layer
Section titled “3. Abstraction Layer”Isolate vendor-specific code so it doesn’t spread into the application’s business logic.
graph LR
A[Business Logic] --> B[Abstraction Interface]
B --> C1[AWS Implementation]
B --> C2[Azure Implementation]
B --> C3[Google Cloud Implementation]
Representative abstraction libraries/frameworks:
- Storage: Go Cloud Development Kit, Apache Libcloud
- Messaging: CloudEvents (CNCF)
- AI: LangChain, LlamaIndex (LLM abstraction)
- Kubernetes: Knative Serving, Dapr
4. Data Portability
Section titled “4. Data Portability”- Standard formats — Parquet, Avro, JSON, CSV
- Store regular backups in a neutral location — a different region/vendor/on-premises
- Be aware of egress costs — egress fees for petabyte-scale data can run into tens of thousands to hundreds of thousands of USD. Note: Google Cloud waived egress fees for switching providers starting January 2024, and in September 2025 launched Data Transfer Essentials for EU/UK, waiving multicloud egress fees in compliance with the EU Data Act
- Use offline transfer options — see Storage Migration
Exit Execution Plan
Section titled “Exit Execution Plan”Common components of an Exit Plan required in the financial sector/regulated industries:
1. Asset Inventory
Section titled “1. Asset Inventory”- List of workloads, data, and dependent services
- Lock-in level per item (high/medium/low)
- Migration priority and difficulty
2. Trigger Scenarios
Section titled “2. Trigger Scenarios”Situations that would trigger an Exit:
- Unilateral price increases by the vendor (exceeding contractual caps)
- Announcement of discontinuation of a core service
- Regulatory changes restricting vendor use
- Vendor security incident/loss of trust
- Strategic changes due to M&A
3. Migration Procedure
Section titled “3. Migration Procedure”- Prepare the target environment (another vendor or on-premises)
- Data migration sequence (migration waves, see Application Migration)
- Dual-run period (running both environments in parallel)
- Legacy shutdown criteria
4. Cost Estimation
Section titled “4. Cost Estimation”- Data egress
- Migration tools/personnel
- Operational downtime costs
- Building the new environment
5. Periodic Validation
Section titled “5. Periodic Validation”- Annual Exit Plan review
- Impact analysis on major architecture changes
- PoC with competing vendors to confirm actual migration feasibility
Common Mistakes
Section titled “Common Mistakes”- Giving up all managed services to eliminate lock-in — running everything directly on Kubernetes for the sake of portability, which actually increases operational burden and cost
- Documenting the Exit Plan without validating it — never running an annual competing-vendor PoC or real migration test, so the plan drifts from reality
- Not estimating egress costs in advance — overlooking that egress costs for petabyte-scale data can reach tens of thousands to hundreds of thousands of USD
Checklist
Section titled “Checklist”- Are you managing an inventory of lock-in levels (high/medium/low) per workload?
- Have you defined Exit trigger scenarios (price increases, service discontinuation, regulatory changes)?
- Do you review the Exit Plan annually and perform impact analysis on major architecture changes?
References
Section titled “References”- AWS Prescriptive Guidance — Building a multicloud strategy (FSI)
- AWS Prescriptive Guidance — Considering vendor lock-in
Google Cloud
Section titled “Google Cloud”Standards and Regulations
Section titled “Standards and Regulations”- CNCF Cloud Native Trail Map
- EU DORA (Digital Operational Resilience Act)
- ESAs CTPP Designation and Oversight Framework — first CTPP designation list published November 2025
- Martin Fowler — Strangler Fig Application