An organisation with several existing telemetry systems considers adopting OpenTelemetry. What does it actually solve, and what does adopting it not fix?

What it solves

• Instrumentation is decoupled from the backend. Application code emits standard telemetry; where it goes is a collector configuration. This is the substantive benefit, because re-instrumenting an estate to change vendors is the reason organisations stay with a telemetry vendor they have outgrown.
• One instrumentation effort for three signals, with consistent context propagation between them — a trace that links to its logs and its metrics without bespoke correlation.
• Consistent semantic conventions, so an HTTP span means the same thing across languages and teams. This matters more than it sounds: inconsistent attribute naming is what makes cross-service queries impossible.
• A collector as a control point for sampling, filtering, redaction and routing, applied centrally rather than in every application.

What it does not fix

• Cost. Standardised telemetry is the same volume of telemetry. Cardinality discipline, sampling and retention decisions are unchanged, and the collector makes them easier to apply rather than unnecessary.
• Instrumentation quality. Automatic instrumentation gives spans at framework boundaries; the spans that explain your domain are still manual work, and their absence is why traces are often unhelpful.
• Vendor lock-in entirely. Query languages, dashboards, alerting rules and the analysis layer remain vendor-specific, and those represent substantial investment. What becomes portable is the data, not the usage of it.
• The migration. Existing instrumentation must be replaced or bridged, which for a large estate is a multi-quarter programme rather than a switch.

The adoption path that works

Collector first, instrumentation gradually. Deploy the collector to receive existing formats and forward them, which immediately provides the central control point for sampling and routing without touching application code. Then migrate instrumentation service by service, starting with new services where there is nothing to replace.

Attempting a big-bang instrumentation migration is how these programmes stall, because the value arrives only at the end and the effort is continuous.

The honest assessment

For an organisation with one telemetry vendor it is happy with, the benefit is modest and mostly optionality. For an organisation with several systems, inconsistent instrumentation, or a vendor relationship it wants to be able to exit, the portability is worth the migration — and the argument should be made on that basis rather than on standards compliance.