Migrate from Datadog to Prometheus and Grafana

Migrate from Datadog to Prometheus and Grafana: what the work involves

If a Datadog renewal, a pricing change or a residency requirement has pushed you toward self-hosting, the move is mainly a rebuild of metrics collection, dashboards and alert rules, not a data copy. Datadog's dashboards and monitors cannot be imported directly into Grafana or Prometheus, so each one has to be exported as a reference, reviewed and recreated against the new data sources. Unless you plan a backfill, the historical metrics stay in Datadog for as long as your Datadog contract keeps them accessible, and your Grafana panels will start with an empty history on the day they go live. The work is usually done by a platform or SRE team, often with an implementation partner that handles the Collector pipelines, the Prometheus and Grafana deployment and the alert translation. Your internal team still owns the decisions that matter most: which services and hosts are in scope, which Datadog monitors are still needed, who receives each alert, and what retention you need. Effort depends mainly on how many hosts, integrations and custom metrics you run and how many dashboards and monitors have accumulated over time. Ask any partner to size the work from a written inventory of those items rather than from a headline number, and confirm which of your Datadog integrations have a Prometheus exporter or an OpenTelemetry receiver before you commit to a timeline.

Risk concentrates in three places. The first is alert coverage: a monitor that fires on a Datadog-specific metric or a log query will not have a one-to-one equivalent, so inventory every monitor and mark it as rebuilt, retired or replaced by a different signal before cutover. The second is dual running: keep the Datadog Agent or Collector exporting to Datadog while Prometheus and Grafana prove out, so you can compare series and alert behavior side by side. The third is storage. Prometheus local storage is a single node that is not clustered or replicated, and its default retention is 15 days, so decide early whether you need remote write to long-term storage and how that changes your operating model. Plan these checks as a documented cutover runbook with named owners.

Which Datadog capabilities map cleanly to Prometheus and Grafana

This table maps each Datadog capability in scope for this migration to its Prometheus, OpenTelemetry Collector, Grafana or Alertmanager equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes, because most rework sits in tags, monitor logic and identity rather than in metric collection itself.

Datadog capability	Open-source equivalent	Status	What to confirm or plan for
Infrastructure metrics from the Datadog Agent	Prometheus scraping node_exporter or OpenTelemetry Collector metrics over OTLP	Clean	Confirm each Agent check has an exporter or receiver. Plan for pull-based scraping and the Collector's host metrics receiver.
Agent integrations (checks)	Exporters, Prometheus scrape configs and Collector receivers per technology	Needs rework	Each integration is rebuilt separately. Inventory every enabled check before cutover, since no single component replaces all of them.
Host and service tags	Prometheus labels set through relabeling and Collector resource attributes	Needs rework	Tag names and cardinality may not carry over one to one. Decide the label schema first, because dashboards and alerts depend on it.
Dashboards	Grafana dashboards, exported Datadog JSON used as a reference for rebuilds	Needs rework	Datadog widget JSON does not import as Grafana panels. Rebuild queries in PromQL and keep the exported JSON as the specification.
Monitors	Prometheus alerting rules evaluated by Prometheus and routed by Alertmanager, or Grafana-managed alerts	Needs rework	Translate thresholds, evaluation windows and no-data behavior by hand. Test each rule against historical data during dual-shipping.
Notebooks and downtimes	Grafana dashboard annotations, Alertmanager silences and maintenance scheduling in your own tooling	Gap	No direct equivalent for notebooks. Downtimes map to silences, which expire and need a process to recreate them on a schedule.
Users, roles and SSO	Grafana authentication with LDAP, generic OAuth, Entra ID, Okta or Google, and Grafana Enterprise for SAML and team sync	Needs rework	The authentication docs list SAML, team sync and SCIM as Grafana Enterprise or Grafana Cloud features. Confirm which identity method your edition supports before design.
Metric accuracy guarantees	Prometheus sampling and PromQL with reliability favored over precision	Gap	Prometheus documents that it is not suited to 100% accuracy, such as per-request billing. Keep any exact-count workload on a system designed for it.

What can leave Datadog and what must be rebuilt

