How to Choose an Observability Platform Without Vendor Lock-In

OpenTelemetry can make your instrumentation portable; your dashboards are under no obligation to cooperate.

Pointing new telemetry at another backend is often the easy part. The queries behind your paging alerts, the metrics your dashboards expect, and the incident history you still need may all depend on the platform you're leaving. That's where vendor lock-in becomes expensive, regardless of how happily the new backend accepts OTLP.

This guide turns portability claims into tests you can run before committing to a platform: move the data, reproduce a dashboard and an alert, retrieve history, and calculate the cost of the transition. For broader platform-selection criteria, see evaluating observability platforms for modern engineering teams.

Start by defining what you need to take with you

A migration will involve new credentials, unfamiliar interfaces, and retested integrations. That's normal. Rebuilding the alerting and investigation setup because it only works inside one vendor's platform is a different kind of expense.

Start with the assets that actually need to survive the move:

Prioritize the assets that matter during an incident. A dashboard nobody has opened in six months should not carry the same weight as the alert that pages your payments team.

Put an exit budget against that inventory: engineering hours, overlapping platform bills, and any disruption to historical investigations. Otherwise, "portable" is just a reassuring adjective.

1. Make instrumentation independent of the backend

OpenTelemetry standardizes how applications generate, collect, and export telemetry. It deliberately leaves storage and visualization to other systems. You control the journey into the backend, not what happens to the data after it arrives.

For application instrumentation, prefer upstream OpenTelemetry APIs, SDKs, and supported auto-instrumentation. If a vendor provides its own distribution, inspect what it adds. A distribution can simplify installation, but required extensions or proprietary APIs can create work when you replace it.

Ask the vendor to demonstrate a representative service sending traces, metrics, and logs over the OpenTelemetry Protocol (OTLP) without its proprietary agent. Include any language or runtime that is particularly important to your stack.

Then check whether the resulting data is actually useful. Can you find a failed request, follow it across service boundaries, and retrieve the associated logs? Are the resource attributes you use to distinguish deployments, customers, or environments still available?

An accepted payload proves the connection works. Being able to investigate the same failed request proves something considerably more useful.

Treat additional signals separately. If browser monitoring, profiling, or another capability is essential, test its collection and export path explicitly. Support for OTLP traces does not establish portability for every feature sold alongside them.

For a deeper assessment of data fidelity and backend behavior, see what makes a good OpenTelemetry backend.

2. Keep control of your telemetry pipeline

The Collector is a good place to be stubborn about ownership. Give applications an endpoint you control, and backend changes can happen in the telemetry pipeline rather than in every service deployment. The OpenTelemetry Collector separates receiving, processing, and exporting into configurable components, including multiple exporters. Dash0's beginner's guide to the Collector covers the pipeline details.

Keep its configuration in your repository. Document which components and versions it requires, where credentials come from, and who owns upgrades. If you use a vendor-managed distribution, verify that the components you rely on are available in an independently deployable build.

Watch for processing that creates data inside the backend. Suppose your current platform generates the request-count metric behind an availability SLO. The spans may arrive at the new platform perfectly intact, while the metric the SLO depends on is nowhere to be found. Reproduce its definition, including filters, dimensions, and sampling assumptions.

The same applies to redaction and enrichment. If a policy must survive a provider change, keep an independently executable version of it, such as redaction rules in the Collector. Where backend-side processing provides useful capabilities, record the dependency and how you would replace it.

During a trial, use the Collector to send a bounded workload to both platforms. Apply shared filtering and sampling before the split where appropriate, so the comparison begins with equivalent input. Check for additional processing inside each backend before interpreting differences.

Account for duplicate ingestion and network costs. Monitor the Collector itself, including queue pressure and export failures, and test what happens when the trial destination becomes unavailable. Fan-out is useful for comparison; its failure behavior still depends on your pipeline configuration. Dash0's guide to batching, queuing, and retries explains those tradeoffs.

3. Test dashboard and alert portability beyond the file format

An export button isn't much of an escape hatch if the next platform cannot use what comes out of it.

Check the queries behind the dashboards

PromQL gives metric queries a better chance of surviving a backend change. It cannot conjure up missing metrics. The destination still needs the names, labels, units, histogram representations, and any recording rules that produce intermediate series.

Take a latency dashboard that references a vendor-generated metric. Its expression might be valid PromQL, yet return nothing against another backend because that metric is absent. Document how to produce the required series, then compare the results using the same workload and time window.

Apply this scrutiny to logs and traces too. A platform can expose them through familiar query syntax while relying on its own mapping of those signals. Reusing the language does not guarantee that another backend exposes the same data model.

Perses provides an open dashboard specification and tooling for managing dashboards as code. For background, see what Perses is and how it differs from Grafana. Export a real Perses dashboard into another compatible environment and check its panel plugins, data-source configuration, queries, variables, and links. An open definition helps with the move; it doesn't supply the missing dependencies.

Verify alert behavior, not just expressions

A portable alert expression is only useful if it still produces the right page. Prometheus alerting rules also specify pending durations, labels, and annotations; notification handling sits elsewhere. All of those details affect what happens when something breaks.

