Grafana legacy alerting migration

How to migrate legacy Grafana alerts to Grafana Alerting before the next major upgrade

To move legacy Grafana alerts, inventory every dashboard-based alert rule and notification channel on your current instance, then recreate the rules and routing in Grafana Alerting on the version your upgrade path requires. Do this before the next major release, because the old alerting path has to be settled before you upgrade. Confirm the target version against the Grafana upgrade guidance and the alerting documentation for the exact versions in scope, since the sequence of intermediate steps depends on where you start.

The effort depends on four things: how many rules you run, which notification channel types they use, which data sources they query, and how many teams depend on alert routing. A small instance with a few rules and one email channel is a short exercise. An instance where a single channel fans out to on-call tools for several teams, and where rules query more than one data source, needs a written mapping of each rule to its owner, its contact point and its notification policy. Check every channel type against what Grafana Alerting supports in your target version. Where a channel does not carry over cleanly, decide whether to replace it, keep a parallel path, or retire the alert.

Most of the cost is internal or partner time spent on inventory, mapping, testing and cutover, and that work happens once. Recurring cost comes from owning the rules afterward. Because Grafana publishes minor releases every other month, your window between upgrades is short, so plan the cutover and a rollback path before the start date. When you request a quote for a fixed-scope engagement, ask for the rule and channel inventory method, the test plan for alert delivery, the cutover window, the rollback procedure, and what the partner needs from your team.

Which legacy alerting capabilities map to Grafana Alerting and which need rework

This table compares each legacy dashboard alerting item with its Grafana Alerting counterpart and marks whether it converts automatically, converts with changes, or must be rebuilt by hand. Treat every status as a starting assumption and confirm it against the official conversion notes for your target version. The main takeaway is that conditions and timing usually carry over, while channel-specific routing and unsupported channel types need planned rework.

Legacy item	Grafana Alerting equivalent	Migration status and notes
Dashboard alert conditions	Alert rule queries and expressions	Converts with changes. Legacy conditions are rewritten as expressions, so compare results and thresholds on a test instance.
Evaluation frequency and pending period	Rule group interval and pending period	Converts with changes. Legacy settings are grouped into rule groups, so check that each shared interval still suits its rules.
Notification channels	Contact points	Converts with changes. Supported channel types map to contact points, but confirm each integration's settings and secrets after import.
Channel types without an equivalent	No direct equivalent	Must be rebuilt by hand. Replace with a supported integration or webhook, and confirm the supported list for your target version.
Channel assignment per alert	Notification policy tree with labels	Must be rebuilt by hand. Per-alert channel selection does not carry over as-is, so design routing with labels and policies.
Dashboard and folder permissions	Folder permissions on alert rules	Converts with changes. Alert rule access follows folder permissions, so review which teams can edit migrated rules.
Alert state and history	Alert instance state	Confirm before cutover. State handling during migration and rollback depends on the upgrade path you choose.
Silences and mute timings	Silences and mute timings	Must be rebuilt by hand. Recreate active silences and schedules after cutover, and confirm what the conversion carries across.

Documented upgrade and conversion paths for legacy alerts

Grafana offers several routes off legacy alerting: a preview that shows what would convert, an in-product upgrade, the clean_upgrade option, and configuration and API routes for reviewing or recreating rules. Each one changes a different part of the instance and leaves different things behind. Run the preview first, take a database backup before any conversion, and confirm each step's behavior in the docs for your target version.

Preview before any change

Preview mode shows which legacy dashboard alerts would convert before you commit to a change. Save its output with the dashboard versions it covers, then compare each proposed rule's query, evaluation interval and labels with the original panel. Confirm in the Grafana docs for your target version exactly what the preview reports, because the result depends on which alert types and notification channels your instance uses.

Simple in-product upgrade

The in-product upgrade converts legacy alerts and notification channels into Grafana-managed rules and contact points on the instance itself. Channels the conversion does not map must be recreated by hand, so list them before anyone's pages depend on the new setup. After the run, compare rule counts per folder with your pre-upgrade inventory and send one test notification per contact point. Check the docs for the list of mappable channel types first.

The clean_upgrade option

The clean_upgrade option changes what happens to existing legacy alert data during the upgrade, so read its exact behavior in the docs for your version before you set it. Do not assume it behaves like a plain conversion. Take a database backup first, because the database holds the instance's configuration, and test the option on a copy of production data before running it on the live instance.

