"We want to switch monitoring tools, but we can't afford to lose our legacy dashboards and alerts"—we hear this concern constantly when providing custom SRE support.
In April 2026, InfoQ reported on Airbnb's OpenTelemetry migration for its metrics pipeline. By replacing legacy vendor products with OpenTelemetry (OTel)-native systems on a high-throughput platform handling tens of trillions of data points daily, their phased migration architecture offers valuable lessons.
This article summarizes the key takeaways from Airbnb's case study, explores architectural patterns for enterprise OTel migrations, and outlines how to structure these initiatives into custom development proposals.
Why migrate to OpenTelemetry now?
Background 1: Soaring monitoring vendor costs
Commercial APMs such as Datadog, New Relic, and Splunk primarily bill based on data volume. With the widespread adoption of AI agents and generative workloads, volumes of logs, metrics, and traces have surged, leading to frequent cases where annual costs multiply several times over.
Background 2: The trend toward lock-in avoidance
Rapidly maturing under the CNCF, OpenTelemetry reached maturity between 2024 and 2025, bringing together its three pillars of traces, metrics, and logs. Because swapping exporters enables sending data to any backend using the same instrumentation code, it is highly valued for structurally eliminating vendor lock-in.
Background 3: Observability demands for AI agents
As noted in LangFuse and Observability in AI Development, monitoring LLM workflows introduces requirements that traditional APMs cannot adequately address (such as tracking prompts, token counts, and tool calls). The OTel GenAI Semantic Conventions are becoming the de facto standard, further driving adoption.
Three architectural decisions learned from Airbnb
Architectural decision 1: Phased migration as an absolute prerequisite
Rather than switching everything at once, Airbnb adopted an approach of running OTel in parallel with their legacy platform, gradually migrating metrics one by one. This allowed for an extended transition period without losing existing dashboards or alerts.
Architectural decision 2: Placing the collector at the core
By deploying the OpenTelemetry Collector as an in-cluster gateway, their architecture absorbs routing, sampling, and transformation entirely at the Collector layer. Application instrumentation is unified around standard SDKs, eliminating the need to re-instrument code when changing backends.
Architectural decision 3: Solving high cardinality first
Exploding metric labels are the root cause of runaway costs. Airbnb first established label inventory and normalization rules before scaling throughput. Reversing this order inevitably results in failures across both cost control and query performance.
Typical enterprise OTel migration patterns
Pattern A: Full APM replacement
An architecture aiming for the complete replacement of commercial APMs (Datadog, New Relic, etc.). Uses OTel Collector routed to open-source-aligned platforms like Grafana Cloud, Honeycomb, Jaeger, and Prometheus. Offers substantial cost reductions, but entails significant dashboard migration effort.
Pattern B: Hybrid architecture
An architecture that retains commercial APMs for their UI while standardizing telemetry ingestion on OTel. Since APM vendors support OTel endpoints, instrumentation can be standardized first, leaving UI migration for a later stage. A practical intermediate solution.
Pattern C: LLM-observability-focused
An architecture that shifts only LLM workflows to OTel. Existing systems remain on legacy APMs, while new generative AI workloads are instrumented using OTel GenAI Semantic Conventions. Has the lowest barrier to entry.
| Variant | Estimated Migration Period | Initial Cost | Risk |
|---|---|---|---|
| A (Full replacement) | 6–12 months | Large | High (dashboard migration) |
| B (Hybrid) | 3–6 months | Medium | Medium |
| C (LLM-focused) | 1–3 months | Small | Low |
Five steps for structuring a custom development project
Step 1: Observability current-state assessment (2–3 weeks)
- Audit license structures and annual costs of existing monitoring tools
- Measure throughput and retention periods for metrics, logs, and traces
- Inventory dashboard and alert assets (prioritizing migration targets)
- Identify primary operational pain points
Step 2: Target architecture design (2 weeks)
- Select Pattern A, B, or C
- Design Collector topology (agent, sidecar, or gateway mode)
- Select backends (open source, SaaS, or hybrid)
- Establish cardinality design guidelines
Step 3: PoC and instrumentation guidelines development (4–6 weeks)
- Instrument a single service to establish end-to-end data flow
- Unify SDKs by language and implement standard wrappers
- Document instrumentation guidelines for engineering teams
Step 4: Phased migration implementation (2–4 months)
- Expand instrumentation sequentially across business domains
- Operate dashboards and alerts in parallel
- Implement phased routing switchovers via Collectors
Step 5: Operational handover and team enablement (ongoing)
- Provide training for SRE teams
- Develop runbooks
- Establish recurring monthly metric cost review meetings
Pitfalls custom development teams should avoid
Pitfall 1: Promising complete parity with existing dashboards
Because query languages and underlying data models differ, guaranteeing complete parity is impractical. Limiting the initial scope—such as "migrating the top 30 critical metrics" in initial agreements—ensures smoother execution.
Pitfall 2: Making the Collector a single point of failure
Architectures where all telemetry stops if a Collector fails are high risk. Redundancy and buffering must be included as baseline architectural requirements.
Pitfall 3: Postponing LLM instrumentation
For clients deploying new generative AI capabilities, LLM observability is often the most pressing need. Delivering quick wins here builds trust across the entire project. This aligns closely with telemetry checkpoints covered in RAG Optimization Patterns.
Pitfall 4: Making cost reduction the sole goal
Promoting OTel migrations by highlighting not only cost savings, but also accelerated development velocity and the elimination of vendor lock-in, significantly improves executive buy-in.
Client communication template (for executive leadership)
| Technical term | Executive-friendly phrasing |
|---|---|
| OpenTelemetry | "The industry standard specification for observability data" |
| Collector | "The switchboard (router) for observability data" |
| Cardinality | "The balance between observability data granularity and cost" |
| Vendor lock-in | "The risk of being unable to leave a specific monitoring tool" |
Stating in executive briefing materials that "writing instrumentation code once allows monitoring tools to be swapped out later" helps accelerate investment approvals.
Estimated timelines
2026-04 → 現状評価と設計（1 ヶ月）
2026-05 → PoC と計装ガイドライン策定
2026-06 → 1 ドメインへの本番反映
2026-07 〜 2026-09 → ドメイン順次展開
2026-10 → 旧ツール解約 or 縮小With Pattern B's hybrid approach, achieving tangible results within 3 to 6 months is straightforward, providing clear progress for executive reporting.
Conclusion: Designing observability platforms with replacement in mind
Airbnb's OpenTelemetry migration illustrates a paradigm shift: observability infrastructure must be abstracted just like compute infrastructure. In custom development environments, focus on these three priorities:
- Make the selection between Pattern A, B, or C the centerpiece of early alignment
- Define cardinality design rules first before ingesting telemetry
- Deliver LLM observability early as a high-impact quick win
At GleamHub, we provide end-to-end support for migrating observability platforms—from initial assessments and target architecture design to instrumentation guideline development and phased migration implementation. Whether rising APM costs have become an executive priority or your development team is building observability for generative AI workflows, reach out to discuss our one-month assessment phase. Together, we will map out the fastest path to eliminating future lock-in while preserving existing dashboard assets.