Dashboards can be exported as JSON and reused as a reference, but most of the Datadog estate has to be recreated in the open-source stack. Metrics history has no supported bulk export, so each component below needs a decision about what is rebuilt, what is backfilled and what stays in Datadog.

Dashboard definitions as JSON

Datadog exposes dashboard definitions as JSON through its API, so each dashboard can be saved as a reference file before cutover. The JSON describes widgets and queries in Datadog's own format, so PromQL and Grafana panels must be written by hand. Check which dashboards depend on Datadog-only functions or template variables, and record the owner of each dashboard before rebuilding it in Grafana.

Metrics history has no bulk export

Datadog does not offer a supported bulk route for exporting raw metrics. Historical series either stay readable in Datadog for the period you still need, or are backfilled from your own sources such as a data warehouse or long-term store that you already control. Confirm with Datadog support which metrics and retention windows apply to your account before you set a cutover date.

Agent integrations as Collector receivers

Each Datadog Agent integration, such as a database or web server check, must be matched to an OpenTelemetry Collector receiver or a Prometheus exporter. Coverage differs by integration, so list every enabled check from your Agent configuration and mark those with no equivalent. The Collector runs with its contrib distribution, which is where most receivers live, and each receiver's stability level should be checked in its README.

Prometheus scrape configs and service discovery

Hosts and containers that Datadog discovered automatically must be declared in Prometheus scrape configs, either as static targets or through service discovery for Kubernetes or cloud APIs. Tags that drove Datadog filtering become labels, and label naming must be fixed early because dashboards and alerts depend on it. Plan the scrape interval and the number of series per target, since high-cardinality labels drive storage use.

Alertmanager routing and receivers

Datadog monitor notifications and their routing to teams and channels must be rebuilt as Alertmanager routes, receivers and inhibition rules. Grouping and silences work differently from Datadog's notification settings, so a monitor that paged one team may need a new route. Prometheus should point at every Alertmanager instance, and a clustered setup needs its own testing before it takes over paging.

Grafana data sources and provisioning files

Grafana data sources, dashboards and alerting resources can be defined in YAML or JSON files loaded at startup, which keeps the rebuilt estate in Git rather than in clicks. Store the configuration in MySQL or PostgreSQL for production, since SQLite does not scale for production. Keep dashboard JSON exports in the same repository so reviewers can compare the old Datadog definition with the new Grafana one.

Users, roles and SSO

Datadog users, roles and team memberships do not move automatically, so each role must be mapped to a Grafana role and team. Grafana supports LDAP, generic OAuth, Entra ID, Okta and other identity sources in every edition, but SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Confirm which of these your identity provider requires before you map access.

Migration sequence from inventory to decommission

This sequence moves Datadog metrics, dashboards and monitors to Prometheus and Grafana in controlled stages, so each team can prove alert parity before it stops relying on Datadog. It produces a retirement record that shows exactly what was moved, verified and switched off.