What rollback restores

Rollback depends on what the upgrade removed or rewrote, so confirm in the docs which legacy artifacts a rollback restores for your version. Do not rely on an assumed revert. The database backup taken before conversion is the restore point you control. Test the restore on a non-production copy and verify that legacy rules evaluate and that notifications reach their destinations.

Reviewing rules through provisioning files

After conversion, export the alerting resources and keep them as files you can diff. Grafana provisioning loads alerting resources from YAML or JSON files at startup, which gives you a repeatable way to recreate rules and contact points on another instance. Compare the exported files with your pre-upgrade inventory, and confirm that every contact point appears with its intended notifier type.

Alerting API routes for recreation

Where the instance exposes alerting configuration through its API, use those routes to read existing rules and contact points, then recreate them on a target instance with a script you can rerun. Confirm the endpoints, required permissions and payload format for your version before writing automation. Authenticate with a service account token so the script does not depend on a person's login.

Preview versus simple upgrade: choosing the conversion path

A small instance with a few dashboard alerts, one owner and no shared notification channels can usually accept a direct upgrade. The owner knows every rule and can check firing behavior by hand after the change, so a full preview adds little beyond a short review. Read the upgrade guidance on timing before you pick a window.

Direct upgrade is acceptable when the owner can name each alert, its data source and its contact point from memory or a short list.
A preview is worth the time when the owner cannot identify the channels attached to alerts, or suspects a dashboard uses a legacy alert that will not carry over cleanly.
Block the upgrade when the preview marks a channel type as not converting and that channel is the only route to whoever responds to the alert.
Back up the database first so that any rollback has a known state to return to.

Before the change, confirm in the release notes for your target version which channel types convert, and record the list alongside the backup location.

Sequence for a parallel run and cutover of Grafana alerts

This sequence moves dashboard alerts and notification channels to Grafana Alerting in controlled stages, so each team proves its alerts fire and recover correctly before the legacy definitions are retired. The output is a dated record of what converted, what was rebuilt and who signed off on each cutover.

Inventory alerts, channels and owners
Before touching the instance, list every dashboard with legacy alert rules, every notification channel and every data source those alerts query. Record the owning team or folder for each item, plus the people who receive its notifications. Ask the team leads to confirm the list, since ownership gaps are the most common reason a cutover stalls. The step is done when every legacy alert and channel has one named owner and one destination in the cutover plan.
Run the preview and log unconverted items
Run the migration preview on a copy of the instance, not the live one, and export or record its report. Each alert or channel that the preview cannot convert should be logged with its dashboard, folder, owner and the reason given. Treat the log as the work list for the rebuild step. The step is done when every legacy item is either marked as converting cleanly or has a logged entry with a named owner.
Back up the database and provisioning files
Take a backup of the Grafana database and a copy of the provisioning directory, including any alerting provisioning files, before any upgrade or conversion. Store the copies outside the server being changed. Confirm you can restore them into a test environment, because the rollback path depends on them. The step is done when a restore has been tested and the backup location and timestamp are written into the change record.
Rebuild items that do not convert
Work through the unconverted log with each owner. Rebuild the affected alert rules and contact points directly in Grafana Alerting, or adjust the dashboard queries so the rule can be evaluated. Where a channel type has no equivalent, agree the replacement destination with the team and document it. The step is done when each logged item has a rebuilt counterpart, an owner sign-off and a note on any notification behavior that changed.
Upgrade a non-production copy
Apply the upgrade to a non-production copy built from the backup, and run the conversion there with the same options you plan to use in production. Compare the alert rule count, contact points and notification policies against the inventory. Confirm dashboards and their alerts still load for each team. The step is done when the copy matches the inventory with no unexplained differences, and the team has recorded the exact options used.
Run legacy and new alerting side by side
Keep both legacy and Grafana Alerting active so each team can compare behavior over a set period. The high availability documentation says that running more than one active server needs additional configuration to avoid duplicate notifications, so confirm that configuration is in place before enabling the parallel run. Check the notification log for any alert that reaches a person twice. The step is done when duplicate notifications are absent during the observation window and each team has accepted the comparison.
Verify firing and recovery notifications per team
For each team, trigger or wait for a controlled test alert in a non-critical rule, then confirm the firing notification reaches the intended contact point and that the recovery notification follows. Repeat the check for each notification policy route the team depends on. Record the test time, the recipients and the result. The step is done when every team has a recorded firing and recovery pass for every route it uses.
Cut over and retire legacy definitions
Cut over one team or folder at a time, disabling its legacy alerts only after its verification is signed off. Keep the legacy definitions in place until every team has cut over and the observation period has ended, then remove them. Keep the pre-cutover backup until the removal is confirmed. The step is done when all legacy alerts are disabled or removed, the backup is archived, and the change record names the owner for each cutover.

