Vendor Lock-in Mitigation

Overview

Lock-in is a cost, not a sin. The goal is to know what you are locked into, why, and what leaving would take. Mitigation focuses effort on dependencies where the exit risk is highest.

Lock-in has several forms: technical APIs, data formats, operational skills, contractual commitments, and ecosystem integrations. Contractual terms such as committed spend discounts count too, so review them alongside the architecture.

How it works

Hide the vendor behind your own interface and keep data portable.

interface BlobStore { put(key, bytes); get(key); delete(key) }
class S3Store implements BlobStore { ... }      // adapter
class GcsStore implements BlobStore { ... }     // alternate, tested in CI
// Exit plan: nightly export to open format, runbook, effort estimate: 8 weeks

Score each vendor on switching cost and criticality, and invest in mitigation only where both are high. For a database, that might mean standard SQL and regular exports. For identity, it might mean standard protocols such as OIDC and SAML, plus a documented user migration path.

Pitfalls

• Building a generic abstraction over every vendor feature, which becomes the lowest common denominator
• Writing an exit plan but never testing a trial migration
• Ignoring data gravity: egress fees and volume often dominate switching cost
• Treating multi-cloud as a default rather than a targeted answer to a specific risk

Key takeaways

• Choose lock-in deliberately and record it in ADRs
• Wrap proprietary APIs in thin adapters
• Prefer open formats and protocols
• Test the exit with a small trial migration