Your Dashboards Are No Longer a Reason to Stay

Every conversation about switching observability platforms ends at the same place. The pricing math works. The feature comparison works. Then someone says "we have 300 dashboards" and the project dies in planning.

That objection deserved a real answer, so we built one. The OpenObserve Dashboard Migrator is a free web tool that converts dashboards from Datadog, Grafana, Kibana, and AWS CloudWatch into OpenObserve automatically. Queries are translated, layouts are preserved, and you can inspect every conversion before you commit to anything. No signup is required. It is live now at migration.openobserve.ai.

Why dashboards became the moat

Dashboards are where years of operational knowledge accumulate: the tuned queries, the panel that caught the last three incidents, the layout your on-call engineers can read at 3am without thinking. Rebuilding all of that by hand is weeks of skilled work that nobody can prioritize, and vendors know it. Dashboard lock-in is quieter than data lock-in, and often stronger. It is also the biggest hidden cost in any Datadog alternative migration.

Migration tooling has always focused on the data path: ship your logs, metrics, and traces somewhere new. The presentation layer was left as an exercise for the reader. This tool closes that gap.

What it actually does

The migrator takes the dashboard definition your current tool already exports and produces a schema-validated OpenObserve v8 dashboard. Three things happen along the way.

Query translation. This is the hard part, and it is source-specific. Grafana PromQL maps directly to OpenObserve PromQL, so Prometheus-based dashboards are the smoothest path. Datadog metric queries convert to PromQL, while Datadog log and trace queries become SQL. Kibana's Lucene and KQL queries translate to SQL, with aggregations converted and streams mapped. CloudWatch metric widgets become SQL panels over your OTEL metric stream, with dimensions turned into filters.

Layout conversion. Panels, rows, tabs, and template variables carry over. Standard panel types all convert: timeseries, stat, table, gauge, pie chart, heatmap, text, and logs.

Schema validation. The output is validated OpenObserve v8 JSON. It imports cleanly rather than arriving as a best-effort file you debug afterward.

How a migration runs

The whole flow is four steps in the browser.

1. Load. Upload or paste the dashboard JSON exported from your current tool. The site shows exactly where to find the export in each product (in Grafana, for example, it is Dashboard settings, then the JSON Model tab). You can also connect with an API token and pick dashboards directly.
2. Connect, optionally. Link your OpenObserve org and the tool matches each panel and variable to a stream that actually exists in your instance, flags anything missing, and lets you pick streams per panel from a searchable list. In a hurry? Skip this step and get an instant static conversion instead.
3. Review. This is the step we are most proud of. You get coverage stats for the whole dashboard, a status for every panel (migrated, needs review, or skipped), and a confidence score for each translation. Click any row and the exact query conversion opens for inspection.
4. Export. Download the OpenObserve v8 JSON and import it, or, if you connected your org, create the dashboard there with one click.

We tested it on a monster

To pressure-test the tool we ran Grafana's Node Exporter Full through it, one of the most widely deployed community dashboards anywhere: 124 widgets across gauges, stats, timeseries panels, and three template variables.

The result: 124 of 124 panels converted, zero skipped, in under two minutes end to end. 70 panels came through at high confidence, ready to use as-is. The remaining panels were flagged for review with notes explaining exactly what to verify. Nothing needed rebuilding from scratch.

That flagging behavior is deliberate. Automatic translation of complex queries is never perfect, and a tool that pretends otherwise wastes your time in worse ways later. When a translation is uncertain, the migrator tells you. When a panel type is unsupported (canvas, dashlist, alertlist, and plugin-backed panels currently are), it is skipped with a note, never silently dropped.

A note on security

Connecting your OpenObserve org is optional, and static conversion requires no account at all. If you do connect, your credentials stay in the browser session. They are used only to fetch your stream list and, if you choose one-click creation, to send the migrated dashboard to your org. Nothing is stored server-side.

What about CloudWatch?

CloudWatch support comes with one prerequisite worth knowing up front: the tool supports CloudWatch metrics ingested into OpenObserve as an OTEL metric stream (CloudWatch Metric Streams to Firehose in OpenTelemetry format). Metric widgets then convert to SQL panels over that stream. Logs-Insights and alarm widgets are skipped with notes. If you are already standardizing on OpenTelemetry, you are ready today.

Running something else?

Datadog, Grafana, Kibana, and CloudWatch cover most of the requests we heard, but not all of them. The site includes a request form for other platforms. Tell us what you run and what you need, and we will let you know when we can move you over.

Try it on a real dashboard

The best evaluation takes about ten minutes: export the dashboard your team looks at most, drop it into migration.openobserve.ai, and look at the coverage number. If a translation comes out wrong, use the Report Issue button on any page. We are improving the converters weekly, and real-world dashboards are exactly the test cases we want.

Not on OpenObserve yet? Sign up for a free O2 Cloud trial and you will have a destination for your dashboards in a few minutes.

Your data path to OpenObserve was already open. Now your dashboards can follow it.