Lock-in anxiety produces some of the most expensive architecture decisions in enterprise software: abstraction layers over cloud services, self-hosted alternatives to managed ones, portability requirements that constrain every design. The anxiety is not baseless, but it is usually pointed at the wrong things. Some dependencies are genuinely hard to leave; others are trivial and get treated as though they were not.
The dependencies that genuinely bind you are the ones holding state and behaviour together. A proprietary database with no compatible alternative. A managed service whose semantics you have built business logic around. Data volumes large enough that egress charges alone make an exit uneconomic - this one is underrated, because the number grows quietly until leaving costs more than staying. And identity, which threads through everything and is unpleasant to replace.
What is not real lock-in, however much it is discussed: managed compute, object storage, managed Postgres or MySQL, queues, and load balancers. These have equivalents everywhere and the migration is work rather than a trap. Choosing a worse option among these to preserve theoretical portability is paying a permanent tax to avoid a cost you would only ever pay once, and probably never.
Abstraction layers deserve particular scepticism. Wrapping a cloud provider's services in your own interface sounds prudent and in practice means you use the lowest common denominator of every provider, maintain the abstraction forever, and debug through an extra layer during every incident. Teams that build these almost never migrate, and the ones that do find the abstraction leaked in exactly the places that mattered.
What is worth doing is cheap and specific. Keep your data in formats you can export - open formats, documented schemas. Keep infrastructure in code, so recreating an environment elsewhere is a known quantity rather than an archaeology project. Know your egress cost before it is a surprise. And avoid building business logic inside a vendor's proprietary workflow engine, because that is the code you cannot take with you.
The most common real lock-in is not technical at all, and it is worth naming: the multi-year contract with an early termination penalty, or the development partner who holds your cloud account, your repository and your domain. No architecture protects against those. Read the commercial terms with the same care you would give a database choice, because that is where the door actually gets locked.
