Vendor lock-in is a situation in which switching from one provider to another is so costly, risky or slow that customers effectively cannot leave. In observability, lock-in typically comes from proprietary agents and instrumentation, closed data formats, vendor-specific query languages and dashboards, data that cannot be exported, and contract terms.
What is vendor lock-in?
Vendor lock-in describes a dependency on a single supplier that is expensive to undo. The cost of leaving, often called switching cost, includes engineering effort, migration risk, lost history, retraining and contract penalties. Lock-in is not always bad; deep integration can bring real benefits. It becomes a problem when it removes your negotiating position, blocks better technology or makes you unable to meet regulatory requirements such as data residency or exit plans.
Observability is particularly prone to lock-in because telemetry touches every service. Instrumentation lives in application code and deployment manifests, alerts encode years of operational knowledge, and dashboards are how teams think about their systems.
Where lock-in hides in observability
| Layer | Typical lock-in | Open alternative |
|---|---|---|
| Instrumentation | Proprietary SDKs and agents with vendor-specific APIs in code | OpenTelemetry APIs, SDKs and zero-code agents |
| Transport | Closed wire protocols and ingestion endpoints | OTLP, Prometheus remote write |
| Collection pipeline | Vendor-only forwarders and processing rules | OpenTelemetry Collector |
| Data model | Custom attribute names and metric types | Semantic conventions |
| Query and alerting | Proprietary query languages only | PromQL, SQL |
| Stored data | No bulk export, or export only in proprietary formats | Export in open formats, own storage account |
| Commercial | Multi-year commitments, overage penalties, bundled pricing | Usage-based terms, clear exit clauses |
Why it matters
- Cost control: without a credible alternative, price increases or changes to the pricing model are hard to push back on.
- Technology choice: when instrumentation is tied to one vendor, adopting a better tool for one signal, such as profiling or LLM monitoring, means instrumenting twice.
- Regulation: financial regulations such as DORA require exit strategies for critical ICT third-party services, and GDPR obligations may require moving data to another region or provider.
- Resilience: if a single vendor has an outage or changes direction, you need a way to keep visibility.
Data gravity
The longer you use a platform, the more history accumulates in it: months of metrics for capacity planning, logs needed for audits, traces linked to past incidents. This data gravity is a quiet form of lock-in. Even when instrumentation is portable, leaving means either losing the history, running two systems in parallel until old data ages out, or paying for a bulk export. Plan for it early by knowing which data you really need to keep, in which format, and for how long, ideally aligned with your retention policy.
How OpenTelemetry reduces lock-in
OpenTelemetry is the most effective lever against observability lock-in because it standardizes the most expensive layer to change: instrumentation. Code uses vendor-neutral APIs, data travels over OTLP, and the Collector decides where it goes. Switching or adding a backend becomes a configuration change rather than a code change:
exporters:
otlphttp/current:
endpoint: https://otlp.current-vendor.example
otlphttp/candidate:
endpoint: https://otlp.candidate.example
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlphttp/current, otlphttp/candidate]With this illustrative configuration, the same traces flow to two backends in parallel, which makes an evaluation or a migration low risk. Note that OpenTelemetry does not remove every form of lock-in: dashboards, alert rules and stored history still need a plan.
Portable dashboards and alerts
Dashboards and alert rules are where much operational knowledge lives, and they are the part teams most often underestimate during a migration. Keep them as code in version control, prefer widely supported query languages for the alerts that page people, and document the intent of each alert, not only its expression. An alert described as "page when more than 1 percent of checkout requests fail for 10 minutes" can be rebuilt on any platform; a 40-line proprietary query without explanation cannot. Open initiatives for dashboard definitions exist, but none is universal yet, so the description of intent remains your best insurance.
Best practices
- Instrument with OpenTelemetry, including for new services, even if your current vendor offers its own agent.
- Put a Collector layer in between so routing, filtering and enrichment are under your control.
- Prefer open query languages for alerts that matter, and keep alert and dashboard definitions in Git as code.
- Verify data export before signing: format, completeness, speed and cost of bulk export.
- Write an exit plan with owners, steps and timelines, and test parts of it, for example by dual-shipping a subset of services.
- Check contract terms for commitment periods, renewal clauses and data deletion after termination.
Common mistakes
- Assuming that "supports OpenTelemetry" means no lock-in, while dashboards and alerts are built only in a proprietary language.
- Mixing vendor SDK calls into business logic, which makes later migration a code refactoring project.
- Ignoring stored history: if data cannot be exported, switching means losing months of trends.
How Obseria helps
Obseria is OpenTelemetry-native: it ingests OTLP and works with standard SDKs and Collectors, so you do not need proprietary instrumentation. You can export your data via OTLP at any time, query with PromQL and SQL in addition to OQL, and choose data residency in the EU, the UK or your own cloud account (BYOC). Pricing is usage-based per signal, with no host or seat licenses. Learn more on OpenTelemetry in Obseria.