Build the inventory register
Platform engineering exports the list of monitored hosts, Datadog integrations, custom metrics, dashboards and monitors, then assigns each item an owning team. Dashboard definitions can be pulled as JSON through the Datadog API, which gives you a reference for rebuilds, but metrics and monitor state have no bulk export, so confirm each item's query by hand. The output is an inventory register with one row per host group, integration, dashboard and monitor, marked as keep, rebuild or retire. The step is done when every owning team has signed off its rows.
Run a pilot on one service group
Choose a small, low-risk service group and deploy the OpenTelemetry Collector as an agent on those hosts, with a Prometheus scrape or OTLP path into Prometheus and a Grafana data source. Rebuild two or three representative dashboards from the exported JSON and translate their monitors into Prometheus alert rules routed through Alertmanager. The output is a set of pilot dashboards and a short list of gaps, such as metrics the integration did not expose in the same form. The pilot is done when the on-call engineers for that group can answer their usual questions from Grafana.
Run both backends in parallel
Configure the Collector pipeline to export the same metrics to Datadog and to Prometheus, and keep the Datadog Agent running where it still covers workloads that have not moved. Datadog accepts OTLP from a standard Collector pipeline, so the two backends receive identical samples during this window. Compare alert behavior by running each rebuilt Prometheus alert beside its Datadog monitor and recording where they fire differently. The output is alert parity checks, one per monitor, with the cause of every mismatch. Prometheus stores data locally with a default 15-day retention, so decide early whether longer history needs remote write to external storage.
Write the cutover runbook per team
For each owning team, write a cutover runbook that lists the hosts to switch, the dashboards and alert rules that replace Datadog, the notification channels to re-point, and the rollback steps. Include who approves the switch and who watches the first on-call shift afterwards. Grafana high availability needs two or more active-active servers behind a load balancer sharing MySQL or PostgreSQL, so confirm that the production Grafana is set up that way before any team depends on it. The output is one signed runbook per team, reviewed against the parity checks from the previous step.
Cut over each team in turn
Teams move one at a time, following their runbook. On cutover day the Collector stops exporting to Datadog for that team's hosts, Datadog monitors for those services are muted rather than deleted, and Prometheus alerts are confirmed to reach the right channels with a test notification. Keep the Datadog monitors muted for a review period agreed in advance by the team, so a rollback is possible. The output is a cutover log with the time, the person approving and any rollback. The step is done for a team when its runbook is closed and no alert is routed only through Datadog.
Decommission the Agent and subscriptions
When every team has cut over, remove the Datadog Agent from the hosts, delete the API keys it used, and remove the Datadog integrations. The Datadog Agent source is open under Apache-2.0 for its user space components and GPL-2.0 for its eBPF code, but the Datadog backend and UI are not open source, so the subscription itself ends only through Datadog's contract process. Ask Datadog in writing to confirm the notice terms, data retention after cancellation and whether any dashboards or history need exporting first. The output is a retirement record listing removed agents, revoked keys, closed integrations, the contract end date and where archived dashboard JSON is stored.

How to run Datadog and Prometheus in parallel during cutover

The safest way to cut over is to send the same telemetry to both platforms for a period, so each Prometheus metric and Grafana panel can be checked against its Datadog counterpart before anyone relies on it. Datadog accepts OpenTelemetry data in three ways: through the Datadog Agent with its DDOT Collector, through a standard OpenTelemetry Collector pipeline exporting over OTLP, or by direct OTLP ingestion. A single OpenTelemetry Collector can fan out to both, using an OTLP exporter for Datadog and a Prometheus exporter or the Prometheus OTLP receiver for the new stack. Confirm which Datadog ingestion path your account and site support, and check how Datadog maps OpenTelemetry resource attributes, since names and tags may differ from what Datadog Agent integrations emitted.

Start the comparison with metric names and labels, not dashboards. Query the same service in Prometheus and Datadog for request rate, error rate and latency, then record where the names, units, histogram buckets and label sets diverge. Dashboards and alert thresholds are easier to rebuild once that mapping is written down. For alerts, run each translated Prometheus alert rule alongside its Datadog monitor and log every firing and recovery with timestamps. Differences in evaluation windows and notification routing between Alertmanager and Datadog will show up here, so treat them as findings to resolve rather than noise. Prometheus keeps local data for 15 days by default, and its storage is single-node and not replicated. Plan comparison windows with that limit in mind: if you want to compare a monthly pattern, such as a batch job or billing cycle, you need to either extend local retention with a size or time setting or accept that the comparison covers less history than Datadog holds. Remote write to long-term storage is a later decision, and it can wait until the parallel run shows which metrics and label cardinality you actually need to keep. Confirm your storage sizing and retention requirements with the people who own the audit and incident review process before the Datadog agents are switched off.

How the migration differs by estate size and starting point

A single team running the Datadog Agent on a handful of hosts with a few integrations usually has a narrow surface to move. The main effort is inventory and translation rather than infrastructure: listing which hosts report, which integration checks are enabled, which dashboards and monitors the team actually uses, and which ones were created once and never looked at again. Because the footprint is small, one Prometheus server with local storage and one Grafana instance may be enough to start, and the team can run both pipelines side by side for a short period while it compares series and alerts.

