Vendor Lock-In

Vendor lock-in occurs when the effort, cost or risk of moving to another provider is high enough that a customer is effectively tied to the current one. In cloud and hosting, it arises from proprietary services and APIs, data formats, egress fees, contracts and the skills a team has built around one platform.

Why it matters

Lock-in reduces bargaining power and makes it harder to react to price rises, outages, policy changes or a provider leaving a market. It is not always bad. Proprietary managed services can save substantial engineering time, so the practical question is whether the benefit is worth the exit cost. Teams reduce risk by using open standards and portable tools such as containers, PostgreSQL or Kubernetes, keeping data exportable and documenting an exit plan.

Example

Portable:   app in a container + PostgreSQL + Terraform
Locked in:  business logic in a provider-only workflow service,
            data in a proprietary database with no export tool

Moving the first set mostly means redeploying; moving the second may mean rewriting.

Common mistakes

• Avoiding every proprietary service and slowing down delivery for a migration that may never happen.
• Ignoring data egress charges when estimating exit cost.
• Never testing that a backup can be restored elsewhere.

Related

• Multi-cloud
• Egress fees
• Open source
• Container

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.