Cloud vendor lock-in: when switching costs become a business risk

22 April 2026Bizonbyte Team6 min read

The promise was compelling: infinite scalability, pay-as-you-go pricing, and no physical infrastructure to manage. After a decade in the cloud era, European companies are waking up to an uncomfortable reality. The freedom they wanted has often become another kind of constraint.

A massive anchor made of tangled ethernet cables and cloud service logos, half-submerged in deep blue water, with a small boat above struggling against the weight—dramatic lighting with storm clouds gathering on the horizon

Cloud vendor lock-in rarely comes from one decision. It accumulates through hundreds of small, reasonable choices: using a proprietary database service because it is faster to implement, choosing a serverless framework because it reduces operational work, or storing data in a format optimised for one provider’s query engine. Each choice makes sense on its own. Together, they build an invisible wall around your infrastructure.

The real cost of “free” migration

Cloud providers do not charge you to upload data. They charge you to take it out. This asymmetry is not accidental — it is a business model. Egress fees, the cost of moving data outside a provider’s network, can turn a theoretical migration into a budget shock.

Consider a mid-sized Dutch logistics company with 500 terabytes of operational data stored with a major cloud provider. At typical egress rates of €0.05–€0.09 per gigabyte, simply downloading its own data could cost €25,000–€45,000. That is before engineering time, testing, and inevitable troubleshooting.

But egress fees are only the visible part of the iceberg. The deeper costs sit underneath:

Rewriting applications: services built on proprietary APIs do not translate automatically. A function written for AWS Lambda will not run on Azure Functions without changes. Code using Google BigQuery syntax will not execute on Amazon Redshift.

Operational knowledge: your team has spent years mastering one ecosystem. That expertise is not transferable by default. Retraining or hiring brings real costs and lost productivity.

Integration dependencies: authentication systems, monitoring tools, and CI/CD pipelines are usually deeply intertwined with provider-specific services.

Contract timing: multi-year commitments with volume discounts create financial penalties for leaving before the terms are complete.

How lock-in really develops

Understanding the progression helps identify intervention points. Lock-in usually moves from easy choices to structural dependencies.

A cross-section diagram showing geological layers, but instead of rock strata, each layer represents progressive cloud integration—shallow surface layer showing basic compute/storage, middle layers showing managed databases and proprietary APIs, deepest layer showing custom machine learning models and data gravity—each layer visibly harder to excavate than the one above

Stage 1: Compute and storage — relatively portable. Virtual machines and object storage work similarly across providers. Switching is difficult but manageable.

Stage 2: Managed services — convenience increases while portability declines. Managed databases, message queues, and caching services use similar concepts but different implementations.

Stage 3: Proprietary platform services — lock-in accelerates. Serverless functions, AI/ML platforms, and specialised analytics tools bind your architecture to specific providers.

Stage 4: Data gravity — the point at which moving back becomes impractical. When petabytes of data accumulate, migration becomes difficult regardless of technical compatibility. The data itself anchors you.

Most organisations do not consciously decide to become locked in. They wake up in stage 3 or 4 and wonder how they got there.

Measure your actual exposure

Before addressing lock-in, understand your current position. An honest assessment needs to examine several dimensions:

Technical dependency audit: list every cloud service you use. For each, identify open-source or multi-cloud alternatives and estimate replacement effort realistically.

Data inventory: where is your data stored, in what formats, and at what volumes? Calculate theoretical egress costs. Identify data that cannot be moved without first replacing processing dependencies.

Contract analysis: what commitments exist? What penalties apply to lower usage? When do renewal windows open?

Capability assessment: how provider-specific is your team’s expertise? What is the real retraining period?

This exercise often produces uncomfortable revelations. A technology director at a Dutch financial-services provider described the results of their audit as “sobering”: they estimated 18 months and €2 million to migrate their core platform, assuming no business interruption. The strategic flexibility they thought they had was largely theoretical.

Practical strategies that work

Avoiding all lock-in is unrealistic. Proprietary services often provide real benefits in speed, capability, or operational simplicity. The goal is not elimination but conscious management.

Containerisation as insurance: Kubernetes is one of the closest options to a cloud-neutral deployment platform. Managed Kubernetes differs by provider, but workloads built with standard container tooling remain significantly more portable than provider-specific deployments.

Abstract your dependencies: design applications with interfaces between business logic and cloud services. Instead of calling AWS S3 directly throughout the codebase, use an abstraction layer that could theoretically target different backends. It adds development overhead and you may never use it. Treat it as architectural insurance.

Negotiate data portability: before signing large contracts, negotiate egress limits or free data-export provisions. Providers increasingly offer these terms to large customers. The negotiation window is before signing, not when you are trying to leave.

Use multi-cloud for critical workloads: running identical systems at multiple providers is expensive and complex. For genuinely critical capabilities, optionality may justify the cost. This is not about efficiency; it is about strategic flexibility.

Prefer open standards where practical: PostgreSQL instead of proprietary database services, Apache Kafka instead of provider-specific queues, and standard authentication protocols instead of provider-owned identity systems. Each open-standard choice preserves a future option.

The European dimension

For Dutch and European organisations, lock-in creates more than commercial risk.

Data-sovereignty requirements under GDPR place real limits on where data can be stored and how it can move. Heavy dependence on non-European providers adds regulatory complexity that domestic or European alternatives may avoid.

The European Commission’s Gaia-X initiative and national cloud strategies aim to create sovereign alternatives. They are not mature enough to replace hyperscaler capabilities for most workloads, but they are worth watching. Regulatory pressure on cloud contracts, including standardisation and data-portability requirements, will continue to increase.

Some Dutch organisations now maintain separate infrastructure for data subject to strict legal requirements, accepting the operational complexity as the price of compliance certainty.

Make informed trade-offs

Lock-in is not inherently wrong. Every technology choice involves compromises. The problem is not using proprietary services; it is using them without understanding the implications.

A startup launching quickly may reasonably accept significant lock-in in exchange for development speed. An established enterprise with a ten-year planning horizon should weigh flexibility differently. A highly regulated organisation faces constraints that do not apply to others.

A chess board viewed from above at a crucial mid-game moment, where several pieces are positioned showing multiple possible strategies—the board's squares subtly textured with different cloud provider patterns, some pieces clearly committed to one region while others maintain central flexibility

The honest questions to ask are:

What would trigger the need to migrate? Is that scenario realistic?
If migration became necessary, what would it really cost? Could the business absorb it?
Do proprietary services create enough value to justify the constraint?
What is our minimum viable level of portability?

Move forward deliberately

Cloud vendor lock-in is not a problem to solve once. It is a risk to manage continuously. As architectures evolve and providers introduce new services, the calculation changes.

Regular dependency audits — at least annually — help ensure that lock-in remains conscious rather than accidental. Architecture reviews should assess portability alongside security and performance.

Organisations that handle this well share one trait: they treat cloud strategy as a business decision, not only a technical one. Engineering teams understand commercial constraints. Leadership understands technical reality. Decisions are made with the trade-offs visible.

Cloud strategy requires a balance between the speed of innovation and long-term flexibility. At Bizonbyte, we help Dutch organisations assess their current position, understand their options, and make deliberate decisions about digital infrastructure. If you are wondering whether your cloud architecture serves your business strategy, we should talk.