What OTel Can (and Can't) Replace

Read enough migration blog posts and you’d think adopting OpenTelemetry means deleting your observability vendor. It doesn’t — and teams that believe it discover the gap the hard way, usually when a dashboard goes blank a week after they uninstalled the old agent. OpenTelemetry is transformative, but only if you’re precise about what it actually is.

OpenTelemetry is a standard for producing, collecting, and transporting telemetry. It is not an observability backend: it doesn’t store data, index it, run a query language, draw dashboards, or evaluate alert rules. So the honest framing of any OTel migration is replace the left side of the pipeline, keep or rebuild the right side. This guide draws that line clearly so you can scope a migration that doesn’t leave anything dark.

The three layers OpenTelemetry actually standardizes

OTel replaces the parts of the stack that used to be proprietary and welded to one vendor:

• Instrumentation — OTel SDKs and zero-code auto-instrumentation produce spans, metrics, and logs in a vendor-neutral shape, replacing a vendor’s SDK.
• Collection — the OTel Collector receives, processes, and exports telemetry, replacing a vendor’s agent.
• The wire format — OTLP is one open protocol for all three signals, replacing a vendor’s proprietary protocol.

Everything downstream of OTLP — storage, indexing, query, visualization, alerting, analytics — is the backend’s job, and OTel deliberately doesn’t do it. That’s not a gap in OpenTelemetry; it’s the boundary that makes it a standard rather than a product.

What OpenTelemetry replaces — the honest matrix

Here’s the line, capability by capability. “Usually” means it works for most teams with validation; “Partial” means some of it moves and some doesn’t; “No” means it’s simply not what OTel does.

Capability	Move to OTel?	What it means in practice
Host & infrastructure metrics	Usually	hostmetrics / kubeletstats cover the standard set; validate vendor-specific metrics.
Application traces	Usually	OTel SDKs / auto-instrumentation emit OTLP; instrumentation depth may differ from a proprietary agent.
Log collection & forwarding	Often	filelog / journald collect; parsing and routing rules must be recreated as processors.
Custom / StatsD metrics	Usually	statsd and Prometheus receivers ingest most custom metrics.
PII redaction & data shaping	Yes	transform / redaction / filter processors — often better than a closed agent, and before egress.
Resource attribution / tagging	Yes	resource / k8sattributes processors set service.name, environment, ownership.
Dashboards	No	Rebuild in the new backend, or keep the old one. Not an OTel concern.
Alerting / monitors	No	Alert rules live in the backend; migrate them separately.
RUM / session replay	Usually not	OTel has browser/mobile signals but not feature parity with vendor RUM.
Continuous profiling	Emerging	OTel profiling is young; treat vendor profilers as not-yet-replaced.
Service topology / dependency maps	Partial	Derivable from traces, but auto-discovered proprietary maps don’t transfer 1:1.
AI root-cause / anomaly analytics	No	Vendor analytics (Davis, Watchdog, etc.); the new backend provides its own, if any.
Network performance monitoring	Usually not	eBPF/vendor-specific; not an OTel-native capability.
Backend storage & query language	No	OTel is not a backend — this is where residual lock-in genuinely lives.

The pattern behind the matrix

Look at the “Yes/Usually” rows versus the “No” rows and a clean split appears: OpenTelemetry owns everything up to and including the wire, and nothing past it. That’s why it’s such a good deal — the layer it replaces (agents, SDKs, protocol) is exactly the layer that used to be most expensive to switch, because it was deployed on every host and embedded in every service.

The “No” rows are real, and pretending otherwise is the mistake. But notice what kind of work they are: rebuilding a dashboard or re-authoring an alert is portable effort — you do it once, in a backend you chose, and you’re never blocked from leaving again. Compare that to re-instrumenting a thousand services, which is the wall that kept you locked in before. OTel doesn’t eliminate switching cost; it converts a technical impossibility into a project plan.

How to scope a migration so nothing goes dark

The failure mode is uninstalling the old agent before you’ve accounted for a “No”/“Partial” capability you actually depended on. Avoid it with a simple discipline:

1. Inventory what you actually use. Not what the vendor offers — what your team opens during an incident. Dashboards, the three alerts that page you, the topology view, RUM if you truly rely on it.
2. Classify each against the matrix. Collection-layer items move to OTel; backend-layer items get rebuilt or retained.
3. Dual-run. Keep the incumbent live while OTel ships in parallel, and validate parity before turning anything off. (Every vendor playbook below walks this.)
4. Retain deliberately. Where a capability doesn’t move — RUM, synthetics, profiling — decide consciously to keep a tool for exactly that, replace it, or drop it. “Forgot about it” is not a decision.

This is also where a control plane earns its place: it manages the collection layer OTel does replace, so the part you’re migrating is actually operable at scale.

Where this fits

If the collection layer is what OTel replaces, the next questions are how to run it and how to leave your current vendor:

• Reducing vendor lock-in with OpenTelemetry — the strategic case.
• OpenTelemetry architecture for enterprises — how the agent/gateway/control-plane pieces fit.
• Vendor playbooks: Datadog, Dynatrace, Splunk Enterprise, New Relic, Elastic Agent.

OpenTelemetry won’t rebuild your dashboards or replace your backend’s analytics — and a guide that tells you otherwise is selling something. What it does is hand you the collection layer as an open standard you own, which is the one thing that turns your backend from a life sentence into a choice.