OpenTelemetry adoption means replacing proprietary Datadog, New Relic, or Dynatrace agents with a vendor-neutral instrumentation layer you control. The safest path is dual-shipping telemetry to both the old and new pipeline during a multi-week cutover, validating semantic convention parity, then retiring the proprietary agent once dashboards and alerts match.
| Dimension | Proprietary vendor agent | OpenTelemetry-based pipeline |
|---|---|---|
| Instrumentation ownership | Closed-source agent, vendor controls upgrade cadence | Open-source SDKs and Collector, you control versioning |
| Data portability | Proprietary wire format, hard to export elsewhere | OTLP standard format, portable across backends |
| Switching cost | Full re-instrumentation if you change vendors | Swap exporters only, instrumentation stays intact |
| Semantic consistency | Vendor-specific tag and attribute naming | Shared semantic conventions across services and teams |
| Multi-backend support | Usually one destination at a time | Collector can fan out to several backends simultaneously |
| Community and longevity | Tied to one company’s roadmap | CNCF graduated project with broad industry backing |
Why Vendor-Locked Agents Became a Liability
For most of the last decade, adding observability to a service meant installing a proprietary agent from Datadog, New Relic, Dynatrace, or a similar vendor. The agent auto-instrumented your frameworks, shipped data to that vendor’s backend in a private wire format, and everything worked as long as you never wanted to leave. That last clause is the problem engineering leadership eventually runs into: the agent is not just a data collector, it is a lock-in mechanism. Switching observability vendors historically meant re-instrumenting every service, rebuilding every dashboard, and retraining every on-call engineer.
OpenTelemetry changes the ownership model. Instead of a vendor’s black-box agent, you instrument once using open standard APIs and SDKs, then route the resulting telemetry through a Collector that can export to any number of backends using OTLP, the OpenTelemetry protocol. According to the Cloud Native Computing Foundation, OpenTelemetry graduated to CNCF’s highest maturity tier in May 2026, a milestone reserved for projects with broad adoption, a mature governance model, and proven production stability. The project now has contributions from over 12,000 individuals across more than 2,800 companies, and CNCF describes it as the de facto standard for telemetry instrumentation in cloud native systems.
The download numbers back that up. In the twelve months before the graduation announcement, the OpenTelemetry JavaScript API package passed 1.36 billion downloads and the Python API package passed 1.3 billion, both setting monthly records in April 2026. Organizations named in CNCF’s own materials, including Bloomberg, Capital One, and eBay, rely on OpenTelemetry for production monitoring. That scale matters for a migration decision: you are not betting on an experimental library, you are adopting the same instrumentation layer that has already displaced proprietary agents at companies running workloads far larger than most teams reading this piece will ever operate.
What OpenTelemetry Actually Replaces
It helps to be precise about what changes and what does not. OpenTelemetry does not replace your observability backend. Grafana, Datadog, New Relic, Honeycomb, and Dynatrace can all still be your dashboard and alerting layer after migration. What changes is the layer beneath that: the SDKs embedded in your application code, and the pipeline that carries traces, metrics, and logs from your services to wherever you choose to send them. A vendor agent typically bundles instrumentation and transport into one closed package. OpenTelemetry separates them into three independent pieces you can reason about on their own.
The three layers of an OpenTelemetry deployment
| Layer | Purpose | Typical components |
|---|---|---|
| Instrumentation | Generates spans, metrics, and log records inside application code | Auto-instrumentation agents, manual SDK calls, language-specific libraries |
| Collection and processing | Receives telemetry, batches it, filters it, samples it, enriches it | OpenTelemetry Collector (agent mode and gateway mode) |
| Export and storage | Sends processed telemetry to one or more analysis backends | OTLP exporters to Grafana Tempo, Honeycomb, Datadog, or self-hosted stores |
This separation is what makes a phased migration possible in the first place. You do not have to change instrumentation and backend in the same release. You can swap the transport layer while keeping instrumentation stable, or change the backend while leaving instrumentation and Collector configuration untouched. That flexibility is the whole point of the standard, and it is why treating migration as a single cutover event, rather than a staged rollout, is the most common way teams get burned.
Building a Migration Strategy That Does Not Break Production
A realistic OpenTelemetry migration runs in five stages, and skipping stages is the single biggest source of migration incidents. Rushing straight from “install the Collector” to “delete the vendor agent” removes your ability to compare old and new data side by side, which is the only way you catch instrumentation gaps before they show up as a blind spot during an incident.
Stage 1: Inventory current instrumentation
Before touching any code, catalog every service that currently ships telemetry through the proprietary agent, what data each one produces (traces, metrics, custom spans, logs), and which dashboards and alerts depend on that data. Teams that skip this step routinely discover, mid-migration, an alert tied to a vendor-specific metric name that has no OpenTelemetry equivalent yet.
Stage 2: Deploy the Collector alongside the existing agent
Install the OpenTelemetry Collector in agent mode on hosts or as a sidecar in containers, but do not remove the vendor agent yet. At this stage the Collector is simply present, typically forwarding to a gateway tier that fans out to a test backend.
Stage 3: Dual-ship telemetry during cutover
This is the stage most teams underestimate. Dual-shipping means both the proprietary agent and the OpenTelemetry pipeline send data simultaneously, to different destinations, for a defined window, usually two to six weeks depending on how many services you are migrating at once.
Figure 1: Dual-shipping architecture during OpenTelemetry cutover
During the cutover window, each instrumented service sends telemetry down two paths at once: the legacy proprietary agent continues shipping to the existing vendor backend unchanged, while an OpenTelemetry SDK or auto-instrumentation layer feeds a parallel Collector pipeline that exports to a staging destination. Both paths run concurrently so engineers can compare trace counts, latency percentiles, and error rates between the two systems before anyone touches the production alerting rules tied to the legacy agent.
The reason dual-shipping matters is simple: it gives you a live parity check. If the OpenTelemetry pipeline reports 40 percent fewer traces than the proprietary agent for the same traffic, you have found a gap in your instrumentation before it became an operational blind spot. Cutting over without this overlap window means you find the gap during the next incident, which is the worst possible time to discover missing data.
Stage 4: Validate parity, then migrate alerts and dashboards
Once trace volume, span counts, error rates, and latency distributions match between the two pipelines within an agreed tolerance, start rebuilding dashboards and alert rules against the OpenTelemetry-sourced data. Keep the vendor agent’s alerts active as a safety net until the new alerts have proven themselves through at least one real incident or a deliberate game day.
Stage 5: Decommission the vendor agent
Only after alerts and dashboards have run clean on OpenTelemetry data for a full business cycle, ideally including a peak-traffic event, should you remove the proprietary agent. Removing it early is the most common rollback trigger teams report, because it eliminates the fallback path the moment something in the new pipeline misbehaves.
Semantic Conventions: The Part Everyone Underestimates
Semantic conventions are the standardized names and structures OpenTelemetry defines for common attributes: what a database call’s attributes look like, how an HTTP span should name its status, what a Kubernetes pod attribute is called. They exist so that a dashboard built against one service’s traces works identically against another team’s traces, without a translation layer. That consistency is a major reason organizations move to the standard in the first place, but it is also where migrations quietly go wrong, because the conventions themselves are still evolving.
According to guidance from Honeycomb and the OpenTelemetry project’s own non-normative migration documentation, semantic convention migrations are rarely a clean cutover. They tend to be months of overlap where old and new attribute names coexist across your fleet, because you cannot redeploy every service simultaneously. The Collector’s schema processor exists specifically to translate between convention versions in flight, so a service still emitting an older attribute name does not silently break a dashboard built against the newer name.
In 2026, the database and messaging semantic convention groups reached stable status, and continuous profiling entered release candidate status in the first quarter, a milestone that, combined with existing trace, metric, and log support, makes OpenTelemetry the first open standard to cover all four observability signal types under one SDK, one wire protocol, and one convention layer. That is good news for long-term consistency, but it means a migration started in early 2026 and one started today may need to account for different convention baselines.
Common attribute mapping when leaving a proprietary agent
| Concept | Typical vendor-specific name | OpenTelemetry semantic convention |
|---|---|---|
| Service identity | Vendor-specific service tag (varies by product) | service.name, service.namespace |
| HTTP route outcome | Custom status bucket per vendor | http.response.status_code, span status |
| Database call | Vendor APM “db span” with proprietary fields | db.system, db.operation.name |
| Container or pod context | Vendor container tagging plugin | k8s.pod.name, k8s.namespace.name |
| Error capture | Vendor error-tracking event | exception.type, exception.message span events |
Do not attempt to remap every attribute in one pass. Prioritize the attributes your existing alerts and top dashboards actually query, migrate those first, and use the Collector’s transform and schema processors to bridge older names to newer ones while long-tail services catch up on their own schedule.
Collector Architecture: Agent, Gateway, and Hybrid Patterns
The OpenTelemetry Collector is the piece of infrastructure that makes vendor-neutral routing possible, and choosing the wrong deployment topology is a common source of avoidable cost and operational overhead. There are three common patterns.
An agent-only deployment runs a Collector instance on every host or as a sidecar per pod, each one exporting directly to your backend. This keeps network hops low and isolates blast radius per host, but it means every configuration change has to roll out fleet-wide, and sampling decisions made independently per agent cannot see the full picture of a distributed trace.
A gateway deployment adds a small, centralized tier of Collector instances that every agent-mode Collector forwards to before export. The gateway tier is where you centralize expensive operations: tail-based sampling, which needs to see an entire trace before deciding to keep or drop it, cardinality limiting, and multi-backend fan-out. Most production OpenTelemetry deployments beyond a handful of services end up needing a gateway tier specifically because tail sampling cannot function correctly when each agent only sees a fragment of a trace.
Figure 2: Agent plus gateway Collector topology
Per-host or per-pod agent Collectors handle local batching and lightweight head sampling close to the source, then forward everything to a smaller, horizontally scaled gateway tier. The gateway tier reassembles full traces, applies tail-based sampling rules such as keeping every trace that contains an error, and fans the result out to one or more backends over OTLP. This is the topology that lets a single instrumentation pass feed a proprietary vendor backend and a self-hosted backend at the same time during a dual-shipping window.
A hybrid pattern combines both: lightweight agents do local batching and basic filtering, then forward to a gateway tier that owns sampling policy centrally. This is the pattern most teams converge on once they move beyond a handful of services, because it keeps per-host resource usage low while giving the gateway tier the full-trace visibility that tail sampling and cardinality control require. If you are also working through cost tradeoffs at the sampling and retention layer once the Collector is in place, that is a distinct problem from migration itself and is covered in this deep dive on observability cost control, which picks up where a completed OpenTelemetry migration leaves off.
Validating Parity Before You Cut Over
Parity validation is the checkpoint that separates a controlled migration from a gamble. At minimum, before removing a proprietary agent, confirm that trace counts within a defined tolerance match between the two pipelines for the same traffic window, latency percentiles (p50, p95, p99) are consistent within a few milliseconds of each other, error rates match exactly since a discrepancy here usually indicates dropped spans rather than sampling variance, and every alert currently firing from the vendor agent has a working equivalent on the OpenTelemetry-sourced data, tested against a synthetic or replayed incident.
Teams instrumenting agent-based or LLM-driven systems alongside conventional services should pay particular attention here, since the tracing patterns for autonomous agent workflows differ meaningfully from request and response spans. The considerations for instrumenting those systems are covered in more depth in this guide to agent observability, and the two efforts, standard service migration and agentic instrumentation, are worth planning together rather than sequentially if your organization runs both.
Common mistake
Removing the proprietary agent as soon as the OpenTelemetry Collector starts receiving data, rather than after a validated parity window. Teams that do this lose their fallback path the moment an instrumentation gap surfaces, and the gap is usually discovered during an incident rather than during testing.
Common mistake
Treating semantic convention migration as a one-time find-and-replace across the codebase. Convention updates roll out over months, and a big-bang rename across hundreds of services is far riskier than using the Collector’s schema processor to bridge old and new names while services update on their own schedule.
Common mistake
Running tail-based sampling on per-host agent Collectors instead of a centralized gateway tier. Tail sampling needs to see a complete trace to decide whether to keep it, and a distributed trace that spans multiple hosts cannot be evaluated correctly by an agent that only observes a fragment of it.
What worked
Migrating one service tier at a time, starting with a low-traffic, non-critical service to validate the full five-stage process end to end before touching anything customer-facing. Teams that piloted the migration this way caught Collector configuration mistakes and missing instrumentation while the blast radius was small, then repeated the validated playbook against higher-traffic tiers with far fewer surprises.
What worked
Keeping the vendor agent’s dashboards and alerts live, unmodified, through the entire dual-shipping window, and only rebuilding them against OpenTelemetry data after a full business cycle of matching output. This gave on-call engineers an unbroken safety net and made the eventual cutover a non-event rather than a stressful weekend deployment.
Cost and Timeline Expectations
Migration timelines vary with fleet size, but a pattern holds across most reported case studies: instrumentation inventory and Collector deployment take two to four weeks, dual-shipping and parity validation take another four to eight weeks depending on how many services are involved and how much of the fleet you migrate concurrently, and full decommissioning of the vendor agent, including a full business cycle of clean OpenTelemetry-based alerting, adds another two to four weeks after validation completes. Organizations running dozens of services rather than hundreds tend to land at the shorter end of each range, provided instrumentation inventory was accurate from the start.
Budgeting for the migration itself is a separate conversation from the ongoing cost of running two pipelines during cutover, and from what your bill looks like on the other side. If your organization is also working through the FinOps side of this decision, the tradeoffs around dual-running costs, exporter fan-out, and eventual backend consolidation are covered in this overview of FinOps fundamentals, which is a useful companion read for whoever is signing off on the migration budget.
How Migration Connects to Broader Observability Maturity
Adopting OpenTelemetry is rarely the end goal by itself, it is usually the prerequisite for something else the organization wants: consistent distributed tracing across microservices, better model and agent monitoring in production, or the ability to apply AIOps tooling across a unified telemetry stream instead of several incompatible vendor formats. Distributed tracing in particular depends on the standard this migration establishes, since consistent trace context propagation across services is what makes cross-service debugging possible in the first place, a topic covered directly in this guide to distributed tracing for microservices debugging.
Teams running machine learning workloads in production also benefit from a completed OpenTelemetry migration, since a unified telemetry pipeline makes it far easier to correlate model behavior with the infrastructure and request context around it, a connection explored further in this piece on model monitoring in production. And once telemetry is flowing through a standard, vendor-neutral pipeline, automated correlation and anomaly detection tooling, the subject of this overview of AIOps, becomes meaningfully easier to deploy, because it can rely on consistent attribute names across every service rather than reconciling several vendor-specific schemas first.
Glossary
- OpenTelemetry (OTel)
- A CNCF-graduated, vendor-neutral open standard and set of APIs, SDKs, and tools for generating, collecting, and exporting traces, metrics, and logs.
- OTLP
- The OpenTelemetry Protocol, the standard wire format used to transmit telemetry data between instrumented applications, Collectors, and backends.
- Collector
- A standalone process that receives, processes (batches, filters, samples), and exports telemetry data to one or more destinations.
- Dual-shipping
- Running both the legacy proprietary agent and the new OpenTelemetry pipeline simultaneously during a cutover window to validate parity before decommissioning the old system.
- Semantic conventions
- Standardized naming and structure rules for telemetry attributes, ensuring consistent meaning across services, teams, and backends.
- Tail-based sampling
- A sampling strategy that waits until a full trace is assembled before deciding whether to retain it, typically prioritizing traces with errors or high latency.
- Gateway Collector
- A centralized tier of Collector instances that receives forwarded telemetry from agent-mode Collectors, enabling operations like tail sampling that require full-trace visibility.
- Schema processor
- A Collector component that translates telemetry between different semantic convention versions, allowing services on different convention baselines to coexist during migration.
Key Takeaways
- OpenTelemetry migration separates instrumentation, collection, and export into independent layers, letting you change one without touching the others.
- Dual-shipping to both the proprietary agent and the OpenTelemetry pipeline for several weeks is the safest way to validate parity before cutover.
- Semantic convention migration is a months-long, phased process, not a one-time rename, and the Collector’s schema processor exists to bridge convention versions during that overlap.
- Tail-based sampling requires a centralized gateway Collector tier, since agent-mode Collectors only see fragments of a distributed trace.
- Never decommission the vendor agent until dashboards, alerts, and trace parity have held steady through a full business cycle, ideally including a peak-traffic event.
- OpenTelemetry reached CNCF’s highest maturity tier in 2026, with over 12,000 contributors and adoption at organizations including Bloomberg, Capital One, and eBay.
- A completed OpenTelemetry migration is usually the prerequisite for downstream goals like consistent distributed tracing, AIOps tooling, and unified model monitoring.
FAQs
What is the safest way to migrate from a proprietary observability agent to OpenTelemetry?
Deploy the OpenTelemetry Collector alongside the existing vendor agent and dual-ship telemetry to both pipelines for several weeks. Validate that trace counts, latency percentiles, and error rates match before rebuilding alerts and dashboards, and only remove the vendor agent after a full business cycle of clean output.
How long does an OpenTelemetry migration typically take?
Most migrations run ten to sixteen weeks end to end: two to four weeks for inventory and Collector deployment, four to eight weeks for dual-shipping and parity validation, and two to four weeks for final decommissioning, though fleet size and service count can extend this considerably.
Do I need to replace my observability backend to adopt OpenTelemetry?
No. OpenTelemetry replaces the instrumentation and transport layer, not the backend. You can continue sending data to Datadog, New Relic, Dynatrace, Grafana, or Honeycomb, the difference is that the data now arrives over the open OTLP standard instead of a proprietary agent format.
What are semantic conventions and why do they matter during migration?
Semantic conventions are OpenTelemetry’s standardized names for common telemetry attributes, such as how a database call or HTTP status is labeled. They matter because dashboards and alerts depend on consistent attribute names, and convention versions evolve, so migrations need a bridging strategy rather than a one-time rename.
Why does tail-based sampling require a gateway Collector instead of per-host agents?
Tail-based sampling decides whether to keep a trace only after the entire trace is assembled. A per-host agent Collector typically sees only the spans generated on that host, so it cannot evaluate a distributed trace correctly. A centralized gateway tier receives forwarded spans from all agents and can reassemble the full trace before applying sampling policy.
What is the biggest risk of migrating too quickly?
The biggest risk is decommissioning the vendor agent before instrumentation gaps surface. Without a dual-shipping and parity validation window, missing spans or misconfigured exporters are usually discovered during a production incident rather than during planned testing, when there is no fallback pipeline left.
Can OpenTelemetry instrumentation feed multiple backends at once?
Yes. The Collector supports fanning out processed telemetry to several exporters simultaneously, which is exactly what makes dual-shipping during migration possible, and also allows organizations to route different signal types to different specialized backends long term.
Is OpenTelemetry mature enough for large-scale production use in 2026?
Yes. OpenTelemetry graduated to CNCF’s highest maturity tier in May 2026, with contributions from more than 12,000 individuals across 2,800-plus companies, and its JavaScript and Python API packages each passed a billion downloads in the preceding twelve months, indicating broad production use at significant scale.
References
- Cloud Native Computing Foundation, “Cloud Native Computing Foundation Announces OpenTelemetry’s Graduation, Solidifying Status as the De Facto Observability Standard,” May 2026.
- OpenTelemetry Project Blog, “OpenTelemetry is a CNCF Graduated Project,” 2026.
- InfoQ, “OpenTelemetry Graduates to CNCF’s Highest Maturity Level,” 2026.
- Honeycomb, “Managing OpenTelemetry Semantic Convention Migrations With the Collector.”
- Honeycomb, “Making Semantic Conventions Work for You With OpenTelemetry Weaver.”
- OpenTelemetry Documentation, “Semantic Conventions: Non-Normative Migration Guidance.”
- Cloud Native Computing Foundation, “OpenTelemetry” project page, cncf.io.
