If you’ve been running Datadog, Dynatrace, or New Relic for a few years, your team is locked in — agents, proprietary data formats, pricing models that scale painfully as you grow. The more you build on those platforms, the harder it gets to leave. OpenTelemetry’s OTLP is designed to break that coupling. The promise is “collect once, route to any backend.” That promise is real — but there are limits worth understanding before you commit. Here’s what OTLP actually delivers in 2026, where lock-in persists anyway, and what it costs to switch. If you want to understand how OTLP fits into a full migration strategy, the Enterprise OpenTelemetry Migration Playbook lays out each phase — from instrumentation audit through backend selection and security hardening.
What Is the OTLP Protocol and Why Does It Matter More Than “OpenTelemetry Support”?
OTLP is a binary wire protocol. It runs gRPC/Protobuf on port 4317 for high-throughput production environments, and HTTP/JSON on port 4318 for restrictive networks and browsers. The current stable spec is OTLP 1.10.0, covering traces, metrics, and logs.
The phrase you need to watch for when evaluating vendors is “native OTLP ingestion” — not just “OpenTelemetry support.” Vendors love the second phrase because it’s vague. Native OTLP ingestion means the backend accepts raw OTLP at its ingest endpoint, no translation layer in between. A translation layer introduces fidelity loss, attribute mapping errors, and latency you didn’t need. When a vendor says they “support OpenTelemetry,” ask the direct question: does your ingest endpoint accept raw OTLP?
What Does “Collect Once, Route Anywhere” Actually Mean in Practice?
The OTel Collector is where this promise gets real. Applications send telemetry to the Collector — it handles ingestion, processing (filtering, sampling, enrichment), and exports to multiple backends at the same time. Routing decisions live in infrastructure config, not in your application code. A single Collector pipeline can push to Datadog for production alerting and SigNoz for cost-controlled analysis simultaneously. Switching tracing backends can take as little as one config line change and zero application changes.
Airbnb switched to OTLP and retained backend flexibility — they use a dual-write approach, emitting StatsD for their existing pipeline and OTLP for the new OTel Collector at the same time. That system now processes over 100 million samples per second. Dual-write lets you run both pipelines side by side until you’re confident enough to cut over.
That said, routing to any backend works at the transport layer. At the semantic layer — how backends interpret what your telemetry data actually means — you don’t always get consistency across signal types. That’s the next thing to get your head around.
Which Major Vendors Support Native OTLP Ingestion in 2026?
Datadog gives you multiple paths: the Datadog Exporter, OTLP ingestion in the Datadog Agent, and direct OTLP API endpoints (Preview). It also ships DDOT — the Datadog Distribution of OTel Collector — with Datadog-specific extensions including Live Container Monitoring.
New Relic launched APM hybrid agents in February 2026 — emitting both proprietary signals and OTLP at once, so you can adopt incrementally without a flag-day cut-over. They also offer NRDOT with an Adaptive Telemetry Processor for filtering signal noise.
Dynatrace is more often a migration source than an OTel-native destination. OTLP ingestion exists, but OneAgent is still the primary lock-in mechanism.
Honeycomb is the one to call if you’re in a regulated industry. Honeycomb Private Cloud launched in January 2026 on AWS and meets HIPAA, PCI DSS, SOC 2 Type II, and CSA STAR Level 1. Natively accepts OTLP. If you’re in HealthTech or FinTech and need observability with regulatory certifications, this is the primary option.
Google Cloud Managed OpenTelemetry offers native OTel support at the GCP infrastructure layer — the natural starting point if your team is already running on GCP.
SigNoz is the open-source, self-hosted option. OTel-native, ClickHouse storage, and Thoughtworks placed it at Trial in Volume 34 of the Technology Radar (April 2026) — “a strong self-hosted alternative to platforms such as Datadog.”
ClickStack is also OTel-native with ClickHouse storage, placed at Assess on Thoughtworks Radar Vol. 34. Its standout feature is sub-second, high-cardinality queries across large data volumes.
Where Does Lock-In Persist Even When OTLP Is in Use?
OTLP solves the transport layer. It doesn’t fully solve the semantic layer — and that’s where the residual lock-in sits.
Semantic conventions are OpenTelemetry’s standardised attribute naming schemas: they define what your telemetry data means. http.request.method, db.system, net.peer.name — these tell a backend how to interpret an incoming span. When your instrumentation and your backend agree on those names, switching backends is clean. When they don’t, your dashboards and alerts break.
Stability is uneven. HTTP, gRPC, and database conventions are stable — they transfer cleanly between backends. GenAI and LLM conventions, messaging frameworks, and cloud-provider-specific attributes are still experimental in 2026. If you’re running AI workloads, portability is partial until those conventions mature.
There’s also a practical forcing function worth noting: CVE-2026-41078 is a DoS vulnerability in OpenTelemetry.Exporter.Jaeger — no patch available, you need to migrate to OTLP. Teams doing that as a security fix run straight into the semantic convention mapping challenge. The CVE-2026-41078 fix requires migrating to the OTLP exporter — and doing so simultaneously delivers the vendor portability that OTLP provides.
The short version: audit your specific convention dependencies before assuming the portability promise is fully redeemable for your stack.
Vanilla OTel Collector vs Vendor Distributions: What Is the Real Trade-Off?
The Elastic 2026 observability survey of 500+ IT decision-makers found vendor Collector distributions grew from 44% to 60% of all OTel Collector deployments year over year. Practitioners are choosing operational convenience over independence, and they’re probably making the right call for their situation.
Every vendor distribution is built from the same OTel Collector codebase with vendor-specific components and support added on top. DDOT, NRDOT, EDOT (Elastic), ADOT (AWS), Grafana Alloy — they all have their flavour. Vendor distributions are easier to set up, come with SLA-backed support, and are optimised for their backend. Upstream gives you better portability and no vendor dependency on Collector patches.
Running a vendor distribution doesn’t lock you into that backend — all distributions speak OTLP. The soft dependency is operational: vendor-specific extensions may not have vanilla upstream equivalents, so switching Collector distributions when you change backends adds engineering work on top of the backend migration.
There’s a third path if you want to go further: build a custom Collector distribution using the OTel Collector Builder (ocb). You get exactly the components you need, compiled into a single binary, with reduced dependency surface and a smaller attack surface. Adobe’s custom OTel Collector distribution illustrates this trade-off at enterprise scale.
SigNoz and ClickStack: What Does the No-Proprietary-Backend Option Look Like?
If the goal is to exit proprietary APM entirely — not just bolt OTLP onto it — the OTel-native open-source backends are where you want to look.
SigNoz is self-hosted, OTel-native, ClickHouse storage. Thoughtworks placed it at Trial in Volume 34 (April 2026) — “a strong self-hosted alternative to platforms such as Datadog.” Trial means their engineers have used it in the field. That’s the strongest recommendation short of Adopt, and it carries real weight.
ClickStack is also OTel-native with ClickHouse storage, sitting at Assess on the same Radar. Its standout is sub-second, high-cardinality query performance — relevant if your metric label sets are dense.
With a vanilla OTel Collector and a self-hosted backend, the only proprietary dependency is the cloud infrastructure it runs on. Switching backends becomes a Collector reconfiguration, not an instrumentation overhaul. The backend selection phase of the migration playbook has the evaluation criteria if you’re working through that decision.
On cost: the Elastic survey confirms cost drives OTel evaluation — but no independent source provides structured numbers at specific company sizes. Model it yourself: Datadog licensing at your current metrics volume versus self-hosting plus engineering overhead. SigNoz on ClickHouse requires infrastructure management and tuning. That’s real cost. Factor it in honestly.
What Does Switching Away From a Proprietary APM Actually Cost?
New Relic coined “migration tax” to describe what stops teams from making this move: configuration rewrites, dashboard rebuilds, alert reconfiguration, agent replacement, and team retraining. Their February 2026 hybrid agents are a direct response — emitting proprietary signals and OTLP at the same time so you can adopt incrementally, no flag-day cut-over required.
The realistic migration structure for a mid-size team runs through instrumentation audit, dual-write transition, Collector topology design, dashboard rebuild, alert migration, and team training — weeks to months, depending on how much dashboard debt you’ve accumulated. Deductive AI escaped Datadog in under 48 hours — greenfield instrumentation, minimal dashboard debt. That’s the outlier, not the template. Don’t plan your migration assuming you’ll be that lucky.
On TCO: 49% of organisations with OTel in production cite cost as a key driver, but actual numbers are absent from any independent source. Proprietary APM licensing scales with your growth; self-hosted OTel-native infrastructure cost is more predictable. Year one costs more — migration overhead — the payoff compounds as your team and traffic grow. The Enterprise Migration Playbook covers the full strategy alongside how OTLP enabled a backend switch at production scale.
Frequently Asked Questions
What is the OTLP protocol?
OTLP (OpenTelemetry Protocol) is a vendor-neutral binary protocol that standardises how traces, metrics, and logs move between instrumented applications, OTel Collectors, and observability backends. It uses gRPC (port 4317) for high-throughput environments and HTTP/JSON (port 4318) for browsers and restrictive networks. Current stable spec: OTLP 1.10.0.
Does OpenTelemetry actually eliminate vendor lock-in?
OTLP eliminates protocol-level lock-in — switching backends requires no application code changes. Semantic convention gaps create residual lock-in at the interpretation layer: dashboards built on experimental conventions may not transfer cleanly. Meaningful portability, not perfect portability — the gap shrinks as conventions mature.
What are semantic conventions and why do they matter for vendor portability?
Semantic conventions are OpenTelemetry’s standardised attribute naming schemas — http.request.method, db.system, gen_ai.usage.input_tokens — so backends interpret data consistently. Stable conventions (HTTP, gRPC, database) transfer cleanly. Experimental conventions (GenAI, messaging) may be absent or implemented differently by different backends — which means rebuilding dashboards when you switch, even with OTLP in use.
Should I run the vanilla OTel Collector or a vendor distribution like DDOT or NRDOT?
Elastic’s 2026 survey shows vendor distributions grew from 44% to 60% of deployments. For single-vendor deployments requiring vendor support, use their distribution. For multi-backend routing or open-source backends, use upstream. Vendor distributions don’t lock you into a backend — routing still works — but they create a soft dependency on that vendor’s Collector maintenance.
What is the “migration tax” in OpenTelemetry adoption?
Migration tax is New Relic’s term for the engineering toil of moving from a proprietary APM to OTel: configuration rewrites, dashboard rebuilds, alert reconfiguration, agent replacement, and team retraining. New Relic’s February 2026 hybrid agents directly reduce this by emitting both proprietary signals and OTLP simultaneously — incremental adoption, no flag-day cut-over.
What is SigNoz and is it a credible alternative to Datadog?
SigNoz is an open-source, self-hosted, OTel-native observability platform using ClickHouse for storage. Thoughtworks Technology Radar Vol. 34 placed it at Trial — “a strong self-hosted alternative to platforms such as Datadog.” Self-hosting requires infrastructure management and ClickHouse tuning; factor that into any cost comparison.
How hard is it to migrate from Datadog to an open-source observability stack using OTel?
The difficulty is in your existing dashboard and alert debt, not the instrumentation. OTLP removes the need to replace application code; the Collector handles routing. Realistic migration involves instrumentation audit, dual-write transition, backend setup, dashboard rebuild, alert migration, and team training — weeks to months depending on dashboard debt.
What compliance certifications does Honeycomb offer for OTel-native observability?
Honeycomb Private Cloud (January 2026, AWS) provides GDPR, HIPAA, PCI DSS, SOC 2 Type II, and CSA STAR Level 1 compliance across U.S., European, and APAC regions. Honeycomb natively accepts OTLP — the primary option for HealthTech and FinTech teams needing OTel-native observability with regulatory certifications.
Does switching to OpenTelemetry actually save money compared to Datadog or Dynatrace?
No structured, independently verified TCO comparison exists at any specific company size. 49% of production OTel users cite cost as a key driver — but actual numbers are absent. Model it: Datadog/Dynatrace licensing at your current metrics volume versus self-hosting infrastructure cost plus engineering overhead. Year-one migration cost is typically higher; proprietary APM licensing scales with growth while self-hosted cost is more predictable.
What is ClickStack and how does it compare to SigNoz?
ClickStack is an OTel-native observability platform placed at Assess on Thoughtworks Technology Radar Vol. 34 — one step behind SigNoz’s Trial placement. Both are OTel-native with ClickHouse-based storage. ClickStack’s differentiation is sub-second, high-cardinality query performance — relevant for organisations with dense metric label sets.
Why is the Jaeger exporter deprecated and what does it have to do with OTLP?
CVE-2026-41078 is a DoS vulnerability in OpenTelemetry.Exporter.Jaeger. No patch — the exporter was deprecated in 2023. Migrate to the OTLP exporter. This CVE remediation simultaneously moves teams onto the vendor-portable transport — a security fix that also improves observability architecture.
Can I use the Datadog OTel Collector distribution (DDOT) and still switch backends later?
Yes. DDOT is a pre-configured OTel Collector, not a proprietary agent — switching the exporter destination is a Collector config change. The soft dependency is operational: DDOT includes Datadog-specific extensions that may not have vanilla upstream equivalents. Switching is feasible but adds Collector configuration migration work alongside the backend migration.
