Datadog Migration Guide: 8 Key Considerations

Organizations like yours have struggled with soaring Datadog bills for years now. Costs continue to rise while the concerns you raise with your vendor go ignored — there is no incentive for Datadog to change its pricing model, especially when they know their customers feel locked into their proprietary tool and believe migrating to a new vendor is too cumbersome to contemplate.

Meanwhile, value is diminishing. In the words of one Datadog user: “With Datadog, we were seeing costs compound over years and escalate unexpectedly without much benefit.” But the thought of migrating off Datadog and onto a platform that offers more value and lower costs can seem too daunting to contemplate, and so the cycle continues.

The good news is that with a plan in place and with experts guiding you along the way, switching observability platforms is within reach.

Read below for 8 considerations to start executing on your Datadog migration.

You should start thinking about a Datadog migration as early as possible, but the actual timing depends heavily on the scale of the migration. Tools such as timeline calculators can estimate how long the migration itself might take, but they might not account for the pre-planning phase—the time you need before you “kick something off.” That planning window varies based on how many assets you have and the size of your telemetry footprint, collector architecture, and the overall setup.

With so much to consider, here is a checklist to get you started:

• Determine the amount of staff you’re willing to dedicate to a central team
  • Helps coordinate the migration and helps with first-pass activities
• Take inventory of how many integrations and data sources your organization has.
  • Helps determine how much effort is required to capture the equivalent data in the system you’re migrating to
• Determine how many Datadog assets you have (dashboards, monitors, etc.)
  • Prioritize scope; it’s key to leave low-value assets in Datadog and only migrate what’s important
  • Ingest all metrics referenced in these assets before migration starts
• Determine the architecture you’ll need for collectors and data flow
• Answer the question: Are you trying to optimize for a short onset-to-completion timeline, or minimal disruption to developers’ day-to-day work?

Ultimately, it’s a sliding scale: Your appetite for disruption and your target timeline determine what you can realistically afford to do during the migration, but in all cases, careful planning is critical to getting it done.

It depends on your use case and what you care about, but a reasonable baseline is about a month of data. That comes from aligning with what most teams already use as their standard SLO reporting window — you generally want at least one full window of data as a baseline when you move into a new solution.

Migration planning is more than training people; there is also a lot of cleanup and reference work that has to happen around the tool. Update anything that points to Datadog so it directs people to the new system instead.

You should also expect to touch many small but important pieces that sit outside the product itself.

Concretely, that means things like:

• Updating references to your new tool of choice
• Reviewing all your runbooks
• Updating links and documentation that currently point to Datadog and redirecting them to equivalent docs for your new platform

Bottom line: Start planning your Datadog migration as early as you can. The larger and more complex your Datadog setup, the more time you need upfront to analyze assets, architect data collection, and define what success looks like. Your planning window should reflect whether you’re optimizing for speed of exit, minimal disruption, or a balance of both.

You should strongly weigh vendor neutrality when making this decision. Continuing to depend on a proprietary SDK from a previous vendor is a risky strategy, because that vendor can change the SDK in ways that negatively impact you, and you have no recourse. In the long term, this risk is a clear reason to favor Prometheus/OpenTelemetry over remaining tied to a Datadog instrumentation path.

You should also factor in the migration timeline and current pain with your existing SDK. A long-term, multi-year plan to replace an existing instrumentation SDK with Prometheus/OpenTelemetry will extend the overall migration timeline, whereas staying on existing instrumentation allows a faster exit when cost pressure is high. In addition, ongoing bugs or weak support in the current SDK can be a strong motivator to move sooner, whether to adopt new features or escape existing issues.

In practice, teams should assume that Datadog SDK instrumentation removal is a long-term, eventual objective, not an immediate step. Almost all customers keep Datadog instrumentation in place initially. From there, forward Datadog instrumentation traffic into an OpenTelemetry collector, and let the collector convert it into OpenTelemetry for ingestion. That pipeline allows the migration to proceed without forcing immediate changes at the source, and very few teams attempt to rip out Datadog instrumentation at the start.

A sustainable approach is to treat the decommissioning of Datadog instrumentation as a parallel, gradual effort once the main migration is underway.

The starting point is always what customers already consider important. You should identify which metrics power critical dashboards and alerts by starting with what users already rely on most: the dashboards they regularly use and consider critical, and the alerts they agree are genuinely valuable.

