Home / Insights / Architecture and Modernization
Architecture and Modernization
Cloud Vendor Lock-In: How Much Is Acceptable and How to Keep Your Options Open
Some lock-in is the price of using powerful managed services; too much leaves you exposed to price rises and outages. This guide explains the sources of lock-in, how to decide what level is acceptable and the architecture and contract practices that keep your options open.
TopicsArchitecture and ModernizationSoftware Costs and BudgetsBusiness Operations and Integration
Key takeaways
- Lock-in comes from proprietary services, data gravity and egress costs, tooling and skills, and contract commitments.
- Zero lock-in is neither possible nor desirable; managed services deliver real value. The goal is deliberate, understood dependency.
- Classify components by switching cost and business criticality, and invest in portability where both are high.
- Use open standards, containers, infrastructure as code and abstraction layers where they add little cost.
- Keep an exit plan: data export, documented dependencies and contract terms that support leaving.
On this page
Cloud providers offer managed databases, serverless functions, AI services and analytics that would be expensive to build yourself. Using them speeds delivery but creates dependency. Vendor lock-in becomes a problem when switching costs are so high that you cannot respond to price increases, service changes, outages or new requirements.
Sources of lock-in
| Source | Example | Switching impact |
|---|---|---|
| — | — | — |
| Proprietary services | Serverless platforms, proprietary databases, AI services with unique APIs | Code and architecture changes |
| Data gravity | Large datasets stored with one provider | Time and cost to move data |
| Egress costs | Fees for transferring data out | Ongoing and one-off costs |
| Tooling | Provider-specific monitoring, IAM, deployment tools | Operational rework |
| Skills | Team expertise in one provider | Retraining or hiring |
| Contracts | Committed spend and discounts | Financial penalties or wasted commitments |
Data and skills are often harder to move than code.
Deciding what is acceptable
Classify components by two factors:
| Low switching cost | High switching cost | |
|---|---|---|
| — | — | — |
| Low criticality | Use freely | Accept with awareness |
| High criticality | Use freely | Invest in portability or exit planning |
Focus portability effort on critical systems with high switching costs.
Architecture practices
- Containers and Kubernetes for workloads that may need to move.
- Infrastructure as code with modular templates.
- Open data formats and standard database engines where practical.
- Abstraction layers around provider-specific services you may need to replace, such as AI model gateways and messaging adapters.
- Open standards for observability, identity and APIs.
- Avoid unnecessary proprietary features in core domain logic.
Each practice has a cost; apply them where the risk justifies it rather than everywhere.
Contract and commercial practices
- Negotiate data export assistance and reasonable egress terms for exit.
- Align commitment terms with realistic usage.
- Understand price-change notice periods and service deprecation policies.
- Keep ownership of accounts, data and encryption keys.
Exit planning
- Inventory dependencies on provider-specific services.
- Document data locations, volumes and export methods.
- Estimate effort and cost to move critical systems.
- Test partial exits, such as restoring backups in another environment.
- Review annually or when architecture changes significantly.
Multi-cloud: when it makes sense
Running across several providers can reduce dependency and meet specific requirements, but it increases complexity, skills needed and often cost. It makes sense for specific workloads — regulatory requirements, best-of-breed services, resilience for critical systems — rather than as a blanket policy.
Frequently asked questions
Should we avoid managed services to prevent lock-in?
No. Managed services often deliver large productivity and reliability gains. Use them deliberately and understand switching costs for critical components.
Is Kubernetes enough to avoid lock-in?
It helps with compute portability, but databases, data, identity and managed services usually create more dependency.
How expensive is it to leave a cloud provider?
It depends on data volume, use of proprietary services and team skills. Estimating it periodically keeps the risk visible.
Does AI increase lock-in?
It can, through proprietary model APIs and data stored in vendor-specific formats. Model gateways and owning your evaluation sets reduce this — see our guide to sovereign AI.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
Related reading
Continue your research
Worried about depending on one cloud provider?
Share your architecture and concerns. We will help you identify critical dependencies and design practical exit options.