A team says it is locked in to its cloud platform "because of the code" — what does lock-in actually mean, and which kinds are not code?

## Lock-in is a price, not a wall **Lock-in** is what it would cost you to stop using a platform and run the same system somewhere else. It is a number — money, engineer-time and calendar — not a physical barrier. Very little on a large cloud platform is genuinely impossible to leave; plenty of it is expensive enough that nobody ever does. So "we are locked in" with no number attached is not an answer, it is a mood. The interview question behind this one is whether you can turn that mood into an inventory. The useful move is to stop treating lock-in as one undifferentiated fear and split it into the bills that make it up. Four are worth naming, because each is paid by different people, measured in a different unit, and reduced by a different action. ## The four bills | Dimension | What it is | Measured in | Who ends up paying it | |---|---|---|---| | Technical | application code calling a proprietary interface with no equivalent elsewhere | call sites to rewrite, engineer-months | the team that rebuilds and retests | | Data | stored bytes that would have to be copied out | gigabytes multiplied by what moving a gigabyte costs | the transfer charge, and the calendar the copy occupies | | Operational | knowledge that only applies on this platform | engineer-months of relearning, longer incidents afterwards | whoever is on call on the far side of the move | | Commercial | an unexpired term commitment | months and money left to run | finance, whether or not the workload still exists there | ## The three that are not code - **Data.** Storing bytes is cheap and taking them back out is not: traffic leaving a platform is normally metered and charged per gigabyte, while traffic arriving normally is not. On top of the charge sits elapsed time — a copy measured in weeks is a schedule, not a line item — and the fact that a live dataset keeps changing while the copy runs. This dimension is the one that grows every day without anybody deciding anything. - **Operational.** A team that has only ever run one platform knows its failure modes, its defaults and where its sharp edges are. That knowledge does not transfer cleanly. A move buys a period in which the same incident takes longer to diagnose, the same change is likelier to be wrong, and hiring is against a smaller pool of people who already know the destination. - **Commercial.** A term commitment is a promise to spend, and it normally goes on billing for the remainder of its term regardless of whether the workload it was bought for is still there. Some contracts allow a transfer or a buy-out; the point is that the obligation is a separate bill from the technical work, and it expires on a date rather than when the migration finishes. ## Why splitting them changes the conversation 1. **Different owners, different remedies.** Rewriting call sites is an engineering plan; shrinking stored volume is a data-retention decision; relearning is a hiring and training question; the commitment is a finance conversation. Lumped together, none of them gets acted on. 2. **You can rank them.** Once each row has a rough size, one of them is usually much larger than the other three — and that is the one that actually decides whether leaving is realistic. 3. **They run on different clocks.** Data accumulates continuously. The commitment ends on a known date. The code dimension only changes when somebody rewrites something. Skills change slowly in both directions. A snapshot taken today is not the answer for next year. ## What lock-in is not - **Not the monthly bill.** What you pay to keep running is the cost of *staying*. Lock-in is the one-off cost of *leaving*. Confusing the two produces migrations justified by the wrong number. - **Not removed by an open interface.** Using an interface several platforms implement can shrink the technical bill, and leaves the data, the people and the contract exactly where they were. - **Not automatically a reason to say no.** Accepting a proprietary capability can be the right call; what is not defensible is accepting it without knowing which of the four bills it grows. - **Not a migration plan.** Naming and sizing what binds you is a different exercise from sequencing and pricing an actual move. ## What an interviewer is listening for At this level the expected answer is short: lock-in is the cost of leaving, and it is not only code — data, people and the contract each carry their own cost. Naming even two non-code dimensions and saying what unit each is measured in is enough to pass; claiming that a platform "traps" you, or that using open interfaces means there is no lock-in at all, is what fails.