What No Vendor Lock-In Actually Requires: A Checklist
No vendor lock-in is a claim most tools fail. Here is the checklist for what real portability requires: open formats, standard runtimes, and a tested exit.
"No vendor lock-in" is on half the landing pages I read, and most of them are lying. Not on purpose. They mean it aspirationally. But real portability is not a promise, it is a property of your architecture, and it either holds up under a test or it does not. If you have never actually moved a workload off a vendor, you do not know whether you are locked in. You are guessing.
Here is the checklist I use to decide whether a stack is genuinely portable, based on running a portfolio where every app has to be movable.
What does no vendor lock-in really mean
It means you can leave a vendor without rewriting your application or losing your data. That is the whole test. If leaving requires re-architecting, you are locked in, no matter what the marketing says. Portability is measured in the cost and time of an exit, and the only honest way to know that number is to have run the exit at least once in staging.
Most teams never run that test. They assume portability because the vendor uses friendly words. Then a price hike or an outage forces the move, and they discover the export is incomplete, the API was proprietary, and three services had no open equivalent. The bill for that discovery is a rewrite under deadline pressure.
The portability checklist
Open data formats. Your data lives in formats other tools can read: SQL dumps, JSON, CSV, S3-compatible object storage. If any critical dataset only exports in a proprietary blob, that dataset is hostage.
Standard runtimes. Your app runs on plain Linux, standard containers, or a common language runtime, not a proprietary execution environment. If the only place your code runs is one vendor's serverless platform with their custom bindings, you cannot lift it out.
Open protocols at the boundaries. SMTP for mail, plain HTTP and standard SQL for data, S3 API for storage. Standard protocols are the seams your app can be cut along. Proprietary SDKs weld the seams shut.
A tested exit. You have actually stood the app up somewhere else, at least once. Not planned to. Done it. This is the step everyone skips and the only one that proves the rest.
Your own deploy path. You can build and ship the app without the vendor's pipeline. If deploys only work through their proprietary CI, you inherited another dependency. I get into owning that step in what a deploy you actually control looks like.
Why owning the base layer makes the rest easy
Everything on that checklist gets easier when the bottom of your stack is a box you control. On a plain server running standard Linux, open formats and standard runtimes are the default, not something you engineer around a vendor. That is why I run my portfolio on infrastructure I own through HostSSH: the base layer is boring, standard, and mine, so portability sits on top for free.
Compare that to a fully managed platform where every layer is proprietary. There, portability is something you have to fight for at every level, and usually lose. The decision of where to draw that line is the real one, and I walked through it in self host vs managed cloud, how to decide.
What lock-in-free does not mean
It does not mean zero switching cost. Moving is always some work. A tool with a two-day migration is not locked in. A tool with a two-quarter rewrite is. The goal is not friction-free, it is affordable and known.
It also does not mean you self-host everything. I use managed services where the lock-in is small and the convenience is large. Managed Postgres, for example, exports cleanly and has an open equivalent, so the exit stays cheap. The trap is not managed services. The trap is managed services with no export and no open equivalent, chosen without ever pricing the exit.
Run the checklist before you commit, not after. Open formats, standard runtimes, open protocols, a tested exit, your own deploy path. If a vendor clears all five, "no vendor lock-in" is true. If it clears three, you own the gap, and you should know exactly how expensive that gap is before it becomes a rewrite you did not plan for.