Vendor Lock-In Is a Spectrum, Not a Binary: A Pragmatic Assessment Framework
A pragmatic framework for assessing vendor lock-in across five dimensions — helping architects make informed trade-offs between cloud-native efficiency and portability costs.
"We cannot use Azure Cosmos DB because it creates vendor lock-in."
This statement treats lock-in as binary — either you are locked in or you are not. In reality, lock-in is a spectrum. Every technology decision involves some degree of coupling, and the goal is not zero lock-in (which is unachievable) but informed lock-in where the benefits justify the switching costs.
This framework helps architects assess lock-in across five dimensions and make pragmatic decisions rather than ideological ones.
The Five Dimensions of Lock-In
Dimension 1: Data Lock-In
How difficult is it to extract your data from the service?
| Score | Description | Example |
|---|---|---|
| 1 | Standard formats, easy export | Azure Blob Storage (standard APIs, easy migration to S3) |
| 2 | Standard formats, large volume | Azure SQL Database (standard SQL, but terabytes of data take time) |
| 3 | Proprietary format, export available | Cosmos DB (proprietary wire protocol, but JSON export works) |
| 4 | Proprietary format, complex export | Dynamics 365 (structured data, complex relationships) |
| 5 | Data is entangled with service logic | Power Platform (data + business logic + UI are intertwined) |
Key question: Can you export all your data in a format that another service can import without data loss?
Dimension 2: API and Interface Lock-In
How tightly coupled is your application code to the provider's APIs?
| Score | Description | Example |
|---|---|---|
| 1 | Industry standard APIs | S3-compatible storage (many providers support the S3 API) |
| 2 | Standard protocol, provider extensions | Azure Service Bus (AMQP standard, but proprietary management API) |
| 3 | Provider-specific SDK, abstraction possible | Azure Functions (provider SDK, but business logic is portable) |
| 4 | Deep API integration | Azure AD/Entra ID (identity model deeply embedded in application) |
| 5 | No equivalent exists elsewhere | Azure Arc (no direct equivalent on other platforms) |
Key question: How many lines of code would need to change to swap providers?
Dimension 3: Identity and Access Lock-In
How dependent are you on the provider's identity platform?
| Score | Description | Example |
|---|---|---|
| 1 | Standard protocols (OIDC/SAML) | Any OIDC-compliant IdP (easy to swap) |
| 2 | Standard protocols with extensions | Entra ID with Conditional Access (OIDC + proprietary policies) |
| 3 | Deep identity integration | Microsoft 365 + Entra ID + Intune (identity = platform) |
| 4 | Identity is the platform | Entra ID with PIM, access reviews, identity governance |
| 5 | Cross-platform identity dependency | Entra ID federated with 50 SaaS applications |
Key question: If you changed identity providers, how many systems would break?
Dimension 4: Networking Lock-In
How coupled is your network architecture to the provider?
| Score | Description | Example |
|---|---|---|
| 1 | Standard networking | VNet peering (concept exists on all clouds) |
| 2 | Provider-specific features | Azure Private Link (proprietary but concept is portable) |
| 3 | Deep networking integration | ExpressRoute with specific peering locations |
| 4 | Provider-specific architecture | Azure Front Door + WAF + Private Endpoints chain |
| 5 | Network is the product | Azure Virtual WAN spanning multiple regions |
Dimension 5: Operational Knowledge Lock-In
The most underestimated dimension. How much of your team's expertise is provider-specific?
| Score | Description | Example |
|---|---|---|
| 1 | Transferable skills | Kubernetes (works on any cloud) |
| 2 | Mostly transferable | Terraform (provider-specific modules but same language) |
| 3 | Partially transferable | Azure DevOps (CI/CD concepts transfer, specific features do not) |
| 4 | Mostly provider-specific | Azure Monitor + Log Analytics (query language and dashboards) |
| 5 | Entirely provider-specific | Power Platform / Power Automate |
Key question: If your team had to operate on AWS tomorrow, how long before they are productive?
Scoring and Interpretation
For each service or platform decision, score all five dimensions (1-5). The total score indicates the lock-in level:
| Total Score | Lock-In Level | Interpretation |
|---|---|---|
| 5-10 | Low | Migration is straightforward. Use native services freely. |
| 11-15 | Moderate | Migration is feasible but requires planning and investment. |
| 16-20 | High | Migration is expensive. Ensure the business justification is strong. |
| 21-25 | Very High | Migration is a major project. Only accept if the benefits clearly outweigh the switching cost. |
The Cost of Avoiding Lock-In
Lock-in avoidance has its own costs:
Abstraction Layer Tax
Building abstraction layers (e.g., wrapping Azure Blob Storage and S3 behind a common interface) costs engineering time upfront and maintenance time forever. If you never migrate, this investment returns nothing.
Lowest Common Denominator Architecture
Using only features available on all clouds means missing the features that make each cloud valuable. Azure Cosmos DB's multi-model capability, AWS Lambda's ecosystem, and GCP BigQuery's analytics power are competitive advantages you forfeit for portability.
Multi-Cloud Operational Overhead
Running workloads on multiple clouds simultaneously means:
- Multiple IAM systems to manage
- Multiple billing systems to monitor
- Multiple monitoring and alerting platforms
- Multiple networking models to understand
- Team training and certification across platforms
Honest assessment: For most enterprises with fewer than 10,000 employees, the operational cost of multi-cloud exceeds the lock-in risk it mitigates.
When Lock-In Is Acceptable
- The service delivers significant competitive advantage — Cosmos DB's global distribution is worth the lock-in if your application needs single-digit millisecond latency across continents
- The switching probability is very low — If you have a 5-year Azure EA and no realistic reason to migrate, optimise for Azure-native efficiency
- The switching cost is manageable — Lock-in at score 10-15 means migration is a project, not a crisis
- The alternative costs more — A "portable" architecture that costs 40% more to build and operate is not a good trade
When Lock-In Is Dangerous
- The vendor relationship is deteriorating — Pricing disputes, support quality declining, strategic direction diverging
- Regulatory risk — A new regulation could require data sovereignty that your current provider cannot meet
- Acquisition risk — The vendor could be acquired and the product sunsetted
- Single-provider concentration — If 100% of your infrastructure is on one provider, a pricing increase has existential leverage
Practical Recommendations
- Score every significant architecture decision against the five dimensions
- Accept lock-in consciously — Document the decision and the rationale
- Invest in portability only where switching is plausible within 3-5 years
- Use standard interfaces where the cost is low — Kubernetes over proprietary container orchestration, PostgreSQL over proprietary databases
- Review lock-in scores annually — Business context changes, and so should your tolerance
Need help assessing vendor lock-in for your cloud architecture? Contact us — we help architects make pragmatic decisions about portability and native service adoption.
Topics