A platform with services in five languages and three monitoring vendors considers adopting OpenTelemetry. What does it solve, and what is the realistic migration cost?

What it solves

One instrumentation API across languages and vendors. Application code emits telemetry once; where it goes is a collector configuration rather than a code change.

The concrete benefits:

• Vendor portability. Changing observability vendors becomes a configuration change rather than a re-instrumentation project across every service. For a platform with three vendors, this is the ability to consolidate without rewriting.
• Consistent semantics across languages. Standard attribute names for HTTP, database and messaging operations, so cross-service queries actually work. In a polyglot estate this is frequently the bigger win — a platform where one service logs user_id and another userId cannot be queried coherently regardless of tooling.
• One collector tier doing sampling, enrichment, redaction and routing centrally, so those policies are changed in one place rather than in every service.
• Automatic instrumentation for common frameworks, which covers a large share of what matters without code changes.

The realistic cost

Migration is a long project, not a quarter. Every service must be re-instrumented, and services owned by teams with other priorities will lag for a long time. A prolonged period of mixed instrumentation is guaranteed, and it must be planned for rather than treated as a transitional inconvenience.

A collector tier to operate — a new piece of infrastructure that is on the path of all telemetry and can therefore lose it. It needs its own capacity planning, monitoring and failure handling, and it is a correlated failure domain.

Feature gaps against mature vendor agents, which have had years of tuning for specific runtimes. Vendor-specific capabilities may need to be given up or reimplemented.

Semantic convention churn. Attribute naming standards evolve, and dashboards and alerts built on them need updating.

The recommendation

Adopt for new services immediately — the marginal cost is near zero and the position improves over time.

Migrate existing services opportunistically, prioritising those on critical paths and those that already need instrumentation work. Do not run a big-bang migration project; the value accrues per service and the risk is concentrated by doing them together.

Deploy the collector tier early, even while most services still use vendor agents, because centralised sampling, redaction and routing deliver value independently of instrumentation migration.

The strategic argument is the strongest one: instrumentation is the highest-switching-cost part of observability. Owning it in a portable form is what preserves the ability to change vendors, and that optionality is usually worth more than any single vendor feature.