What drives the cost and duration of an alert migration

This table lists the factors that change how much work an alert migration takes, who is paid for each piece, and whether the cost is one-time or recurring. Use it to check a written quote against the estate you actually run, and to see which items you can reduce before the work starts.

Driver	Why it changes effort	Who is paid and one-time or recurring	What to ask for in a quote
Number of legacy alert rules and their data sources	Each rule needs review, conversion or rebuilding, and rules tied to several data sources take longer to verify.	Implementation partner or internal team, one-time. Effort scales with the rule inventory.	A rule inventory by data source, with a split between rules that convert directly and rules to rebuild.
Count and types of notification channels	Each channel needs a matching contact point, and some channel types need different settings or credentials.	Partner or internal team, one-time. Unusual channel types add research time.	A channel-by-channel mapping to contact points, with the channels flagged as needing manual setup.
Channels that do not convert	Channels without a direct equivalent must be rebuilt through another integration or replaced, which changes the plan.	Partner for design, internal team or vendor for replacement, one-time.	A list of non-converting channels and the proposed replacement for each, agreed before build.
Use of templates and custom message text	Custom templates and message text must be rewritten and checked against the new template syntax and the fields available to them.	Partner or internal team, one-time. Heavily templated alerts take the most review.	Count of templated alerts and a plan to test rendered messages for each.
Dependence on external Alertmanagers	Routing that depends on external Alertmanagers must be redesigned so notifications are not duplicated or lost during cutover.	Partner or platform team, one-time, with possible ongoing configuration upkeep.	A routing diagram for current and target state, and who owns each Alertmanager after cutover.
Number of teams and folders that own alerts	Ownership, folder permissions and sign-off must be agreed per team, so more owners means more coordination.	Internal team leads and the partner, one-time. Coordination time is often underestimated.	Ownership map by folder and team, with named approvers and a sign-off schedule.
Unsupported or third-party data source alerts	Alerts from data sources without Grafana-managed support may need separate conversion or stay in their source system.	Partner or internal team, one-time. May add recurring tooling to maintain.	Confirmation of each data source's alerting support, and a plan for any alerts left in place.
Database backend and HA setup	Alert state and configuration live in the database, and a high availability setup adds checks for duplicate notifications during cutover.	Partner or platform team, one-time for the check. Database operations are recurring and usually stay internal.	Confirmation of the database backend, the HA topology and the steps to verify no alert state is lost.
Testing against real notifications	Each route must be tested with live notifications to real recipients, which is often the largest share of verification time.	Partner and internal on-call staff, one-time. Repeated test rounds increase cost.	A test plan listing each route, the recipients used, the expected outcome and who signs off each result.

What usually goes wrong when legacy alerts move to Grafana Alerting

Most failures in a legacy alert migration are quiet: a notification never leaves, a rule fires at a different time, or a second server pages the same on-call group. Each card below names one risk, the step that prevents it, and the check that shows the step worked. Run the checks before cutover, not after the first missed page.

Notifications dropped from unconverted channels

Some legacy notification channel types do not convert to contact points during the upgrade. An alert can still show as firing while nothing reaches a person. Before you upgrade, list every channel type on each dashboard alert and compare it with the contact point types your target version supports. Rebuild each unsupported channel as a contact point, then send a test notification from the Grafana Alerting UI to each one. Confirm each test arrives at the real destination, not only at a placeholder.

Duplicate pages during the parallel run

Running legacy and Grafana-managed alerts side by side means the same condition can notify twice. Pause the legacy notifications for each rule at the moment its Grafana-managed copy goes live, and record the cutover time per rule. Keep a single owner for each on-call route during the overlap. The check is a replay: compare the notification log from both systems for one test firing and confirm exactly one page reached each responder.

