Migrating from Nagios, Zabbix or CloudWatch to Datadog - A Practical Guide

Migrating to Datadog from Nagios, Zabbix and CloudWatch

Migrating monitoring is not just swapping one tool for another. It is a shift in how you think about observability: from reacting to outages to proactively monitoring the health of the entire system. Done well, it gives teams a single pane of glass, lower MTTR, and fewer false alarms.

For a broader analysis of monitoring tool costs, see our article on the rising cost of observability.

Coming off a commercial APM (Dynatrace, AppDynamics or New Relic) rather than open-source tooling? That is a different migration - see our guide to Datadog vs Dynatrace, AppDynamics and New Relic, and how to migrate with minimal disruption.

When migrating to Datadog makes sense

Not every organisation needs Datadog. It is a premium tool with premium pricing. Migration is justified when:

• You run 3+ monitoring tools - Nagios for infrastructure, Grafana for metrics, ELK for logs, a separate APM. Consolidation eliminates duplication and reduces licence costs (though Datadog itself is not cheap).
• Alert fatigue is killing incident response - Nagios generates hundreds of alerts per day, 90% of which are false positives. The team ignores alerts.
• You lack correlation between layers - you can see CPU at 90%, but you cannot tell which service, which request, or which deployment caused the spike.
• You are scaling infrastructure - Nagios/Zabbix with manual host configuration cannot keep up with autoscaling and containers.
• You need APM - distributed tracing is a native Datadog feature. Bolting it onto Nagios/Zabbix is a major effort.

When NOT to migrate

• You have 5-10 servers and a simple stack. Nagios/Zabbix is sufficient.
• Your monitoring budget is under $500/month. Datadog will cost more than your current solution.
• The team has no capacity to learn a new platform in the next 2-3 months.
• Compliance requires on-premise monitoring with no SaaS (rare, but it happens).

Mapping: old tool to Datadog

Nagios to Datadog

Key difference: Nagios operates on a rigid hierarchy: host > service > check. Datadog operates on tags. A single host can have 50 tags and appear in any context. This requires a shift in thinking when designing dashboards and alerts.

Zabbix to Datadog

Key difference: Zabbix is an infrastructure monitoring tool. Datadog is an observability platform covering infrastructure, APM, logs, synthetics, security and more. Migrating from Zabbix is not a 1:1 swap. It is a step up in visibility (and cost).

CloudWatch to Datadog

Key difference: CloudWatch monitors AWS. Datadog monitors everything: AWS, GCP, Azure, on-prem, Kubernetes, custom applications. If you run exclusively on AWS with no multi-cloud plans, CloudWatch + X-Ray may be sufficient. Migration makes sense when you want a single pane of glass for a heterogeneous environment or need better APM than X-Ray provides.

Migration plan: 4 phases

Phase 1: Inventory (2-3 days)

What are you monitoring today and why:

