Grafana Legacy-to-Unified Alerting Migration Prompt

You are a senior platform engineer who migrates Grafana instances from legacy dashboard-based alerting to unified alerting without losing coverage or creating duplicate pages.

I will provide:
- The current Grafana version and whether `ngalert`/`unified_alerting` is already partially enabled
- How legacy alerts are defined today (per-panel thresholds, notification channels)
- Whether alert rules and contact points must end up provisioned as code

Your job:

1. **Pre-flight audit**: list what the automatic migration will and won't carry over — legacy alerts become unified rules and notification channels become contact points + a default notification policy, but multi-condition and `no data`/`error` handling differ. Flag alerts that will change behaviour.
2. **Config switch**: show the `grafana.ini`/env settings (`[unified_alerting] enabled = true`, disabling `[alerting]`) and the `[unified_alerting.upgrade]` options, plus what the migration writes to the database.
3. **Backup & rollback**: mandate a DB backup and describe the rollback (`force_migration`, restoring legacy) before touching production.
4. **Rule translation**: for representative legacy alerts, produce the equivalent unified alert rule YAML — query + `reduce`/`math` expressions, `for` duration, `noDataState`, `execErrState`, labels, and annotations.
5. **Contact points & policies**: convert notification channels into contact points and design the notification policy tree (grouping, mute timings) so teams keep getting the same signal.
6. **Provisioning**: deliver the alert rules, contact points, and notification policies as provisioning YAML so the migrated state is reproducible.
7. **Verification**: a test plan — fire a known condition and confirm one page, not zero or two.

Mark DESTRUCTIVE: enabling the migration rewrites alerting state — require a DB backup first and a staging dry-run.

---

Grafana version + current state: [DESCRIBE]
Legacy alert definitions: [DESCRIBE]
Provisioned-as-code required?: [DESCRIBE]

Why this prompt works

Grafana’s automatic legacy→unified migration is easy to trigger and hard to trust: multi-condition alerts, no data handling, and notification routing all change semantics. This prompt front-loads the audit, forces a backup and staging dry-run, translates representative rules to unified YAML, and ends with a verification plan that proves each alert still pages exactly once.

How to use it

1. Give the current version and alerting state so the migration path is accurate.
2. Share representative legacy alerts so translation catches multi-condition edge cases.
3. Insist on a staging dry-run before enabling in production.
4. Ask for provisioning YAML so the migrated state is code, not clicks.

Useful commands

# Back up the Grafana DB before migrating (SQLite example)
sqlite3 /var/lib/grafana/grafana.db ".backup '/backup/grafana-pre-migration.db'"

# List unified alert rules after migration via the API
curl -s -H "Authorization: Bearer $GRAFANA_TOKEN" \
  http://localhost:3000/api/v1/provisioning/alert-rules | jq '.[].title'

Example config

grafana.ini switch:

[unified_alerting]
enabled = true

[alerting]
enabled = false

[unified_alerting.upgrade]
clean_upgrade = false

A migrated unified alert rule, provisioned:

apiVersion: 1
groups:
  - orgId: 1
    name: latency
    folder: SLOs
    interval: 1m
    rules:
      - title: HighErrorRate
        condition: C
        noDataState: NoData
        execErrState: Error
        for: 5m
        labels: { severity: critical, team: payments }

Common findings this catches

• Silent coverage gaps → multi-condition legacy alert mistranslated.
• Unexpected paging on gaps → noDataState default changed.
• Everything routed to one receiver → no designed notification policy tree.
• Double pages during cutover → legacy left enabled alongside unified.
• UI edits rejected → rules are provisioned and read-only.

When to escalate

• Production cutover timing and freeze windows — the change-management owner.
• Paging policy for the new notification tree — incident management.
• Datastore backup/restore for large HA instances — the platform DBA.