Short answer
#The only useful principle
- Lock-in
- The cost of moving away from a chosen supplier, platform or approach, measured in time, money and risk — including the cost of the work that does not get done while the move happens.
- In plain terms How much it would cost to change your mind later.
Every technology choice creates some. The question is never "is there lock-in" but "is the cost of escaping it larger than the cost of avoiding it?" — and for most technical decisions the answer is no, because avoiding lock-in means building abstractions you do not need, on the chance you will one day want a different thing.
A useful test: would a competent team be able to move this in a quarter, if it were worth doing? If yes, it is a cost. If no, or if the answer is "we could not move it at all", it is a risk, and risks are worth money.
#Six kinds of lock-in
| Kind | Example | Cost to escape |
|---|---|---|
| Ownership | The domain, cloud account or data held in somebody else's name | Potentially unbounded. You may not be able to escape at all |
| Knowledge | Only the supplier understands the system | Months of a new team rediscovering, paid for twice |
| Proprietary component | A supplier's own framework inside your product | Weeks to quarters, and it outlives the contract |
| Platform | Built entirely on one cloud's managed services | A quarter or two, and usually not worth doing |
| Data format | Business data in a proprietary store with no export | Varies enormously. Check before you need to |
| Skills market | An unusual language or framework few people know | A permanent tax on hiring rather than a one-off cost |
#The two worth paying to avoid
Ownership lock-in is the only kind on the list that can leave you unable to operate rather than merely delayed. It is also the cheapest to fix: moving accounts into company identities is an afternoon, and it does not require changing anything technical. Who owns production infrastructure is the whole of the fix.
Knowledge lock-in is the one that decides how long and how painful a supplier change is. It is also the one nobody measures, because it looks like a good relationship right up until it becomes a bill. The fix is to make the understanding exist somewhere the company holds — derived from the system, with citations, refreshed when something material changes.
Why these two and not the others
Both are cheap to prevent and expensive to have, which is an unusual combination. Platform lock-in is the reverse — expensive to prevent, moderately expensive to have — and that asymmetry is the whole of the argument.
#The ones worth accepting
- Platform. Building on one cloud's managed services is usually the right trade: you get more product, sooner, in exchange for a migration cost you will probably never pay. Writing an abstraction layer over three clouds "in case" is a well-known way to spend a year.
- Framework and language. Within reason. Choosing something with a large market is worth doing at the start and is rarely worth revisiting.
- Third-party services. A payment provider, an email service and an error tracker are all replaceable in days. Their lock-in is real and small.
One qualification: accepting platform lock-in is a decision, and decisions should be recorded. "We chose this deliberately and here is what it would cost to move" is a very different position from "nobody remembers why this is like this".
#How to assess a specific decision
Four questions, in order. They take ten minutes and they are enough for almost every real case.
-
Could we get our data out today?
Not in principle — today, in a format we could load somewhere else. If the answer is unclear, find out before the decision rather than after.
-
If this supplier disappeared, could we still operate?
Not “would it be painful”. Could the product keep running while we found an alternative?
-
How long would a competent team need to move it?
A rough number with a reason. If two people on your side differ by a factor of three, nobody knows, and that is the finding.
-
What are we buying with the lock-in?
Speed, cost, capability, a smaller team. If the answer is “nothing in particular, it is just how it was set up”, that is the case worth revisiting.
#What goes wrong
Building abstractions to avoid platform lock-in you will never escape.
Instead Accept it deliberately, record the decision and what moving would cost, and spend the effort on the product.
Worrying about the cloud while the domain is in a contractor's name.
Instead Ownership first. It is the only category that can leave you unable to operate.
Treating knowledge lock-in as a relationship question.
Instead It is a storage question. The understanding either exists somewhere the company holds or it does not, and that is independent of how much you like the supplier.
Discovering the export format on the day you need it.
Instead Export your data once, now, and try to load it somewhere else. The exercise takes a day and occasionally changes a supplier decision.
Choosing unusual technology for a small advantage.
Instead The hiring tax is permanent and compounds. It is worth paying only where the advantage is genuinely structural.
#What this does not cover
What this does not do
- Specific vendor comparisons. What a particular cloud or platform costs to leave depends on what you built on it.
- Licensing and contractual restrictions on moving. That is a lawyer's question and it can override every technical consideration here.
- Open-source strategy, which is a related but different conversation.
- Cost optimisation. This page is about optionality, not about the bill.