OpenTelemetry Adoption: Why Most Organizations Get It Wrong
After leading observability rationalization projects at Fortune 500 companies and serving as the OpenTelemetry SME at Groundcover, I’ve watched dozens of organizations attempt OTEL adoption. Most start with the wrong assumptions.
The Common Mistake: Big Bang Migration
Organizations treat OpenTelemetry adoption like a database migration: plan everything, execute once, celebrate. This fails because:
- Legacy instrumentation has institutional knowledge baked in: your existing dashboards and alerts encode years of production incidents
- Vendor SDKs are wired into everything: ripping them out breaks more than observability
- Teams resist learning curves: especially when the old tools “work fine”
The Better Approach: Strategic Layering
Instead of replacing existing observability, add OpenTelemetry as a data layer:
Phase 1: New Services Only (Months 1-3)
- Mandate OTEL for all new microservices
- Create golden path instrumentation templates
- Export telemetry in parallel to both your OTEL collector and the legacy backend
- Build confidence without breaking production
Phase 2: Edge and Mesh Instrumentation (Months 3-6)
- Instrument API gateways, load balancers, and (if you run one) the service mesh with OTEL
- Capture entry-point and hop-level spans without touching application code
- Push W3C trace-context propagation inward so those spans start linking into end-to-end traces, instead of staying isolated at the edge
Phase 3: High-Value Migrations (Months 6-12)
- Migrate services where legacy observability is painful
- Target the services that deploy often, break often, and have the worst instrumentation
- Show ROI: faster troubleshooting, lower vendor costs
Phase 4: Observability Pipeline (Months 12+)
- Introduce OTEL collector pipelines for sampling, enrichment, routing
- Route less critical data to cheaper backends
- Keep high-value data in premium tools
Why This Works
It separates data collection from data destinations. Your teams adopt OTEL instrumentation without also migrating dashboards, alerts, and runbooks. You de-risk the transition.
It proves value early. By month 4 you have distributed traces across your instrumented paths and edge: request flows most orgs can’t see today, and you got there without migrating a single dashboard or alert.
It strengthens your hand at renewal. When your observability vendor sees OpenTelemetry collectors in production, renewal conversations get interesting. You’re no longer locked in.
The Build vs. Buy Decision
The dirty secret is that OpenTelemetry is infrastructure, not a product. You still need:
- Trace storage and query engines
- Dashboarding and visualization
- Alerting and incident management
- SLO tracking and error budgets
Some organizations build these (Uber, Netflix). Most should buy (Honeycomb, Grafana, Datadog’s OTEL support).
The win isn’t avoiding vendors. It’s avoiding vendor lock-in.
Real-World Outcomes
At a Fortune 500 semiconductor manufacturer, we:
- Reduced observability spend by 40% over 18 months
- Cut MTTR by 25% through distributed tracing
- Migrated 60% of critical services without a single SEV-1 incident
At a major financial services firm:
- Consolidated 9 observability vendors down to 3
- Improved signal-to-noise ratio (alert fatigue dropped by 50%)
- Gave teams flexibility to choose backends based on use case
Where Organizations Need Help
Most engineering teams can instrument a service with OTEL. What’s hard:
- Sampling strategy: head-based sampling is cheap but blind; tail-based sampling keeps the errored and slow traces that matter, but forces you to buffer every span until the trace completes. Tuning that tradeoff at scale is the hard part.
- Collector pipelines: enrichment, routing, backpressure handling, failover
- Schema governance: preventing instrumentation drift across 200 microservices
- Organizational change: getting SREs to trust new tooling
This is where fractional leadership pays off. You need someone who’s done this before, can architect the strategy, and doesn’t need 6 months to understand your infrastructure.
Bottom Line
OpenTelemetry adoption is an organizational transformation disguised as a technical problem. Treat it like one.
Need help with your observability strategy? I’ve led these transformations at enterprise scale. Let’s talk.