Cloud Lock-In: What It Actually Costs to Switch
Every managed service you adopt is a dependency you'll pay a switching cost on later. The deeper your code couples to proprietary APIs, the higher that cost becomes — and most teams don't see it until they're already stuck.
1:25
Transcript
A team wanted to switch cloud providers. The estimate came back: eight months, three engineers, full rewrite of the auth and data layer. That's what lock-in actually costs. Not a vendor problem — an architecture decision made two years earlier.
Here's how it happens. Your app starts using one managed auth service. Then a proprietary database. Then a managed queue. Then an ML API. Each one is a reasonable choice on its own. But together, they form a dependency web. Every one of those services has its own proprietary SDK, its own data format, its own way of doing things. Your code grows around all of it. And the deeper that coupling goes, the harder it is to extract.
The tradeoffs are real on both sides. Low lock-in means open standards, more infra work upfront, but you can switch providers in weeks. High lock-in gives you less dev time in the short term — managed services are genuinely convenient — but migration costs months. The balanced approach uses proprietary services only where they're commodities: storage, CDN, email. Keep core logic on open standards. Over three years, that's the best total cost.