Agent inventory: List every host running the Datadog Agent and every enabled integration, then map each to a Prometheus exporter or OpenTelemetry receiver.
Dashboard triage: Export dashboard JSON as a reference, then rebuild only the panels the on-call and service owners still read.
Monitor translation: Rewrite each active monitor as a Prometheus alert rule and route it through Alertmanager, dropping monitors that duplicate each other.
Single-node sizing: Prometheus local storage is not clustered or replicated, so decide early whether one node and a backup plan are acceptable for this estate.
Operator ownership: Name one owner for Prometheus, Grafana and the Collector, since the team will carry patching and upgrades that Datadog previously handled.

Before cutover, confirm with your team which dashboards and alerts are actually used and which can be retired without losing coverage.

What drives the cost and duration of the move

Most of the effort in this move comes from how much Datadog is actually doing for you today, not from the open-source software itself. The cards below cover the inventory, the discipline of your tags and metrics, retention, and the parallel run, which together set the one-time work, the dual-running period and the staff time that continues after cutover.

Hosts and integrations in scope

Every host, container, cluster and Datadog integration you monitor needs a collector path, a scrape target or a dashboard that replaces it. Count hosts and integrations by type, then mark which ones are covered by the OpenTelemetry Collector receivers and Prometheus exporters and which need custom configuration. Ask any implementation partner to price per integration group rather than as a single block, so gaps show up in the quote.

Dashboard and monitor count

Each Datadog dashboard and monitor is rebuilt by hand or translated from exported JSON, then tested against live data. Export dashboard definitions through the Datadog API as a reference, then group them by owner and usage so retired views are not rebuilt. Ask for a quote that states the number of dashboards and alert rules in scope and how many are expected to be retired.

Tag and label discipline

Datadog tags are attached at query time, while Prometheus labels are fixed per series and shape how every PromQL query is written. Inconsistent host, service and environment tags will need a mapping table before dashboards can be rebuilt once. Clean naming in the Collector's resource attributes before cutover usually costs less than correcting queries across many dashboards afterward.

Custom metric cardinality

High-cardinality custom metrics, such as series labeled with user IDs, request IDs or unbounded paths, are the main source of storage and memory growth in a self-hosted Prometheus server. Prometheus documents that local storage is a single node and must be managed like any other database, so cardinality directly affects sizing. Review top series by metric name before migration, drop or aggregate labels that are not used in alerts, and ask the partner to state how cardinality was measured.

Retention and long-term storage

Prometheus keeps local data for 15 days by default, and that is configurable by time or size. Teams that rely on Datadog history for capacity planning or audits need an external long-term store such as remote write to a system like Grafana Mimir, which is AGPL-3.0-only. Decide retention per metric class before sizing, because object storage and compute for that tier recur every month.

Parallel run and staff availability

Dual-shipping OpenTelemetry data to Datadog and the self-hosted stack keeps alerting safe during cutover, but every week of overlap adds Datadog charges and the work of comparing two sets of results. Your own engineers must review dashboards, tune alert thresholds and own on-call runbooks, and their availability often sets the schedule more than the software does. Ask for the parallel-run length, the named staff roles and what happens if a cutover milestone slips.

Questions buyers ask before moving from Datadog

Can our team migrate from Datadog to Prometheus and Grafana without outside help?

Yes, a team with Kubernetes or Linux operations experience and some PromQL knowledge can do it alone, but the work is more than a configuration change. The main effort is replacing the Datadog Agent with the OpenTelemetry Collector, rebuilding dashboards and translating monitors into Prometheus alert rules, then running both pipelines in parallel. Prometheus stores data on a single node by default, so someone must own storage, backups and retention from day one. Before deciding, confirm your team's capacity for on-call ownership of the stack, your number of hosts and services, and how many Datadog monitors you actually use.

What does outside help from DeployOpen cover in this migration?

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For this move, that can include designing the OpenTelemetry Collector pipelines, deploying Prometheus, Alertmanager and Grafana, setting up provisioning and high availability, translating monitors into alert rules, and documenting the cutover. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing upgrades and support are available as retainers. A quote follows from the written scope, so ask for the exact list of dashboards, monitors and services included.

How long does a Datadog to Prometheus and Grafana migration take?

