The dashboards are usually the hardest part of any observability migration, because they hold institutional knowledge, not just charts.
Migrating dashboards means recreating your monitoring dashboards and alerts on a new observability platform faithfully enough that teams keep the views they depend on, done incrementally rather than as a big-bang cutover.
When teams plan a platform migration they focus on data pipelines and forget the dashboards, and then discover that the dashboards were the hard part. Every dashboard encodes institutional knowledge: which signals a team watches, what normal looks like, how they reason about their service. Dozens or hundreds of them, plus the alerts attached, represent years of accumulated operational understanding. A migration that loses or degrades them erodes the very trust the new platform needs, which is why dashboards deserve as much planning as the telemetry itself.
Start by taking inventory and prioritising: identify the dashboards people actually use, and delete the stale ones rather than carrying them over, a migration is a chance to clean house. Map the data sources and queries each dashboard depends on to their equivalents on the new platform. Rebuild or convert the panels, some platforms can import Grafana JSON or support dashboards-as-code, and validate side by side against the old dashboard so the numbers match. Migrate the alerts attached to each, then cut over. Managing dashboards as code in version control makes the whole process repeatable and reviewable.
The main pitfalls are query-language differences (a panel's query has to be rewritten for the new backend's language), panel and visualisation parity, and templating or variables that may work differently. Alert thresholds must be migrated carefully so nothing silently stops firing. And resist the urge to copy everything exactly: consolidate overlapping dashboards and drop vanity panels, so you arrive with a cleaner, more useful set rather than a faithful reproduction of the clutter you had.
| Step | What it involves |
|---|---|
| Inventory | List dashboards by usage; delete the stale ones |
| Map | Match data sources and queries to the new platform |
| Rebuild | Convert or recreate panels; use dashboards-as-code where possible |
| Validate | Compare side by side so the numbers match |
| Cut over | Migrate attached alerts, then retire the old dashboards |
Ops Singularity provides dashboards in its Ops Cockpit on the same correlated telemetry Sentinel AI uses, so a dashboard migration onto it lands teams on views that are not just visual but connected to autonomous resolution, the dashboard shows a system that is already fixing itself.
Because dashboards encode institutional knowledge, which signals teams watch and how they reason, so losing or degrading them erodes trust. There are usually many dashboards and alerts, each representing accumulated understanding.
Inventory and prioritise (delete stale ones), map data sources and queries, rebuild or convert panels (dashboards-as-code helps), validate side by side, migrate alerts, then cut over.
No. A migration is a chance to consolidate overlapping dashboards and drop vanity panels, arriving with a cleaner, more useful set rather than reproducing the clutter.
Ops Singularity turns open telemetry into autonomous, governed resolution. See it on your own stack.