How to Migrate Datadog Dashboards to Grafana Without Losing Query Meaning

Pick the panels that change incident decisions

Inventory the dashboards responders actually use and choose the highest-value questions first: whether requests fail, which region is affected, whether a queue drains and when a deployment began. A panel nobody can connect to a decision is a poor first migration target.

For each selected panel, record its owner, source metric, filters, grouping, unit, query and links from alerts or runbooks. Include saved variables and default time ranges. A correct query with an unexpected default environment can still mislead a tired responder.

Translate semantics explicitly

Datadog's query documentation (opens in a new tab) describes filtering and aggregation, including time rollups. A destination query must reproduce the intended meaning rather than simply reuse a similar function name.

For Prometheus-backed panels, use the PromQL function reference (opens in a new tab) to verify rate and aggregation behavior. Do not replace a distribution percentile with an average of per-instance percentiles and call it equivalent.

Create a parity worksheet

Select a fixed UTC window with retained data in both systems. Compare numeric values at agreed timestamps, not only screenshots with independently chosen resolutions. Record the expected tolerance and why it exists, such as different sampling intervals.

Use one healthy period, one known incident and one low-traffic period. Add a deployment window if labels or instance lifetimes change during rollout. A panel that matches on steady traffic can diverge when counters reset or series disappear.

If data was collected differently in the two systems, call the comparison a coverage assessment rather than strict equality. Document the missing instrumentation and whether it affects the operational decision.

Rebuild links and investigation flow

Update drill-down links so a responder moves from a fleet overview to the relevant service, region and time window. Verify that links from alerts and runbooks open the new view with useful context.

Check mobile and smaller-screen behavior for the few panels needed during first response. Preserve clear titles and units. A denser layout is not an improvement if the operator cannot tell what population a number summarizes.

Keep alert migration as a separate acceptance gate

A migrated dashboard does not move its monitor automatically or establish equivalent alert behavior. Track alert rules separately, including duration, recovery, no-data behavior and destination. Use the composite alert migration guide for rules that combine conditions.

Keep one authoritative paging path while the candidate produces review evidence. Otherwise successful comparison can still generate duplicate incidents and confuse ownership.

Switch the documented default after review

Have a responder unfamiliar with the migration use the new dashboard to investigate a saved incident scenario. They should identify the affected service and supporting evidence without asking the author which filter to choose.

Record approved differences and unresolved gaps beside the migration checklist. Keep the old view available for a defined fallback period, then remove outdated links deliberately. Re-run critical parity checks after changing data-source mappings, default variables or aggregation settings.