Migrating from Vendor Agents to OpenTelemetry

Most organizations adopting OpenTelemetry aren’t starting from a blank slate — they already run a commercial APM agent like Datadog’s, Dynatrace’s, or New Relic’s, with years of dashboards, alerts, and institutional knowledge built on top of it. Migrating to OpenTelemetry means replacing the data-collection layer underneath all of that without breaking it, which is as much an organizational sequencing problem as a technical one.

Why it matters

• Avoids a hard cutover with a visibility gap. Ripping out a vendor agent and replacing it with OpenTelemetry instrumentation in one step risks a window with degraded or missing telemetry right when something could go wrong — and if something does go wrong, there’s no fallback.
• Protects existing dashboards and alerts during the transition. Alerting rules and dashboards built against vendor-specific fields don’t automatically understand OpenTelemetry semantic conventions; migrating the data source without migrating or remapping those assets silently breaks them.
• De-risks by decoupling instrumentation change from backend change. Because OpenTelemetry can export to a vendor’s backend just as well as an open-source one, teams can validate new instrumentation against the existing, trusted backend before touching where the data goes.
• Surfaces feature parity gaps early, when they’re cheapest to address. Vendor agents often include proprietary extras — deeper code-level profiling, specific security or RUM features, some auto-detected metrics — that OpenTelemetry doesn’t replicate out of the box; finding these gaps during a controlled migration is far better than discovering them during an incident.

Common migration approaches

• Run both agents in parallel (“dual shipping”). Keep the vendor agent running exactly as-is while adding OpenTelemetry instrumentation alongside it, sending its data to a separate destination or a Collector. Both data paths coexist until the OpenTelemetry side is validated, at which point the vendor agent is retired.
• Point the OpenTelemetry Collector at the existing vendor backend first. Many vendors, including Datadog, ship an exporter (and in some cases a receiver that speaks the vendor’s own submission protocol) for the OpenTelemetry Collector. This lets teams switch client-side instrumentation to OpenTelemetry SDKs while telemetry still lands in the familiar vendor UI, deferring the backend switch to a separate, later decision.
• Migrate service by service, not all at once. Starting with a single low-risk service validates the new instrumentation’s coverage and data quality before expanding, and keeps the blast radius of any instrumentation bug small.
• Use the Collector as the seam between old and new. Routing both vendor-agent-originated and OpenTelemetry-originated telemetry through a Collector gives one place to normalize attribute names, apply consistent sampling, and eventually redirect everything to a new backend with a config change rather than another wave of application redeploys.

Realistic challenges

• Feature parity is rarely 1:1. Proprietary agents often include vendor-specific instrumentation depth — automatic code-level profiling hooks, specific database driver coverage, or platform-specific auto-detection — that an equivalent open-source OpenTelemetry instrumentation library may not yet match. Audit what the current agent actually provides before assuming OpenTelemetry covers it.
• Dashboards and alerts built on vendor-specific fields need rework. A vendor agent frequently emits its own proprietary tag and metric naming rather than OpenTelemetry semantic conventions; existing queries referencing those names won’t work against OpenTelemetry-shaped data without remapping, even when it lands in the same backend.
• Sampling and cost models can shift. Vendor agents often apply their own default sampling; moving to OpenTelemetry’s SDK-level or Collector-level sampling means those decisions need to be reproduced deliberately, or ingest volume and cost can jump unexpectedly.
• Team familiarity is a real cost. Engineers who’ve built muscle memory around a vendor’s specific UI, tagging scheme, and troubleshooting workflows need time to adjust, even when the underlying data is equivalent or better.

Because feature and cost tradeoffs vary a lot by vendor, it’s worth mapping the current agent’s capabilities against OpenTelemetry’s traces, metrics, and logs coverage before committing to a timeline — the OpenTelemetry Collector’s flexibility around exporters is what makes a staged, low-risk migration path possible in the first place.