Grafana Dashboard Migration Between Orgs Prompt

You are a senior Grafana admin who migrates dashboards and folders across orgs and instances without breaking them.

I will provide:
- Source and target orgs/instances and their data sources
- The dashboards/folders to move
- Whether this is a one-time move or recurring sync

Your job:

1. **Inventory**: list source dashboards and folders via `/api/search`, and capture each dashboard's JSON via `/api/dashboards/uid/<uid>`.
2. **Map data sources**: the biggest risk — data source UIDs differ per instance; build a UID mapping and rewrite `datasource` references (or use `${DS_*}` input variables on import).
3. **Recreate folders**: create matching folders in the target via `/api/folders` and capture the new folder UIDs.
4. **Strip instance-specific fields**: remove `id`, set `version` handling, and null out `uid` if you want new IDs (or keep uid to preserve links).
5. **Import**: POST to `/api/dashboards/db` with `overwrite` and the target `folderUid`, remapping inputs.
6. **Preserve links and variables**: fix data links, dashboard links, and library panel references that point at source UIDs.
7. **Verify**: open each imported dashboard, confirm panels render and variables populate against the target data sources.
8. **As code**: for recurring sync, manage via Terraform provider or Grizzly instead of manual API calls.

Mark DESTRUCTIVE: overwriting existing target dashboards (data loss), importing with wrong datasource UIDs (silent empty panels), deleting source before verifying target.

---

Source/target orgs: [DESCRIBE]
Dashboards/folders: [DESCRIBE]
One-time or recurring: [DESCRIBE]

Why this prompt works

Dashboard migration looks like copy-paste JSON but silently fails on data source UID remapping — the panels import fine and render nothing. This prompt centers the UID mapping, folder recreation, and link/library-panel fixes, plus a verify-before-delete discipline, which is what separates a clean migration from a day of empty panels.

How to use it

1. List both instances’ data sources so the assistant can build a UID map.
2. Specify preserve-UIDs vs new-UIDs based on whether links must survive.
3. Say one-time vs recurring so it picks API scripting or as-code tooling.
4. Ask for a verification checklist before any source cleanup.

Useful commands

# 1. Inventory and export a source dashboard
curl -s -H "Authorization: Bearer $SRC_TOKEN" \
  "http://src:3000/api/search?type=dash-db" | jq '.[].uid'
curl -s -H "Authorization: Bearer $SRC_TOKEN" \
  "http://src:3000/api/dashboards/uid/$UID" | jq '.dashboard' > dash.json

# 2. Create the target folder
curl -X POST http://dst:3000/api/folders \
  -H "Authorization: Bearer $DST_TOKEN" -H "Content-Type: application/json" \
  -d '{"title":"Payments"}'

# 3. List target data source UIDs for the remap
curl -s -H "Authorization: Bearer $DST_TOKEN" \
  http://dst:3000/api/datasources | jq '.[] | {name, uid}'

Example config

// Import payload: remap datasource inputs and target folder
{
  "dashboard": {
    "uid": null,
    "id": null,
    "title": "Payments Overview",
    "__inputs_note": "replace source ds refs before POST"
  },
  "folderUid": "target-payments-folder-uid",
  "overwrite": false,
  "inputs": [
    { "name": "DS_PROMETHEUS", "type": "datasource",
      "pluginId": "prometheus", "value": "prom-target-uid" }
  ]
}

Common findings this catches

• Empty panels → data source UIDs not remapped.
• Data loss → overwrite: true on an existing dashboard.
• Broken links → data links/library panels still point at source UIDs.
• UID collisions → preserved UID already used in target.
• Missing permissions → folder ACLs not reapplied.
• Import conflicts → stale id/version fields left in JSON.
• Premature deletion → source removed before target verified.

When to escalate

• Recurring cross-org sync — standardize on Terraform/Grizzly, not manual API.
• Permission/RBAC model differences between orgs — access governance.
• Large migrations with hundreds of dashboards — stage and validate in batches.