Vendor lock-in is when the cost of leaving a product, measured in money, engineering time, and operational risk, gets high enough that you stay even after the product stops being the right choice. The lock-in rarely comes from a contract clause. It builds up quietly, one dependency at a time, until switching means rewriting code, retraining people, and reformatting data all at once.
This article explains how lock-in actually forms, how to tell whether it has already happened to you, and what genuinely prevents it. The examples lean toward observability because that's where the mechanics are especially easy to see, but the pattern is the same everywhere.
How lock-in actually forms
The word "lock-in" makes it sound like a decision you make once, but that's not how it works. You almost never sign up for it. You accumulate it.
It starts with a reasonable choice. You pick a tool because it solves today's problem well, and then you wire your systems around it. Every integration you build, every workflow your team learns, and every piece of data you store in the vendor's format raises the cost of ever leaving. None of these steps feels like a trap on its own. Added up over a couple of years, they become a wall.
The mechanics come down to a few concrete sources of switching cost:
- Proprietary data formats. Once your data is stored in a shape only one vendor understands, moving it means transforming or re-collecting it. Exporting the raw bytes doesn't help if nothing else can read them.
- Proprietary APIs and interfaces. When your automation, scripts, and internal tooling call a vendor-specific API, switching means rewriting all of it against a different API that works differently.
- Learned skills. If your engineers write queries in a query language that only works with one product, that expertise doesn't transfer. You've turned a portable skill into a dependency on a single company.
- Deep integration. The more central a tool is to daily operations, the more a migration risks breaking something important, so the more you avoid attempting one.
The migration project is only part of the cost. The bigger one is the leverage you lose in the meantime. A vendor that knows you can't realistically leave has little reason to keep prices competitive or to prioritize the features you need.
What lock-in looks like in observability
Observability is a good place to watch this happen, because the lock-in hides inside a step most teams treat as boring plumbing: instrumentation.
When you instrument your application with a proprietary agent or SDK, from Datadog, New Relic, Dynatrace, or any similar vendor, that instrumentation code speaks a format only that vendor's backend understands. Your traces, metrics, and logs are shaped for one destination. The instrumentation calls are scattered across every service you run.
That's fine when you have three services. The problem is that the cost of undoing it grows with every service you add. Switching backends later means going back into each service and rewriting instrumentation, then re-validating that you didn't lose signal along the way. What was a trivial change at three services becomes a full engineering quarter at thirty. By the time the bills or the feature gaps make you want to leave, leaving is exactly when it's most expensive.
On top of the instrumentation, the same accumulation happens with the pieces built around it: dashboards that only render in one platform, alerts defined in a proprietary syntax, and CI/CD pipelines that create monitors through a vendor-specific API. Rebuilding hundreds of dashboards and alerts from scratch is its own migration, separate from the data.
How to tell if you're already locked in
You don't need a formal audit. Three questions will tell you where you stand.
First, is your internal tooling built on a vendor's proprietary API? Custom Slack integrations, automated runbooks, and pipelines that provision monitors through a closed API all have to be rewritten if you switch.
Second, do your engineers write queries in a syntax that only works with one product? If it isn't something portable like PromQL or SQL, that knowledge evaporates the moment you change tools.
Third, and this is the honest one: can you answer "how long would it take us to switch?" with a real number? If the answer is "months" or "I genuinely don't know," you're locked in, whatever the contract says.
How open standards break the pattern
The fix for lock-in is to decouple the parts that used to be welded together. In observability, the weld is between how you collect telemetry and where you store it. Break that, and switching backends stops being a code change.
This is what OpenTelemetry does. It's a vendor-neutral standard for collecting traces, metrics, and logs, governed by the Cloud Native Computing Foundation (CNCF), and it defines a wire format called the OpenTelemetry Protocol (OTLP) that any compatible backend can ingest. You instrument your code once, against the open standard, and your instrumentation no longer names a specific vendor.
The payoff shows up when you actually want to move. With OpenTelemetry, changing backends is a configuration change in your Collector, not a rewrite in your application. Here's an exporter block sending data to one backend:
12345exporters:otlp:endpoint: https://ingress.eu-west-1.aws.dash0.com:4317headers:Authorization: "Bearer ${DASH0_AUTH_TOKEN}"
To switch destinations, you change the endpoint and credentials. That's it. The application code that produces the telemetry never changes, because it was never tied to the destination in the first place. Instrument once, send anywhere.
This is also why adopting OpenTelemetry pays off even if you have no plans to leave your current vendor. Portability is insurance. When your instrumentation is vendor-neutral, you're always one config change away from switching, which is the thing that keeps a vendor honest.
Common pitfalls
The traps here are subtle, because the whole point of lock-in is that it doesn't announce itself.
"OpenTelemetry-compatible" is not the same as OpenTelemetry-native. Many proprietary platforms will happily ingest OTLP, and they'll say so in the sales deck. The catch is that full functionality, the good dashboards and the richer correlation, often still depends on their proprietary agent. You get just enough OTel support to feel safe while the features that matter quietly pull you back onto the proprietary path. Check whether the vendor's own product is built on OpenTelemetry, or whether OTel is a compatibility layer bolted onto a closed core. The gap between supporting OpenTelemetry and being built on it is exactly where lock-in survives an OTel adoption.
Some vendors charge a premium for portability. A number of platforms classify OpenTelemetry metrics as "custom metrics" and bill them at a higher rate than their native metrics. You end up paying more for the privilege of not being locked in, which is backwards from how standards are supposed to work. Model your real costs against your actual telemetry volume before assuming OTel support makes a platform affordable.
Waiting until it hurts is waiting too long. The re-instrumentation cost is close to zero when your estate is small and rises with every service you add. Teams routinely defer the move because "we'll standardize later," and later arrives after the cost has already ballooned. If you're going to standardize on an open layer, the cheapest day to do it is the earliest one.
Final thoughts
Vendor lock-in isn't a reason to avoid commercial tools. Plenty of them are excellent, and self-hosting everything has its own costs. The goal is to keep the exit cheap: own your instrumentation through an open standard, keep your queries in a portable language, and know your switching cost before you need it. Do that, and you can choose vendors on merit rather than on how expensive they've made it to leave.
Dash0 is built the other way around from the platforms that create this problem. It's an OpenTelemetry-native observability platform, so your logs, metrics, and distributed traces arrive over OTLP and stay in open formats, queryable with PromQL. There's no proprietary agent locking your data in. Dash0 collects telemetry through open, OpenTelemetry-based components, so nothing you deploy ties your instrumentation to Dash0.
If you want the full picture of how open standards keep your options open, our write-up on avoiding vendor lock-in with open observability standards goes deeper on the collection, dashboarding, and migration side.
Start a free trial to send your existing OpenTelemetry data to Dash0 and see it in one view. No re-instrumentation, no credit card required.