People throw around "vendor lock-in" like it's a binary — you either have it or you don't. That framing is why the conversation usually goes nowhere. Lock-in isn't one thing. It's four different things stacked on top of each other, each with a wildly different cost to unwind, and once you separate them you can actually decide what's worth worrying about.
The four layers
- Data. Proprietary formats, and — the real killer — egress fees to get it back out. Cheap to design around early, brutally expensive to fix late.
- Platform. The vendor-specific managed stuff: serverless, managed databases, IAM, observability. This is where the deep lock-in lives, because these services are genuinely good and have no clean equivalent next door.
- Contract. Renewal clauses, termination terms, committed-spend discounts that quietly jack up your switching cost while feeling like a deal.
- Operations. Your team's muscle memory — the tooling, the runbooks, the way everyone thinks. The least visible layer, and usually the stickiest.
If you want to know where you're most exposed, it's almost always managed databases, serverless, IAM, and observability. Those deserve a real decision, not a default.
Lock-in isn't automatically a problem
Here's the part people skip: lock-in only matters when it traps regulated data, kills your pricing leverage, or makes leaving hideously expensive. A managed service that saves your team a month of work and is easy enough to swap later? That's a good trade. Take the deal.
The goal was never zero lock-in. It's knowing your number and controlling it where it counts. Which is why step one is boring and unglamorous: audit each layer, put a figure on the exit, set a date to revisit. (We built a Vendor Lock-In Auditor that spits out a portability score and an exit-cost estimate, so it's an actual number instead of a vibe.)
Where Terraform earns its keep — and where it's oversold
Infrastructure-as-code (Terraform, Pulumi) is the highest-leverage move you can make on the operations and platform layers. Declarative, version-controlled infra buys you:
- An environment that's documented and reproducible instead of click-configured and half-remembered.
- Your vendor dependencies sitting right there in the code, visible — you can literally read your lock-in.
- The ability to stand up equivalent resources elsewhere from one workflow, which is what makes a real exit or multi-cloud plan more than a slide.
Now the honest bit: Terraform does not make a proprietary managed service portable. It makes the exit auditable and cheaper. The platform-layer dependency itself is still a design choice you make service by service. Anyone selling you Terraform as a lock-in cure is overselling.
(If you're standardising from scratch, our Terraform Blueprint Generator hands you a production-ready, portable-by-default baseline in seconds.)
The playbook I'd actually follow
- Audit the four layers, price the exit.
- Codify infra in Terraform so the dependencies are explicit.
- Decide on purpose for each high-lock-in service: take it (and write down the risk + a portability plan) or skip it.
- Negotiate egress caps and deconversion help into the contract — before you're committed, when you still have leverage.
- Revisit on a schedule, because lock-in creeps while you're not looking.
Selective portability beats both religions. Keep the managed-service speed where it's worth it; keep your options open where it isn't.