In practice, it is more appropriate to remove unused dashboards than alerts; dashboards with zero popularity—or with titles including words such as “copy, ‘John’s Dashboard’, scratch, WIP, etc—are strong candidates to exclude from migration. Across migrations, only about 20% of dashboards typically prove to be worth keeping.

Also, while unused Datadog dashboards do not have a direct cost implication, they greatly extend your migration timeline by making it harder to find what matters. For example, searches returning an excessive number of results will add visual clutter—just think about how often common terms like “Kubernetes” would appear in many little-used dashboards.

Ultimately, you don’t want Datadog dashboards to become observability technical debt. Having an abundance of useless artifacts in your observability platform presents a real risk of slowing people down during investigations, and at the very least will make it harder for newer engineers to get their bearings in the system.

Unlike Dashboards, monitors rarely provide the meaningful usage statistics necessary to evaluate their inclusion in a migration. The best way to proceed is by identifying the repeatable patterns your alerts follow and migrate those as templates, rather than migrating the hundreds or thousands of individual monitors they generate. When migrating alerts, focus on these patterns and move them over as templates instead of lifting and shifting every monitor.

This matters because Datadog doesn’t really have strong signal grouping capabilities — you can’t easily have a single monitor per service with different thresholds and routing per service — so teams lean heavily on Terraform templates to generate a customized alert-per-service pattern.

The key is to find a better solution than this restrictive “alert-per-service” model. For example, a best practice is to use “signals” with unique labels to intelligently group notifications when an alert triggers or resolves. This capability allows customers to consolidate their Datadog Terraform templates that generate hundreds of individual monitors into a single, comprehensive alert definition.

You’ll want to define one overall monitor while still achieving the granularity needed, such as:

• Dynamic Thresholds: Set different alert thresholds per signal (e.g., higher latency limits for Service A than for Service B).
• Granular Routing: Define unique notification routing per signal (e.g., route alerts for Service A to Team Alpha’s Slack channel, and Service B alerts to Team Beta).

Validation starts with an automated pass: dashboards, alerts, SLOs, and other assets are run through migration tooling, which generates configurations to import into a modern observability platform. Look for reports of high-level success rate, with any unsupported widgets or unmappable query functions called out.

The team then performs a manual review, checking panels and monitors individually to confirm they behave and look as expected. Any partial or failed cases can be handled in collaboration with the customer so recurring patterns are resolved once and applied broadly.
After that internal validation, the customer reviews the migrated assets, provides feedback, and the team iterates as needed. For monitors, there is extra scrutiny to ensure they fire under the same conditions as in Datadog. If desired, you can use a simulation or backtesting feature where there is a known alert window, or simply routing notifiers to the same destination so both systems page in parallel and discrepancies can be identified and fixed.

You will want to work with a team of experts that can help you handle your migration with confidence. Set expectations early that you will leave some things behind instead of copying every dashboard and monitor as-is. Align with the experts on what the full process looks like — from kickoff through onboarding, migration, validation, and developer enablement — and what effort is required at each step. Your goal is to create a clear path from data ingestion to asset sign-off with your development teams.

During execution, use the experts to unwind technical debt and focus on utilization. Have them help you:

• Discover and prioritize observability assets
• Identify which dashboards and queries are actively used, which were created for short-term needs, and which are redundant

In a model where each squad owns its own monitoring, you should survey squads on what they actually need and review that list together.

Rely on the migration team to call out anti-patterns — such as dashboards with hundreds of queries — and to guide engineers on working with time-based querying in the new system. Relying on these experts will help you move from thousands of legacy dashboards to a smaller, purposeful set on a predictable timeline.

Migrating off Datadog doesn’t have to be a risky leap of faith. When you treat planning as its own phase, use a realistic baseline for historical data, and intentionally decide what to migrate versus leave behind, the process becomes structured instead of chaotic.

A migration strategy is actually more straight-forward than people think:

• Start early.
• Be clear about whether you’re optimizing for — speed, stability, or a balance.
• Be honest about the Datadog footprint you’ve built, and lean on experts and tooling to surface what’s actually in use.

Paired with a pragmatic approach to instrumentation (Datadog instrumentation now, open standards over time) and a disciplined validation loop before decommissioning Datadog, you can exit a costly, proprietary model and land with a leaner, more sustainable observability stack your teams trust and can operate confidently.

John Potocny, Brad Hjelmar, and Erica Troge contributed to this article.