Self-Hosted Observability Directory

Migration playbook

Replace Datadog with OSS observability

A phased path for moving metrics, logs, traces, dashboards, and alerting away from Datadog without losing operational coverage.

Vendor Datadog
Timeline 8-12 weeks
Difficulty High

Use this playbook when the mandate is broad Datadog cost reduction rather than a narrow tool swap. The safest path is parallel ingestion first, then alert and dashboard migration, then contract reduction.

Do not start with every dashboard. Start with incident-critical telemetry and keep Datadog as a comparison system until the new stack has survived at least one incident replay.

Recommended OSS Stack

Alertmanager

The deduplication, grouping, and routing layer for Prometheus alerts. Sends to PagerDuty, Slack, email, webhooks.

Apache-2.0 · Go · ★ 8500 · Fresh
alerts

Stack Options

OpenTelemetry-first all-in-one

Best for: Teams that want the smallest product surface while keeping traces, logs, and metrics in one workflow.

SigNoz · OpenTelemetry Collector

  • Fastest path to one UI, but ClickHouse operations become a core responsibility.
  • Great for application telemetry; infrastructure-specific Datadog integrations need explicit replacement.

Composable Grafana stack

Best for: Kubernetes-heavy teams that prefer independent storage systems and mature dashboarding.

Prometheus · Grafana · Grafana Loki · Grafana Tempo · Alertmanager · OpenTelemetry Collector

  • Best ecosystem depth, but more components to deploy, backup, and upgrade.
  • Requires dashboard and alert inventory work because Datadog monitors do not map 1:1.

Migration Phases

  1. Inventory Datadog usage

    1-2 weeks

    Outcome: A migration backlog grouped by metrics, logs, traces, dashboards, monitors, SLOs, and integrations.

    • Export monitor, dashboard, service catalog, log pipeline, and APM service lists.
    • Label each item as must-keep, consolidate, retire, or replace later.
    • Identify Datadog-only integrations that need exporters, webhooks, or custom collectors.

  2. Stand up parallel ingestion

    2-3 weeks

    Outcome: OpenTelemetry and native exporters feed the OSS stack while Datadog remains the source of truth.

    • Deploy OpenTelemetry Collector as the first hop for traces and logs where possible.
    • Scrape Prometheus-format metrics and forward legacy agent metrics through bridge collectors.
    • Apply retention, cardinality, and tenant boundaries before inviting broad usage.

  3. Rebuild the critical path

    3-4 weeks

    Outcome: Top dashboards, alerts, and incident workflows are recreated and checked against Datadog.

    • Port the top 20 incident dashboards and annotate known query differences.
    • Recreate page-worthy monitors first, then tune noisy informational alerts.
    • Run weekly incident replay reviews against both systems.

  4. Cut over and reduce spend

    2-3 weeks

    Outcome: Teams use the OSS stack for day-to-day operations and Datadog retention is reduced or cancelled.

    • Move runbooks, links, and on-call references to the OSS dashboards.
    • Lower Datadog retention and indexed log volume only after owners sign off.
    • Keep an export of retired monitors and dashboards for auditability.

Cutover Checklist

  • Top revenue service dashboards render in the OSS stack.
  • Page-worthy alerts fire through the existing on-call path.
  • Trace, log, and metric correlation works for at least three critical services.
  • Retention and cardinality budgets are documented.
  • Every Datadog integration has an owner decision: replace, retire, or defer.
  • Incident commanders can find the new dashboards from runbooks.

Risks To Manage

  • High-cardinality tags can make Prometheus, Loki, ClickHouse, or Tempo expensive if copied blindly.
  • Datadog monitor semantics often need manual translation rather than direct query conversion.
  • Infrastructure integrations may require exporters that were previously bundled in the Datadog Agent.

Back to migration playbooks