Migrating from Datadog Without Downtime

Why Teams Are Migrating

The observability landscape has shifted. Teams that adopted Datadog early are now facing:

• Unpredictable pricing that scales faster than their infrastructure
• Vendor lock-in through proprietary agents, query languages, and integrations
• Feature bloat — paying for capabilities they don't use
• Cardinality limits that force teams to drop valuable dimensions

If any of this sounds familiar, you're not alone. We've helped dozens of teams migrate from Datadog to xScaler Labs + Grafana, and the process is smoother than most people expect.

The Migration Strategy

The key principle: run both systems in parallel before cutting over. This gives you confidence that xScaler Labs is receiving and storing data correctly before you decommission Datadog.

Phase 1: Dual Write (Day 1-3)

Install Prometheus alongside the Datadog agent. You don't need to remove Datadog yet.

If you're running Kubernetes, deploy the Prometheus Operator:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
  --set prometheus.prometheusSpec.remoteWrite[0].url=https://euw1-01.m.xscalerlabs.com/api/v1/push \
  --set prometheus.prometheusSpec.remoteWrite[0].bearerToken=YOUR_XSCALER_TOKEN

For VM-based infrastructure, add a Prometheus instance with appropriate scrape configs for your services.

Phase 2: Dashboard Recreation (Day 3-7)

This is where most teams worry, but it's actually straightforward:

1. Export Datadog dashboards as JSON
2. Use our migration tool that converts Datadog metric names to Prometheus conventions
3. Import into Grafana connected to xScaler Labs as a Prometheus data source

Common name mappings:

| Datadog | Prometheus | |---------|-----------| | system.cpu.user | node_cpu_seconds_total{mode="user"} | | system.mem.used | node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes | | docker.containers.running | kubelet_running_containers | | http.requests | http_requests_total |

Phase 3: Alert Migration (Day 7-10)

Recreate your Datadog monitors as Prometheus alerting rules:

groups:
  - name: migrated-from-datadog
    rules:
      - alert: HighCPU
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage above 80% on {{ $labels.instance }}"

      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 2m
        labels:
          severity: critical

Phase 4: Validation (Day 10-14)

Run both systems side by side and compare:

• Are all expected series present in xScaler Labs?
• Do dashboard values match between Datadog and Grafana?
• Are alerts firing at the same thresholds?
• Is query performance acceptable?

Use our comparison dashboard template that shows Datadog vs. xScaler Labs values side by side.

Phase 5: Cutover (Day 14+)

Once you're confident in the data:

1. Remove the Datadog agent from your infrastructure
2. Cancel your Datadog subscription
3. Celebrate your cost savings

What You Gain

After migration, teams typically report:

• 60-80% cost reduction in metrics spend
• Longer retention (1 year vs. Datadog's 15 months at premium pricing)
• No cardinality limits — store every dimension without worrying about custom metrics pricing
• Open standards — PromQL queries, Grafana dashboards, no vendor lock-in
• Full control — alerting rules in version control, infrastructure as code

Need Help?

Our solutions team has migrated companies from 10 to 10,000 services off Datadog. Reach out through our contact page and we'll put together a custom migration plan for your environment.