Lock-in is usually discussed as something to be avoided entirely, which leads teams to reject managed services and rebuild them badly. Every dependency is lock-in of some degree, including the operating system and the programming language.
The useful question is not whether you are locked in but how expensive each particular exit would be, and whether the capability is worth that price.
Rank dependencies by exit cost
A managed database speaking a standard protocol is cheap to leave — the data and the queries move. A proprietary workflow engine with your business logic expressed in its own format is expensive. A platform whose data model your entire application assumes may be effectively permanent.
Sorting your dependencies this way usually reveals that most are fine and one or two deserve attention.
Count what avoidance costs
Refusing managed services means operating the equivalent yourself: patching, scaling, backups, and expertise. That is a genuine, continuous cost paid for optionality you may never exercise.
Portability is worth paying for where a move is plausible. Where it is not, the insurance premium exceeds the risk.
Abstract at the boundary, not everywhere
A thin interface around a vendor service keeps the option open at modest cost. A full abstraction layer designed to support every provider generally delivers the lowest common denominator and never gets used for its intended purpose.
Write the interface you need today, in your own vocabulary, and leave the rest.
Protect the data above all
You can rewrite code. You cannot recreate data you cannot export. Establish before committing how data comes out, in what format, how completely, and at what cost.
A service with clean export is a reversible decision regardless of how proprietary its internals are.
Use the managed service, keep the boundary thin, know your export path, and spend the saved effort on the part of the system that is actually yours.
