The idea, explained
Lock-in is not the same as simply liking one vendor. It appears when the cost and risk of leaving reduce your practical choices. A service may have a low monthly price yet create high switching costs through proprietary data formats, provider-specific programming interfaces, long committed-spend contracts, data-transfer charges, or specialist training.
Start by mapping dependencies. List the data stored in the service, the interfaces that connect it to other systems, the identities and permissions it controls, the staff skills it requires, and the contract terms that affect renewal or departure. For each dependency, ask whether there is a documented export method, a compatible replacement, and a tested recovery path.
Next, separate portability from interoperability. Portability asks whether an asset can move: for example, can customer records be exported in a documented format? Interoperability asks whether systems can cooperate without a full move: for example, can two clouds exchange data through standard interfaces? NIST identifies both as important cloud requirements. The UK Competition and Markets Authority has also identified data-egress fees and interoperability barriers as limits on switching and multi-cloud choice.
Finally, turn the map into an exit plan. Record who owns the data, how long an export takes, what it costs, which features must be rebuilt, how service continues during migration, and how the old copy is securely deleted. Test a small export before signing or renewing. An exit plan does not require avoiding every proprietary feature; it makes the benefit of that feature visible beside the future cost of leaving.
Follow a worked example.
A small retailer is comparing Cloud A and Cloud B for an order system. Cloud A costs $4,000 per month and uses several provider-specific database and messaging features. Cloud B costs $4,700 per month and relies more heavily on standard containers and a common database engine.
The team first calculates one year of service: Cloud A is $48,000 and Cloud B is $56,400, so Cloud A appears $8,400 cheaper. Then it estimates a possible exit after two years. For Cloud A, data export is $3,000, engineering work is 320 hours at $100 per hour, staff retraining is $6,000, and a temporary overlap of services is $4,000. Estimated exit cost: $3,000 + $32,000 + $6,000 + $4,000 = $45,000. For Cloud B, the comparable estimate is $12,000 because more components can move unchanged.
This does not automatically make Cloud B the right choice. The team records both operating value and exit exposure. It also runs a trial export of anonymized test data, times the process, restores it in a second environment, and checks that order totals and customer identifiers match. The test converts assumptions into evidence before the contract creates a deadline.
Where people get stuck
A common misconception is that using open standards eliminates lock-in. Standards can improve portability, but real systems still depend on configurations, security rules, managed services, staff knowledge, and contracts. Another mistake is to count only an export fee. Labour, downtime, parallel operation, data validation, retraining, and lost features can be larger. Use ranges when costs are uncertain, and update the estimate whenever architecture or contract terms change.
Now try it yourself.
1. Check the core idea
A service has no data-export fee but requires 200 engineering hours, $5,000 of retraining, and $3,000 of parallel operation to leave. Engineering costs $120 per hour. What is the estimated switching cost, and what else should be tested?
Reveal the answer & reasoning
Engineering costs 200 × $120 = $24,000. Adding $5,000 for retraining and $3,000 for parallel operation gives an estimated switching cost of $32,000. A zero export fee therefore does not mean zero lock-in. The team should also test whether exported data is complete and documented, whether a replacement can reproduce critical workflows, how long migration and rollback take, whether identities and permissions transfer safely, and whether contract deadlines create extra risk. The result is an estimate, not a guarantee, so a range and a small migration rehearsal are better than a single untested number.
Why this was added
The library covers APIs and portable execution but not the business and technical mechanics of vendor lock-in, switching-cost measurement, or an evidence-based exit plan.