Everyone talks about "vendor lock-in" but nobody actually unpicks the lock until the bill hits five figures and your CFO starts asking questions nobody in engineering can answer. Datadog is a fantastic product, until it isn't. The feature bloat is impressive, but we were using maybe 20% of it. The final straw was the annual negotiation where our "usage growth" led to a proposed 40% price hike with a three-year lock. So we started the Grafana migration, not for the shiny new thing, but for the old-fashioned concept of cost control.
The migration wasn't about moving dashboards. It was about re-architecting the data pipeline. We kept Datadog agents running for logs during the transition, but pointed metrics to a Grafana Cloud Prometheus endpoint. The real work was in the configs: replacing Datadog's check definitions with Prometheus exporters and Grafana Agent configs. Took about two weeks of engineering time to get the core infrastructure metrics flowing reliably. Alerting was the biggest mindset shift – moving from Datadog's UI to writing and testing Prometheus alert rules in code felt like a step back in time, but forward in clarity. No more magical, opaque thresholds.
Cutover was phased over a month. Week 1-2: parallel runs, comparing graphs. Week 3: shifted primary on-call alerts to Grafana, kept Datadog as backup. Week 4: killed Datadog alerting entirely. Logs came last, using Grafana's Loki with the same agents. Total time from project kickoff to turning off the last Datadog resource was 11 weeks. The actual hard cutover of turning off the Datadog billing meter took about 10 minutes and was the most satisfying part.
The result? Our observability stack now costs 65% less, and because everything is built on open standards, the next "lock-in" conversation will be a lot shorter. The trade-off is real: you lose some of the slick, all-in-one convenience and have to stitch more pieces together. But for our scale, the seven-figure annual savings buys a lot of engineering time to handle that complexity.
/charlie
Show me the TCO.
I run the SaaS platform for a 100-person fintech, and we moved from Datadog to a self-hosted Grafana stack (Mimir, Loki, Tempo) about 18 months ago after hitting similar cost concerns.
**Real Cost:** Datadog started at around $30k/year for us and was projected to hit $45k. Our current Grafana stack (excluding engineering time) runs on three managed VMs and costs under $1k/month in infra. The real cost is the 10-15% ongoing engineering overhead for maintenance and scaling.
**Integration Effort:** The initial pipeline rewrite took us three weeks, similar to you. The persistent effort is writing and maintaining exporters. Every new service needs a Prometheus metric endpoint, whereas Datadog's agent would often auto-discover things. We spend a few hours a month on this.
**Where Grafana Wins:** Absolute data ownership and alerting precision. Our alerts are now code-reviewed YAML in git, tied to our deploy process. There's no UI drift or surprise threshold changes. For investigations, being able to raw query traces, logs, and metrics with the same label set is powerful.
**Where It Clearly Lags:** The out-of-the-box experience. You don't get nice pre-built dashboards for AWS or Kubernetes. We built our own K8s overview, and it took two sprints to get to 80% of what Datadog gave us in an afternoon. Also, the learning curve for team members unfamiliar with PromQL is real.
My pick is Grafana, but only if you have at least one engineer who can own the observability stack as a part-time duty. If you're a small team with no SRE bandwidth, the operational burden of Datadog is probably worth the price.
Tell us your team size and if you're on Kubernetes; that's the deciding factor on whether the DIY route is sustainable.
Always testing.
Your point about the "real cost" being the engineering overhead is spot on. I love that you actually quantified it at 10-15%. That's the number nobody wants to admit when they're pitching the "it's just open source, how hard could it be?" migration to management.
> writing and maintaining exporters
This is the hidden tax, isn't it? Datadog's magic auto-discovery was a siren song of technical debt. Now I find myself writing a custom exporter for some dusty old Java service and thinking, "Ah yes, this is the cost control we fought for." It's fine, I wanted to learn the inner workings of JBoss 7 anyway. 🙃
And the YAML alerts in git? Chef's kiss. Until someone reformats it and breaks the linter.
That line about the hidden tax of exporters is perfect. We got burned by that too, thinking it was a one-time lift. It's the maintenance that adds up.
Our linter break story is worse - we had a GitLab CI job that auto-formatted all the YAML, then a second job that validated it. They'd fight each other on merge requests for months before we figured it out.
The CI linter wars are the perfect symptom of that "hidden tax". You think you're adding automation to solve the problem, but you're just building a more complex system to maintain.
I've seen teams solve that specific fight by making the validation job run the formatter itself, dump the output to a temp file, and diff it with the proposed changes. If there's a diff, it fails the MR with the exact formatting commands. Stops the fight because there's only one source of truth for the format.
But you're right, that's just more code, more pipelines, more things that can break. You trade a vendor bill for a cognitive load bill. The question is which one your team is better equipped to pay.