Evaluation timing shifts after conversion

A converted rule can evaluate on a different interval, group or order than the dashboard alert it replaces, so a threshold breach may page minutes earlier or later. Export each source rule's evaluation interval and pending period, then set the same values on the Grafana-managed rule and its evaluation group. Check the first live evaluations against the legacy history for a known event. If timing matters for an SLA, confirm the differences with your own test data before you retire the old rule.

Permissions lost in folder moves

Moving alert rules into a different folder can change who can view, edit or silence them. Responders who could see a dashboard alert may find the new rule hidden, and rule owners may lose edit rights. Before moving anything, record the folder permissions and the roles that hold access to each rule. Apply the same grants to the target folder and test them with a user from each team. The check is a login as each role that confirms view, edit and silence access matches the baseline you recorded.

Backups taken after changes

A backup made after the upgrade captures the converted state, so it cannot restore the legacy alerts if the migration goes wrong. Take a full backup of the Grafana database and provisioning directory before you start, and store it outside the instance. Label it with the Grafana version and the date. The check is a restore test on a separate instance, confirming the legacy alert rules and channels reappear as they were before the upgrade.

Duplicate notifications from HA misconfiguration

Grafana high availability runs two or more active servers behind a load balancer, and the documentation notes that alerting needs extra configuration to avoid duplicate notifications. Without that setup, each node can send the same notification. Confirm the alerting high availability settings on every node before cutover, and confirm all nodes share one database. The check is to trigger a test alert and count the notifications received, which should match the number of expected pages.

What rollback restores and what it does not restore

Rollback is only as good as the backup it restores from. Before any upgrade to Grafana 10.4 or to a later major release, take a backup of the Grafana database, the provisioning directory and the configuration file, and record the exact Grafana version in use. A restore brings the instance back to the state captured at that moment: dashboards, legacy alert rules and their evaluation state, notification channels and the settings that tie them together. Confirm with the vendor documentation exactly which tables and files the rollback path reads and rewrites for the option you chose, because the preview and simple upgrade paths do not necessarily leave the same artifacts behind. Also confirm whether the clean_upgrade option removes legacy alert data, since a rollback after that point may have nothing to restore.

Some effects of the period after the backup cannot be undone by a restore. Notifications already delivered to email, chat, paging or webhook receivers stay delivered, and a restored instance may send them again if alert state is replayed, so plan how duplicates will be handled with the receiving teams. Silences, acknowledgements and annotations created after the backup disappear from Grafana, which can surprise on-call staff who relied on them. Changes made in external systems during the window, such as tickets opened from alert webhooks, edits to Alertmanager or Prometheus configuration, or changes to downstream routing, are outside Grafana and must be reconciled by hand. Dashboards edited by users during the window are also lost unless you merge them from another source.

Rehearse the restore on a copy before the production cutover. Restore the backup into a separate instance that uses the same database engine and the same plugins, then compare dashboards, alert rules, contact points and a sample of firing alerts against the production inventory. Time the restore and record each step so the change window is based on evidence. Ask the vendor or your database and platform team to confirm which steps are supported after the Grafana version has moved on, and keep the previous Grafana package and database snapshot available until the rehearsal has passed.

Questions teams ask before moving legacy Grafana alerts

What does a legacy alert migration cost?

The cost depends on how many dashboards carry legacy alerts, how many notification channels need to be rebuilt, and how much of the alert logic has to be reviewed by a person rather than converted automatically. Your internal staff time is a cost even when no vendor is involved, because alert owners must confirm that each converted rule still fires for the same conditions. A partner quote follows from a written scope that lists the alert count, the data sources behind them, the channels in use and the test environment. Ask any provider to itemize discovery, conversion, testing, cutover and post-cutover checks, and to state which items are one-time and which recur. No specific figure applies to every estate.

How long does a Grafana alert migration take?

Duration is set mainly by the number of alert rules, how many distinct teams own them, and how long your organization needs to test each notification path. Rules that use simple queries and standard contact points move faster than rules tied to custom plugins, unusual thresholds or chained expressions. Scheduling also matters: most teams want a test window where legacy and new alerts run side by side before the legacy path is switched off, and that window is usually governed by your change calendar rather than by the tooling. Ask for a plan that separates inventory, conversion, review, cutover and observation, and confirm how each stage depends on your owners' availability.

