Datadog is an excellent product with a billing model that punishes success. Per-host pricing, per-GB log ingest, separately metered modules (APM, RUM, synthetics), and surcharges for custom metrics and high cardinality mean the bill grows with every host you add and every team that instruments something new. Bill shock at renewal is one of the most commonly cited reasons teams start looking, and the good news is that the open-source observability stack is now genuinely capable of replacing it. The risk is rebuilding the same cost structure in a different tool, so the choice of target matters.
Know what you are actually replacing
Datadog is three products in a trench coat: metrics, logs, and traces, plus dashboards and alerting over all three. Inventory which of those you actually rely on before you migrate. Many teams find they use Datadog heavily for metrics and dashboards but only lightly for logs, which changes the target calculus significantly.
Prometheus vs Grafana as the anchor
Prometheus is the right anchor when metrics are your center of gravity. It is the CNCF-standard, pull-based metrics engine, pairs with Alertmanager for alerting, and is typically visualized through Grafana. You self-host it, so you trade a subscription for running (and scaling) the storage yourself, with options like Thanos or Mimir for long-term retention. Choose it when you want a focused, metrics-first stack and have Kubernetes or exporter-friendly infrastructure.
Grafana (as the platform, with Mimir for metrics, Loki for logs, and Tempo for traces) is the right anchor when you want a single pane across all three signals, closer to Datadog’s breadth. Instrument with OpenTelemetry, keep Grafana OSS self-hosted or use Grafana Cloud’s tiers, and you get a unified experience without per-host penalties. It is more moving parts to run than Prometheus alone, but it maps more directly onto everything Datadog did for you.
Whichever you choose, the migration pattern is the same: deploy the new agents or OpenTelemetry collectors, rebuild dashboards and translate alerts, and dual-run both stacks until you trust the new one.
Cardinality is the thing that will surprise you
The single most common way a self-hosted observability migration goes wrong is that nobody measures cardinality before moving. Datadog absorbs high-cardinality metrics and charges you for the privilege; Prometheus absorbs them until it falls over.
Cardinality is the number of distinct time series, and it multiplies. A metric with a label for customer identifier, another for pod name, and another for request path does not produce one series, it produces the product of all three. In a Kubernetes estate where pods are recreated constantly, a single carelessly labelled metric can generate hundreds of thousands of series on its own.
Before you size anything, pull your top metrics by series count out of the incumbent and look at them honestly. Two things usually follow. Some metrics are genuinely valuable and need a storage layer built for them, which is where Thanos or Mimir earn their complexity. Others exist because someone added a label years ago and nobody noticed, and those should be fixed rather than migrated. It is common for a cardinality review to remove a large fraction of the volume before a single component is deployed, which changes the sizing and the cost case substantially.
Retention deserves the same scrutiny. Teams habitually ask for thirteen months of everything and then discover that nobody has queried beyond two weeks except during a postmortem. Tiered retention, full resolution recently and downsampled beyond that, is usually the honest answer and it changes the storage bill by an order of magnitude.
What you give up, honestly
Leaving Datadog costs you things, and a plan that does not name them will be undermined the first time someone notices.
History does not come with you. Metric and log history generally stays behind, and you cannot query last quarter’s incident in the new stack. The usual approach is to dual-run through at least one full business cycle and let the old data age out of relevance rather than trying to migrate it.
Correlation gets harder. Datadog’s real value is often not any single signal but the ability to move from a trace to the logs of the same request to the host metrics underneath it without thinking about it. Rebuilding that in an assembled stack is possible, and it takes deliberate work on consistent labelling and trace-to-log linking. It will not be free by default.
Someone now operates the monitoring. The uncomfortable case is monitoring that goes down during the incident it was supposed to help with. Self-hosted observability needs its own availability plan, ideally with alerting that can still fire if the main stack is unhealthy.
Onboarding slows. Datadog’s integrations work out of the box and its defaults are good. Expect a period where teams instrument things less because it takes more effort, and counter it with templates and a paved path rather than hoping.
None of this argues against moving, and for most estates the cost difference is large enough to settle the question. It argues for moving with the trade-offs written down. Each path below opens to a full cost model, plan, and in-depth guide.