The Real Cost of Vendor Lock-In (and When to Actually Migrate)

Switching cost is engineering time and money. Switching risk is what happens if you can't switch when you need to, whether that's a price hike, an outage pattern you can't accept, or a compliance gap the vendor won't close.

A dependency with high switching cost but low risk, a well-run managed database, say, is usually fine to keep. High risk with high cost is the combination that deserves an actual exit plan before you need one, not after the vendor has already announced the change that forces your hand.

If a vendor's own reliability is worse than the availability target you've promised your customers, their downtime is quietly eating your own uptime budget every time they have an incident, no matter how well your side of the system performs¹.

That's a concrete way to test whether a dependency is a risk: pull their public status history for the last year and compare it against what you've actually committed to. A vendor with a spotless record is a low-risk dependency even with a high switching cost. A vendor with a rough quarter behind them deserves a closer look, whatever the pricing looks like.

Data egress fees, proprietary query languages, and integrations built specifically around one vendor's quirks all add to exit cost quietly, over years, without anyone deciding to accept that risk on purpose. Say your team builds a dozen internal tools directly against a vendor's proprietary API over two years; none of those individual integrations felt like a big decision, but together they're now the reason leaving would take months, not weeks.

Ask, for any new core dependency you adopt: if we had to leave in eighteen months, what would that actually take? If no one can answer, that's the gap, and it's worth closing before the dependency gets deeper.

Migrating off a working dependency has its own cost and its own risk: a migration is itself an outage risk, and the engineering time spent moving off a vendor is time not spent on the product.

If the vendor is reliable, the price is fair, and the risk of needing to leave is genuinely low, the right move is often to document the exit plan and not execute it yet, rather than migrate preemptively out of anxiety about lock-in in general. Lock-in itself isn't the problem. An exit you can't execute when you actually need to is the problem.

For example, a small team runs its primary database on a reliable managed service at a fair price. Leaving would take months, but the vendor's status history is clean and no customer requirement is pending. The sensible move is a one-page exit note naming the alternative, the rough steps, and the likely timeline, then a check at the next review. Compare that with a vendor whose reliability keeps slipping below your own promise: there, a live migration plan is justified now. The difference is not how locked in you are, it is how likely you are to need the exit soon.

The worst time to evaluate a vendor dependency is during the outage or price hike that made it urgent. Put a standing review on the calendar, once or twice a year, for your short list of high-risk dependencies, so the evaluation happens on your terms.

That review doesn't need to be exhaustive. A short check against the same two questions, switching cost and switching risk, is usually enough to catch a dependency that's quietly drifted from fine to risky since the last time anyone looked.

Bring whoever owns the vendor relationship into that review, not just engineering. Pricing changes and contract terms often reach a founder or a finance lead before they reach the engineers who'd actually have to execute a migration, and the gap between those two groups knowing is where lock-in risk quietly compounds. A fifteen-minute conversation once or twice a year closes that gap far more reliably than hoping someone mentions it in passing.

Use these questions in a standing review of each high-risk vendor:

• Would leaving be expensive, risky, or both? High cost combined with high risk deserves a written exit plan before you need one.
• Is the vendor's public reliability record worse than the availability target you promised your own customers?
• Do egress fees, proprietary query languages, or vendor-specific integrations make an exit harder than it looked at adoption?
• If you had to leave in eighteen months, can anyone on the team say what that would take?
• Has whoever owns the contract, such as a founder or finance lead, joined the review alongside engineering?