The timeline depends on the number of services instrumented, the number of dashboards and monitors you need to rebuild, the state of your current Datadog Agent configuration, and how long you run both systems side by side. None of the supplied research gives a duration, so treat any figure you hear from a vendor or partner as something to verify against your own inventory. Ask for a written plan that breaks the work into instrumentation, dashboard rebuilds, alert translation, parallel running and decommissioning, with an owner and exit criteria for each phase.

Can we keep our Datadog dashboard and monitor history after leaving?

You can export dashboard definitions as JSON through the Datadog API and use them as a reference for rebuilding dashboards in Grafana, but they will not import directly. Historical metric data does not have a bulk export path in the same way logs do, so plan on a retention window in Prometheus that matches your needs, and keep the Datadog data you must retain under your own control. Confirm with your compliance owner which records must survive the move, and check your Datadog contract for data retention terms before you cancel.

Do we need Grafana Enterprise to use single sign-on with Grafana?

Not for every provider. According to Grafana's authentication documentation, all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your identity provider requires SAML or you need SCIM-based user provisioning, budget for Enterprise licensing and confirm the current terms with Grafana Labs. Check your identity provider's supported protocols before you finalize the design.

How do we verify that alerting in Prometheus matches our Datadog monitors?

Parity is verified by testing, not by assumption. Build an inventory of every Datadog monitor with its query, threshold, evaluation window, notification target and owner, then translate each one into a Prometheus alert rule routed through Alertmanager. During parallel running, compare when each rule and monitor fires against the same telemetry, and test notification delivery end to end. Alertmanager supports grouping, inhibition and silences, so confirm that routing and suppression behave as your on-call process expects. Prometheus values reliability over precision and is not suited to workloads that require 100% accuracy, such as per-request billing, so exclude those from automated parity checks.

What must our team provide before the migration starts?

Your team needs to supply access and decisions that only you can give:

An inventory of hosts, Kubernetes clusters, services and the Datadog Agent configuration in use
Exports of dashboards and monitors, plus the owners and notification routes behind each one
Cloud accounts, data centers or network segments where the stack will run, and storage budget for retention
Identity provider details for Grafana access, and the decision on whether SAML is needed
Named owners for on-call, change approval, and sign-off on cutover criteria

Confirm these items in your own environment before asking for a quote, since they determine scope.

Will running Datadog and Prometheus in parallel cost more during cutover?

Yes, parallel running adds cost because you pay for Datadog usage and for the self-hosted infrastructure at the same time. Datadog is billed per host and per data volume, so the overlap period matters. Self-hosted costs include compute, object storage for long-term data if you use remote write, backups and the staff time to operate both. Shorter overlap windows reduce Datadog spend but increase the risk of gaps in alerting, so agree the exit criteria up front. Ask your Datadog account team which billing terms apply to a shortened contract, and ask for a quote that shows dual-running costs as a separate line.

Official sources for the migration

Start with the vendor and project documentation before you change any production agent or dashboard, because the behavior you rely on is defined there and can change between releases. For the Datadog side, read the OpenTelemetry in Datadog documentation to confirm which paths Datadog accepts for OpenTelemetry data: the Datadog Agent with its DDOT Collector, a standard OpenTelemetry Collector pipeline exporting over OTLP, or direct OTLP ingestion. That choice decides whether your first step is replacing the Agent or only adding an export path, and it determines how long dual-shipping must run. For the receiving side, the Prometheus OTLP receiver is the setting that matters. The Prometheus guide on using Prometheus as an OpenTelemetry backend explains that OTLP metrics are accepted at the /api/v1/otlp/v1/metrics path when Prometheus starts with --web.enable-otlp-receiver. Confirm the flag and the endpoint against the Prometheus version you deploy, and check the Prometheus release cycle and long-term support page to choose a line that receives bug fixes for the period you need. Pick the Collector build and component stability levels from the OpenTelemetry Collector configuration docs, and review the Collector configuration best practices before exposing any receiver. For dashboards and alert rules, use the Grafana provisioning documentation to decide how rebuilt data sources, dashboards and alerting resources will be stored and loaded at startup. Test each provisioning file in a staging Grafana instance, and record the Grafana and Prometheus versions you validated so the evidence for your change record is reproducible. Where the docs do not answer a question for your environment, ask the vendor or project directly and document the answer.

Migrate from Datadog to Prometheus and Grafana