What does your team need to provide for the migration?

The work needs a named owner for each alert group, someone who can confirm what each rule is meant to detect and who should be paged. It also needs access to the notification endpoints such as email relays, chat webhooks, paging services and ticketing integrations, so that test notifications can reach real destinations without alerting production responders. Finally, it needs an agreed test window in which both the legacy and the Grafana Alerting path can be observed. Without these three inputs, converted rules often pass a syntax check but fail when they are first needed, so decide ownership before any conversion starts.

Can our internal team migrate legacy Grafana alerts alone?

Yes, a capable internal team can do this without a partner, provided it has working knowledge of Grafana, the data sources behind the alerts and the notification tools your responders use. The team should be comfortable reading PromQL or the query language of each data source, editing provisioned or UI-based alert rules, and testing contact points and notification policies. It also needs the authority to change alert behavior with the owning teams. Many organizations split the work: internal staff handle the inventory and ownership confirmation, while an outside specialist handles conversion, testing and documentation. Decide which of these you can staff before you commit to a plan.

What happens to notification channels that do not convert?

Some legacy notification channels have no direct equivalent in Grafana Alerting, or they require settings that must be recreated by hand. Each channel should be listed with its type, its destinations and its owners, then mapped to a contact point that performs the same function. Channels that cannot be mapped need a decision: replace them with a supported integration, route the alert through an external Alertmanager, or retire the alert if nobody still needs it. Secrets such as webhook URLs or API tokens must be re-entered and stored according to your secrets policy, so do not copy them into shared dashboards or documents. Confirm the full list of unsupported options against the Grafana documentation for the version you are moving to.

Can we roll back after the cutover to Grafana Alerting?

Rollback depends on how the cutover was run and what the upgrade option changed. If legacy alerts were kept in place during a preview period, returning to the legacy path can be a configuration change plus a restore of the pre-upgrade state, but only if you took a backup of the database and configuration before the change. If the upgrade converted and removed legacy alerts, a rollback restores what the backup contains, not any changes made afterward. Dashboards, alert states and notification history written after cutover may not return cleanly. Before cutover, confirm the exact rollback steps for your version, test them in a non-production copy, and record who can authorize a rollback during the observation window.

When does a support retainer make sense after the migration?

A retainer makes sense when the alerting platform needs regular attention after the migration rather than a one-time project. Typical triggers are the upgrade cadence of Grafana itself, which publishes major releases once a year and minor releases every other month, the need to review new alert rules as teams add services, and the need to keep notification integrations working as external tools change. Retainers are scoped in writing, so ask what is covered, such as patch review, rule audits, channel maintenance and on-call escalation, and what is outside the agreement. Compare that scope with the staff time you would otherwise spend on these tasks each month.

How DeployOpen scopes and delivers a Grafana alerting migration

DeployOpen treats a move from legacy dashboard alerts to Grafana Alerting as a fixed-scope piece of work on your own instance, inside your infrastructure. We start by inventorying every alert rule, notification channel and dependent dashboard, then build, test and document the migration so your team can run Grafana Alerting after handover.

How we scope

We inventory every legacy dashboard alert and notification channel on your instance before any conversion starts.
We flag channels and alert settings that will not convert, so the written scope names what your team must rebuild by hand.
We agree the upgrade path, preview approach and rollback plan in writing, with deliverables and timelines fixed before work begins.

How we build

We run the migration first on a copy of your instance so you can review converted rules and notification routing safely.
We test that converted alert rules evaluate and notify as expected, and we document any differences from the legacy behavior.
We set the clean_upgrade decision and rollback steps explicitly, and confirm what a rollback restores in your environment.

How we hand over

You receive a written record of every converted rule, contact point and notification policy, with its status and owner.
We document the cutover order, the list of items needing manual follow-up and the verification checks your team can repeat.
Your engineers walk through the runbook with us so they can manage Grafana Alerting without relying on DeployOpen.

How we support

Ongoing support, upgrades and continuous testing for your Grafana instance are available as a retainer after the migration closes.
Support can cover the move to later Grafana major releases, so alert behavior is retested with each upgrade you schedule.
Ask us to confirm the support scope, response expectations and upgrade testing in the written agreement before signing.

Migrate legacy Grafana alerts to Grafana Alerting