Vendor lock-in

Vendor lock-in is the collection of costs and obstacles that make it hard to leave a supplier once you have committed to it. It is not a single thing. A platform can be easy to leave in one respect and hard in another, so the useful question is not whether lock-in exists but which forms of it apply to you and how much each would cost to overcome. Naming the forms precisely is the first step to reading your own position.

The forms it takes

Data lock-in. How easily you can get your content out in a usable shape. A platform with a full export in an open format is easier to leave than one where the only path out is scraping the front end or paying for a custom extract.

Format lock-in. Whether your content is stored in a proprietary shape. Rich text saved in a vendor-specific format, page layouts built from that vendor’s block system, or templates written in its own language all have to be converted, not just copied, when you move.

Contract lock-in. The commercial terms: multi-year commitments, notice periods, and pricing that makes leaving mid-term expensive regardless of the technical picture.

Skills lock-in. The investment your team has made in one platform. Staff trained on a specific system, and hiring built around it, are an asset while you stay and a cost when you move, because the next platform means retraining or rehiring.

Some lock-in is a fair trade

Lock-in is not automatically a problem. A managed platform that holds your data and runs everything for you is providing real convenience, and accepting some difficulty of exit is a reasonable price for not operating the system yourself. Open formats and self-hosting reduce lock-in but move more responsibility onto you. The point is not to avoid lock-in at all costs but to know your exit cost before you commit, so the trade is one you chose rather than one you discover later.

How to weigh it

The practical measure is what leaving would actually take: can you export your content in a form another system can read, how much of it is in a proprietary format that needs converting, what the contract says, and how much of your team’s knowledge is specific to this tool. Those four answers size your exit cost. They feed directly into CMS TCO, where exit cost is one of the lines, and they shape any future replatforming. The migration guides show what moving between specific systems involves in practice. The commerce parallel is exit cost on a hosted storefront platform; an open, self-hosted engine like Medusa.js keeps the engine and order data yours to move.