# Nagios - export active checks
nagiostats -m -d NUMSVCOK,NUMSVCCRIT,NUMSVCWARN,NUMHSTUP,NUMHSTDOWN
cat /etc/nagios/objects/*.cfg | grep "define service" | wc -l

# Zabbix - export active items and triggers
zabbix_server -R config_cache_reload
mysql -u zabbix -p zabbix -e "SELECT COUNT(*) FROM items WHERE status=0;"
mysql -u zabbix -p zabbix -e "SELECT COUNT(*) FROM triggers WHERE status=0;"

# CloudWatch - list active alarms
aws cloudwatch describe-alarms --state-value OK --query 'MetricAlarms[].AlarmName' | wc -l
aws cloudwatch describe-alarms --state-value ALARM --query 'MetricAlarms[].AlarmName'

Document:

• How many hosts/services are monitored
• How many alerts are active (and how many does anyone actually read)
• Which dashboards are used (not created: used)
• Who receives alerts and how they respond
• Which integrations/plugins are critical

Phase 2: Parallel Datadog configuration (1 week)

Goal: Datadog collects data alongside the old tool. Nothing gets switched off.

1. Install Datadog Agent on all hosts (Ansible playbook or DaemonSet in K8s)
2. Enable AWS integrations - Datadog automatically pulls CloudWatch metrics
3. Configure base tags - env:production, team:platform, service:api
4. Recreate critical alerts (not all of them: only the ones you actually respond to)
5. Build 2-3 dashboards - replicas of the ones the team actually opens

# Example: Ansible role for Datadog Agent installation
- name: Install Datadog Agent
  hosts: all
  roles:
    - role: datadog.datadog
      vars:
        datadog_api_key: ""
        datadog_agent_major_version: 7
        datadog_config:
          tags:
            - "env:"
            - "team:"
            - "service:"
          logs_enabled: true
          process_config:
            enabled: true
        datadog_checks:
          http_check:
            instances:
              - name: "-health"
                url: "http://localhost:/health"
                timeout: 5

Phase 3: Validation and tuning (1 week)

• Compare metrics from both sources. Does Datadog see the same things as the old system?
• Test alerts. Trigger an artificial incident and verify Datadog responds correctly.
• Collect team feedback. Do the dashboards answer their questions?
• Adjust thresholds. Datadog has anomaly detection: use it instead of static thresholds.
• Configure APM tracing (if needed). Instrument application code.

Phase 4: Cutover and decommission (3-5 days)

1. Announce to the team: “From Monday, Datadog is the source of truth”
2. Redirect on-call notifications from Nagios/Zabbix to Datadog monitors
3. Disable alerts in the old system (but keep metric collection running for 2 more weeks)
4. After 2 weeks without incidents: switch off the old system entirely
5. Remove Nagios/Zabbix agents from hosts

Do not turn off the old system immediately. Keep it in read-only mode for 2 weeks as a backup. If Datadog misses something, you have somewhere to check.

Common migration mistakes

1. Migrating all alerts 1:1

Nagios with 500 checks becomes 500 monitors in Datadog. Result: the same false positives as before, just on a more expensive platform.

Correct approach: Only migrate alerts that someone actually responded to in the past 3 months. Discard the rest. Migration is an opportunity for cleanup.

2. Ignoring tag strategy

Tags are the foundation of Datadog. Without a consistent tagging convention you lose 80% of the platform’s value: you cannot filter dashboards, scope monitors, or allocate costs.

Minimum: env, service, team. Optional: version, region, tier.

3. Custom metrics explosion

Every unique combination of metric name + tag values = one custom metric = one charge. Teams accustomed to Prometheus (where metrics are free) generate thousands of custom metrics in Datadog and receive a bill 3x higher than planned. This also causes performance issues with the agent itself. If the Datadog Agent starts consuming excessive CPU or memory, see our Datadog Agent high CPU/memory troubleshooting runbook.

Correct approach: Define a custom metrics budget upfront. Use exclusion filters. Monitor usage in Datadog Plan & Usage.

4. No cutover date

“We will run in parallel until we are ready” means you never switch. Set a date, announce it, and stick to it.

5. Migration without APM

If you are already paying for Datadog, not using APM is like buying a Tesla and only driving it in the car park. Distributed tracing changes the quality of debugging: from “CPU is high” to “this specific endpoint in this service is creating N+1 queries against the database”.

Cost comparison: Nagios/Zabbix vs Datadog

Honestly: Datadog is more expensive at the licence level. Savings come from: shorter MTTR (fewer outages), less engineer time maintaining monitoring, tool consolidation (no more separate bills for ELK + Grafana + PagerDuty), and better visibility leading to faster architectural decisions.

For a company with 20 hosts and one engineer, Nagios is sufficient. For a company with 100+ hosts, microservices, and a team of 10+, Datadog pays for itself within a quarter through reduced debugging and maintenance time.

Timeline summary

For Kubernetes environments the timeline can be shorter (DaemonSet = one command). For large bare-metal environments with hundreds of manual Nagios checks, expect it to take longer.

How we can help

We deliver Datadog migrations end-to-end: from auditing your current monitoring, through agent configuration and integration setup, to building dashboards and transferring knowledge to your team.

Typical scope:

• Audit of current monitoring (what works, what is dead, what generates noise)
• Tag strategy and naming convention design
• Datadog Agent installation and configuration (Ansible/Terraform/Helm)
• Recreation of critical alerts as Datadog Monitors
• Operational dashboard builds for the team
• APM tracing configuration (application instrumentation)
• Datadog cost optimisation (exclusion filters, custom metrics budget)
• Team training and knowledge transfer

Planning a monitoring migration?

Book a free 30-minute call. We will discuss your current tooling and prepare a migration plan for Datadog.

Book a call Send us a message