| name | migrate-all-supported-assets |
| description | Use when the user has decided to fully switch and wants to "migrate everything", "do the whole environment", "migrate all my dashboards and alerts", or a complete cutover — bulk-migrates EVERY supported dashboard and/or alerting rule from a connected Grafana or Datadog environment into Kibana in one sweep, and reports exactly which assets could not migrate. For a chosen subset use migrate-selected-assets; for a single proof dashboard use try-one-source-dashboard. |
Migrate every supported dashboard / alerting rule
Audience: operators of the published obs-migrate CLI (PyPI/uvx), using public docs and their real source + Elastic/Kibana — not a repo lab harness.
Goal: migrate everything the engine supports from a source in one run, then give the user a straight account of what landed and what could not migrate. This is the full-sweep step for teams that have already assessed readiness and decided to switch.
This skill writes all supported assets to the target. It is otherwise read-only on the source.
Prerequisites (install)
These skills help operators of the published CLI (not a repo checkout).
If obs-migrate is missing or doctor is not Ready, follow
install-obs-migrate first — that skill owns PyPI/uvx/pip, extras, and
Python/uv gotchas. Do not invent alternate install commands here.
uvx --from 'elastic-observability-migration[all]' obs-migrate doctor
Source/Elastic credentials: connect-to-o11y-source (and your env exports).
Core fact: "all" is the absence of a selector
There is no --all flag. A bulk migration is simply --assets all (or --assets dashboards / --assets alerts) with no id/query / --select-* selector — the engine then processes the full set the source returns and reports the ones it cannot translate. Unsupported assets are surfaced, never silently dropped (degrade-gracefully).
--assets dashboards → every supported dashboard, no alert artifacts.--assets alerts → every supported rule/monitor, no dashboard YAML.--assets all → both isolated pipelines in one command (the union). Look for both …/dashboards/ and …/alerts/ under the output dir.
Step 1 — Run the full migration
Datadog, everything, live API (creates rules disabled + tagged in the same run):
export ELASTICSEARCH_ENDPOINT="https://...es..." KIBANA_ENDPOINT="https://...kbn..." KEY="<api-key>"
export DD_API_KEY="..." DD_APP_KEY="..." DD_SITE="datadoghq.com"
obs-migrate migrate \
--source datadog \
--input-mode api \
--env-file datadog_creds.env \
--output-dir full_out \
--assets all \
--field-profile otel \
--data-view "metrics-*" \
--es-url "$ELASTICSEARCH_ENDPOINT" --es-api-key "$KEY" \
--kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" \
--upload \
--create-alert-rules
Grafana, everything, live API:
export GRAFANA_URL="https://grafana.example.com" GRAFANA_USER="..." GRAFANA_PASS="..."
obs-migrate migrate \
--source grafana \
--input-mode api \
--output-dir full_out \
--assets all \
--data-view "metrics-*" \
--esql-index "metrics-*" \
--es-url "$ELASTICSEARCH_ENDPOINT" --es-api-key "$KEY" \
--kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" \
--upload \
--create-alert-rules
--upload pushes dashboards via the typed Dashboards API (in-memory / persisted native/*.native.json payloads). That is the only upload path — there is no YAML/NDJSON compile step and no external tool to install. --create-alert-rules creates the emitted rules disabled and tagged obs-migration.- Drop
--upload / --create-alert-rules for a dry, target-aware translation pass first; add them once the readout looks right. You can also split into two runs: produce artifacts, inspect full_out/dashboards/native/*.native.json (upload payload) and full_out/dashboards/ir/*.ir.json (translator decisions, inspection-only), then obs-migrate upload --artifact-dir full_out/dashboards.
- Without
--create-alert-rules, alert translation still writes monitor_migration_results.json (Datadog) / equivalent Grafana alert artifacts — not monitor_rule_upload_results.json / alert_rule_upload_results.json (those appear only when rules are created in Kibana).
- File-based sources: swap
--input-mode api for --input-mode files --input-dir <dir> pointing at all exported dashboard JSON.
- Custom-CA / self-signed clusters:
--ca-cert <path> (env OBS_MIGRATE_CA_CERT) verifies against a private CA; --insecure (env OBS_MIGRATE_INSECURE) skips verification for testing only. Both cover source, Elasticsearch, and Kibana (including the dashboard upload).
Step 2 — Read what landed and what did NOT
The whole point of a bulk run is the coverage report. Read it; do not assume exit 0 means every asset is perfect.
| What you want | File | Field(s) |
|---|
| Human-readable verdict + per-dashboard table + must-fix worklist | full_out/dashboards/migration_summary.md | verdict, scorecard, must-fix list, grouped warnings |
| Dashboard coverage buckets | full_out/dashboards/migration_report.json | summary (counts), readiness buckets |
| Per-panel status / why a panel didn't migrate | full_out/dashboards/migration_manifest.json | panels[].status, panels[].reasons; Grafana type: panels[].grafana_type; Datadog widget type: panels[].datadog_widget_type |
| Which asset families ran | full_out/run_summary.json | top-level summary |
Alert translation (always for --assets alerts|all) | full_out/alerts/monitor_migration_results.json (Datadog) | tiers / kinds / failures |
Alert rule creation results (only with --create-alert-rules) | full_out/alerts/monitor_rule_upload_results.json (Datadog) / full_out/alerts/alert_rule_upload_results.json (Grafana) | created / failed / skipped |
The dashboards that cannot migrate appear as non-clean entries in migration_summary.md and as requires_manual / not_feasible panels (with reasons) in the manifest. Panels that migrated with warnings (accepted approximations such as histogram_quantile → PERCENTILE) are also non-clean — triage with explain-migration-gaps rather than counting them as hard failures by default. Alerts that cannot be emitted are reported in the alert artifacts. Relay these explicitly — that list is the deliverable, not an afterthought.
Step 3 — Verify and hand off the gaps
- State the coverage: how many dashboards/panels and rules migrated cleanly vs. warned vs. need rework, straight from the summary/report.
- For broken/empty uploaded panels, hand off to the
debug-uploaded-kibana-dashboard skill (captures real ES|QL and classifies render_error vs field/data gaps).
- For warned or blocked panels, use
explain-migration-gaps — it separates accepted approximations from redesign work.
- Stronger gates when staking a cutover claim:
obs-migrate verify / validate-side-by-side, verifier.live_validate, verifier.dashboards_api, and render audit (https://github.com/elastic/observability-migration-platform/blob/main/docs/testing.md) — the last is the only gate for Lens accessor / "invalid column" / empty-state failures that ES|QL execution misses.
- Migrated rules are disabled; review with
obs-migrate audit-rules before enabling (review-and-enable-migrated-alerts).
Honest limits (tell the user)
- Exit 0 ≠ everything is perfect. The run can succeed while individual panels are
requires_manual / migrated_with_warnings / empty. Trust the report, not just the exit code.
- Grafana API extraction is capped at 500 dashboards per search request — a very large org may not be fully covered in one API pass; note it and consider file exports for the remainder.
- No
--es-url ⇒ no live validation. A target-less run still translates and reports, but does not prove panels render against real data.
- Created rules are disabled. A bulk alert migration arms nothing; rules are disabled and tagged
obs-migration until enabled by a human.
- Empty panels are often missing data, not a bug. A clean translation renders empty without matching telemetry in the target; use
prepare-target-telemetry and/or obs-migrate seed-sample-data (auth flag --api-key, defaults to env KEY — not --es-api-key).
- Degrade gracefully: unsupported assets are surfaced with reasons, never hidden — that is the contract.
Do NOT
- Do not report "migrated everything" without reading the coverage report and naming what could not migrate.
- Do not treat exit 0 as proof every panel is correct.
- Do not claim a bulk alert migration enabled rules — it creates them disabled.
- Do not invent flags. Bulk =
--assets all with no selector; confirm with obs-migrate migrate --help.
- Do not cite manifest fields you have not confirmed (e.g.
grafana_type exists on Grafana manifest panels; open the JSON when unsure).
See also
install-obs-migrate — install/doctor when the CLI is missing or not Ready.assess-migration-readiness skill — run this first to know how much will migrate (and at what evidence level) before sweeping.migrate-selected-assets skill — migrate a chosen subset instead of everything.explain-migration-gaps skill — plain-language triage of warned vs blocked panels.debug-uploaded-kibana-dashboard skill — diagnose individual broken uploaded panels after the sweep.prepare-production-cutover skill — go/no-go after the sweep + validation.revert-migration skill — remove the generated dashboards/rules if the user backs out.obs-migrate migrate --help — authoritative asset/upload flags for the installed version.https://github.com/elastic/observability-migration-platform/blob/main/docs/command-contract.md — asset-scope contract and artifact descriptions (online docs / repo).https://github.com/elastic/observability-migration-platform/blob/main/docs/testing.md — layered verifier and render-audit gates.