Replay a controlled failure and check when the alert becomes pending, when it fires, and when it resolves. Also test missing data and confirm which team receives the notification. A syntactically valid rule can still behave differently if evaluation intervals, data arrival, or routing change.

For SLOs, retain the underlying definition: good events, total events, exclusions, objective, and window. Check whether another system can calculate the same result. An exported percentage without those inputs is difficult to validate or reconstruct.

Store dashboard and alert definitions alongside the services they describe. Configuration as code makes ownership, review, and recovery easier. A vendor-specific Terraform resource may automate deployment very well, but it still needs translating when the destination changes.

4. Separate live telemetry portability from historical data access

Redirecting tomorrow's telemetry does nothing for last month's incident history.

Decide which history actually has to travel. Recent traces may matter for active incidents, older logs for audits, and aggregated metrics for seasonal comparisons. Moving all of it may be unnecessary, but assuming it's accessible later is an expensive guess.

Test the export path rather than accepting "data export supported" as the entire answer:

• Does the export contain individual records or only query results and aggregates?
• Which timestamps, identifiers, attributes, and metric metadata survive?
• What pagination, rate, time-range, and volume limits apply?
• What does exporting cost, and how long does access remain available after termination?
• Can the receiving system ingest records with those original timestamps?

Test a representative sample. Parse it independently, compare record counts and selected fields, and attempt the investigation you would need it for. A file on disk is not much of an archive if it cannot answer the question that made you keep it.

Use measured throughput to estimate duration. For example, exporting 2 TB at a sustained 20 MB/s takes roughly 28 hours before retries, transformation, or re-ingestion. Those are illustrative numbers; substitute the throughput and volume from your own test.

Sometimes retaining read-only access to the previous platform is cheaper than migrating all history. Sometimes a separate archive is justified. Record the access period and cost either way, and test retrieval from an archive before relying on it. Exporting data does not guarantee another platform can reconstruct the original query experience.

5. Price the transition as well as the steady state

A technically feasible exit can still be too expensive to use.

Compare the bill at your current workload and a plausible growth scenario. Then calculate a transition period with two backends receiving data. Include ingestion, retention, query charges, export charges, network egress, and the people doing the migration where those costs apply.

Renewal dates, notice periods, minimum commitments, export access, and overlap charges can determine whether the migration window exists at all. Get those terms in writing; a reassuring demo is not part of the contract.

Estimate engineering work separately. Use your dashboard and alert tests to expose dependency classes: simple metric panels, vendor-generated metrics, custom visualizations, complex notification routes. A successful move of one simple dashboard is weak evidence for the rest of the estate. For a worked example of what a full move involves, including query translation to PromQL, see migrating from Datadog to OpenTelemetry and Dash0.

Open source and self-hosting deserve the same scrutiny. Access to source code can improve your options, while running a platform yourself adds capacity planning, upgrades, and on-call responsibilities. You can still accumulate dependencies on a particular query language or data model. Evaluate the exit work and operating work together.

Run an exit test before choosing a platform

A platform trial that never tests leaving tells you very little about lock-in. Pick one representative service, one dashboard engineers actually use, one paging alert, and a small historical dataset. Include an SLO or automation if either is central to your operations.

Agree on the acceptance criteria before the trial. The following sequence provides a practical starting point:

Record engineering hours, help required, features lost, and dependencies that remain. Set a pass condition your team can live with, such as moving the test workload within two engineer-days without changing application instrumentation. That's an example of a trial target, not a claim that a production migration takes two days.

If a feature fails the portability test, decide whether its benefit justifies the replacement cost. An exceptionally useful proprietary capability can be a reasonable choice when the dependency is understood and bounded.

Include AI-assisted workflows in this exercise when they influence incident response. Check whether generated dashboards, rules, and runbooks are available outside the chat interface, and whether an automation depends on vendor-only tools or stored state. Keep the operational instructions and required permissions documented independently.

Where Dash0 fits

Dash0 offers several pieces this exit test can inspect directly: OpenTelemetry-based collection, Perses-based dashboards, and check rules built on an extension of the Prometheus alerting model. Its observability-as-code capabilities let you manage dashboards and check rules through development workflows.

That makes for a useful test, not a portability exemption. Send telemetry through your existing Collector, reuse applicable Prometheus rules, and export dashboard definitions in Perses format. Then check the dependencies, historical exports, and transition costs just as you would for any other platform.

Start with one service using the Dash0 getting-started guide. Build the dashboard and alert needed for a real investigation, then test the same exit path.

Final thoughts

The easiest part of a migration is often the part that makes the best demo: sending telemetry to a new endpoint. The things engineers depend on when production is misbehaving are harder to pack. Queries, generated metrics, paging rules, and historical data can all tie you to a platform long after the application code is vendor-neutral.

Do the exit test before the contract makes leaving a problem for another year. Move one service, one dashboard, one alert, and a sample of history. Record what breaks, how much work it takes to fix, and which dependencies you would accept in return for useful features.

That standard applies to Dash0 too. A platform that can demonstrate a workable exit path has done more to earn your trust than one that merely has an OTLP checkbox.

If you'd like to see how an OpenTelemetry-native platform approaches portability from the start, try Dash0 free for 14 days. No credit card required.