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.

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