An observability vendor migration can avoid widespread application re-instrumentation when applications emit OpenTelemetry data through a controlled Collector boundary. That portability is real but bounded. OTLP moves telemetry; it does not translate proprietary query languages, alert semantics, dashboard variables, access models, retention, derived metrics, billing units, or incident habits. Plan a data-plane migration and a decision-plane migration, then cut over only when both produce trustworthy outcomes.
OpenTelemetry describes itself as a vendor-neutral observability framework for generating, collecting, and exporting traces, metrics, and logs; it is not an observability backend. The official OpenTelemetry overview makes that division useful: keep application APIs, SDKs, semantic conventions, and OTLP endpoints under your control, while treating backend-specific features as explicit adapters. The migration inventory reveals where that separation already holds and where lock-in remains.
Define the portability boundary and migration contract
Inventory every producer, agent, collector, receiver, processor, exporter, credential, endpoint, and network path. Then inventory consumers: dashboards, alerts, SLOs, recording rules, notebooks, APIs, reports, incident links, retention classes, legal holds, and access groups. Mark each item portable, translatable, replaceable, retained in place, or retiring. Include owner, business criticality, data volume, current cost, migration test, and rollback dependency.
Freeze the semantic contract before dual export. Pin SDK and collector versions, resource identity, attribute transformations, sampling, metric temporality, histogram form, log severity mapping, and redaction. If these change while backends are compared, disagreements cannot be attributed. The OTLP specification defines protocol behavior, but accepting OTLP does not guarantee two backends index, aggregate, or expose identical results. Write tolerances per signal and use case.
| Asset | Portability question | Acceptance evidence | Likely owner |
|---|---|---|---|
| Instrumentation | does it use standard API, SDK and semantics? | fixture emitted through neutral endpoint | service team |
| Collection | are transforms and sampling versioned? | replay and pipeline metrics | observability platform |
| Stored telemetry | must history move or remain searchable? | retention and access decision | platform plus legal |
| Queries and alerts | can results and timing be reproduced? | golden-window comparison | service or SRE owner |
| Identity and access | do roles and tenant boundaries map? | authorized and denied test matrix | security |
| Commercial exit | when can ingest and storage contracts end? | dated termination and export record | procurement |
Build and harden the neutral Collector layer
Applications should send to an organization-controlled endpoint rather than embedding a vendor destination. Configure receivers, processors, exporters, extensions, and pipelines using the official Collector configuration model. Keep secrets external, validate configuration in CI, and deploy through canaries. Separate gateway pools when tail sampling or tenant isolation requires state. Monitor accepted, refused, dropped, queued, failed, and exported items by destination.
Neutral does not mean free of implementation choices. A transform written for a backend can quietly become part of the data contract. Classify processors as source normalization, governance control, routing, or destination adaptation. Put destination adapters at the latest possible boundary and test their output. Size for dual export, including serialization, connections, queue memory, retries, and egress. Collector scaling guidance is a starting point; load-test the exact pipelines and failure modes.
Dual-export telemetry without doubling risk
Start with synthetic telemetry, then a low-risk service cohort and bounded production volume. Use independent exporter queues so a slow destination does not block the other. Define retry age and drop policy; unlimited queues turn a vendor outage into a collector outage. Preserve deterministic sampling where comparison requires the same traces. For tail sampling, export the post-decision trace to both destinations or results will differ by design.
Watch the commercial side. Dual ingest can double backend and network charges, while translated metrics can change active-series counts. Set a budget and expiry for parallel running. Redact before fan-out so both destinations receive the same approved data. Verify regional routing and data residency independently. A successful exporter counter is insufficient: query known trace IDs, log fingerprints, and metric windows in each backend and reconcile received populations.
| Signal | Compare | Allowable difference | Cutover blocker |
|---|---|---|---|
| Traces | trace count, completeness, duration, attributes and links | documented indexing delay | missing critical spans or tenant leakage |
| Metrics | series, temporality, resets, buckets and query results | defined rounding tolerance | different alert decision |
| Logs | count, severity, timestamp, parsing and redaction | known multiline representation | lost audit or error class |
| Alerts | condition, evaluation delay, grouping and notification | bounded delivery variance | missed page or duplicate storm |
| Dashboards | filters, units, time zones and drill-down | approved visual difference | operator cannot answer runbook question |
Migrate queries, alerts, and incident workflows
Translate intent, not syntax. For each critical query, state population, aggregation, window, grouping, missing-data behavior, time zone, and expected decision. Build golden windows containing quiet periods, spikes, resets, deploys, and incidents. Run old and new queries and explain discrepancies. Derived metrics and backend rollups often matter more than raw ingest. Recreate SLO calculations with exact event definitions and error-budget windows before changing pages.
Run shadow alerts to a non-paging route, comparing evaluation time, firing intervals, labels, grouping, inhibition, and recovery. Then let selected teams use the new backend during real support work while the old system remains authoritative. Measure time to answer runbook questions, not just dashboard count. Train access, search, trace navigation, annotations, and incident links. A migration is not complete if data exists but operators still open the old tool first.
Cut over authority and close the old contract
Move in layers: read-only exploration, dashboard authority, shadow alerts, selected paging, all paging, and finally ingest. Define rollback at each layer. DNS or Collector configuration rollback restores data flow, but dashboards and notification routes need their own reversals. Keep old credentials and capacity for a bounded observation period. Stop if loss, latency, query divergence, page behavior, or operator performance crosses a predeclared threshold.
Decide whether historical data is exported, retained under a read-only contract, or allowed to expire. Validate export format, completeness, cost, and future readability before assuming portability. Remove vendor SDKs and agents only after proving no unique signal remains. Revoke credentials, stop dual export, reconcile final invoices, capture contract obligations, and test deletion. Preserve the migration fixtures and parity suite; they become leverage for the next backend upgrade or replacement.
Treat proprietary enrichments as deliberate migration work. A former backend may have created service maps, inferred Kubernetes metadata, converted logs into metrics, or supplied agent-only host data. For each enrichment, decide whether to reproduce it with standard collection, accept a new implementation, retain a limited legacy source, or retire the dependent use case. Document the accuracy difference. Rebuilding every feature wastes effort, but discovering after cutover that a page depended on an undocumented derived metric is avoidable.
Include procurement and legal gates in technical waves. Confirm data-processing terms, regions, subprocessors, security evidence, support response, export rights, deletion commitments, rate limits, overage behavior, and contract start and end dates. Model new billing units with real shadow volume rather than sales estimates. Reserve capacity for incident bursts and retry storms. Require a named owner for final legacy termination; parallel systems often persist because each technical team assumes someone else will close the commercial obligation. A completed migration has one authoritative production path and no accidental double bill.
Plan communication by audience. Service teams need endpoint, SDK, semantic, and support changes; on-call teams need new query and alert behavior; security needs access and data-flow evidence; finance needs overlap cost and cutoff dates; executives need risk and decision parity. Publish a migration status keyed to capabilities rather than a percentage of dashboards copied. A service is ready only when its production telemetry, critical consumers, responders, ownership, and rollback have passed. This prevents a large count of low-value assets from hiding one untested paging path.
Keep a compatibility endpoint after cutover only when it has a named sunset. Measure remaining senders, reject new registrations, and contact owners before expiry. An indefinite legacy receiver recreates the coupling the migration was meant to remove, adds another security surface, and lets unmaintained agents escape the tested semantic contract. Close it through observed zero traffic and an explicit exception process.
Key takeaways
- Inventory both telemetry transport and the queries, alerts, access, retention, and habits that consume it.
- Freeze semantics before comparing backends so differences have an explainable cause.
- Isolate destination exporters and bound queues, retries, dual-ingest cost, and parallel duration.
- Translate query intent and prove alert decisions against golden historical windows.
- Close the migration through historical-data disposition, credential revocation, final reconciliation, and tested deletion.
Frequently asked questions
Does OTLP guarantee backend portability?
No. It standardizes telemetry transport and data models, while storage, query, alert, access, retention, and pricing semantics remain backend concerns.
How long should dual export run?
Long enough to cover representative traffic and operational events, but with a fixed budget and expiry. Critical systems may need a full release or incident cycle rather than an arbitrary day count.
Must all historical telemetry be migrated?
No. Export, read-only retention, and expiry are all valid when legal, incident, cost, and query needs are explicit and future readability is tested.
Conclusion
OpenTelemetry can keep application instrumentation stable while vendors change, but only a deliberate boundary turns that possibility into leverage. Prove the pipeline, semantics, decisions, and operator workflow in parallel; then transfer authority in reversible layers and close the old data and commercial obligations with evidence.