Migrate from Nagios XI to Checkmk

A single Nagios XI server with one set of hosts is the simplest starting point. The usual pattern is to build a Checkmk site beside XI, run discovery and check the results against the XI view of the same hosts, and keep XI as the only notifier until the Checkmk side is verified. Because both systems poll the same targets, the extra load is usually small, but confirm this against your own check intervals and network path before you start.

• Run both monitors read-only at first: Keep XI notifications on and Checkmk notifications off while you compare states.
• Compare states host by host: Match each XI service with its Checkmk counterpart and record any mismatch in threshold, timeout or plugin output.
• Keep legacy plugins where needed: Run custom Nagios plugins as active checks in Checkmk until you have a replacement.
• Limit the overlap to one notification path: Only one system should page the on-call group at any time.
• Record the cutover order: Write down which hosts move first so rollback is a known step.

Before you disable XI notifications, confirm that every critical service has a matching Checkmk check, that the notification rules deliver to a test contact, and that acknowledgments and downtimes work in the new system.

Distributed XI installations usually have a central server and remote pollers or nodes in other networks. Checkmk handles this with its own distributed monitoring model, so the cutover should be planned by segment rather than by a single switch. Start with the segment where failures are easiest to see and where network reachability from the new central site is already proven.

• Map each XI poller to a Checkmk site: Decide whether each remote segment gets its own site or a remote site connected to a central instance, and confirm this against the Checkmk distributed monitoring documentation for your edition.
• Cut over one segment at a time: Switch notifications for that segment only, then move to the next.
• Check firewall and time sync first: Agent and check traffic must reach the new sites, and clock drift will distort freshness checks.
• Avoid double paging across segments: If XI and Checkmk both cover a segment, disable XI notifications for that segment before enabling Checkmk ones.
• Confirm escalation paths per segment: Escalations often depend on local contacts, so test each one.

For each segment, verify that a deliberately induced failure produces one alert, one recovery, and the expected escalation in the target system before moving on.

Some organizations run Nagios XI for one group of hosts, a Checkmk Community site for another, and a commercial Checkmk edition elsewhere. In that case the cutover is less about switching a single system and more about deciding which system owns each host and each notification. Ownership must be recorded explicitly, because two systems that both think they own a host will both page.

• Assign one owner per host: Maintain a single inventory that states which tool is the notifier of record for each host.
• Match features to editions: Check whether features you rely on, such as push-mode agents or Synthetic Monitoring, are available in the edition you run, using the Checkmk editions page.
• Plan for Community limits: Community is intended for small infrastructures, so confirm its fit before moving large groups there.
• Keep the XI license in view: Keep XI running only for hosts still owned by it, and track its renewal date against the cutover plan.
• Document the exceptions: Record any host that stays in XI for a reason, such as a plugin with no Checkmk equivalent.

Before you retire any XI notification group, confirm that the owner inventory matches what the monitors actually cover and that no host is left without a notifier.

Whatever the starting point, the overlap period is where duplicate and missed notifications appear. The controls below apply to every cutover, and they are most useful when written into the runbook before the first host moves. They also give auditors and incident responders a clear record of which system alerted for which service on which day.

• Use a single notifier per service: Disable notifications in the system that does not own the service, even if its checks keep running.
• Test with induced failures: Use a non-production host or a planned, announced fault to confirm alert count and recovery messages.
• Verify acknowledgments and downtimes: Maintenance windows set in one tool must suppress alerts only in that tool, and the other tool must not page during the window.
• Keep plugin behavior identical where needed: Run the same Nagios plugin with the same arguments in both systems and compare output before trusting Checkmk results.
• Keep XI read-only for evidence: Export XI configuration and history before shutdown so that past incidents remain traceable.

Before you disable XI notifications for good, confirm the owner inventory, the test results and the export of XI history, and get sign-off from the on-call team that the new paging path works.

A single Nagios XI server running on Community, with a modest host list and a handful of notification contacts, is the simplest case. The work is mostly a fresh Checkmk site, a set of discovery runs and a review of what Checkmk now calls services. Because the estate is small, the main risk is not scale but forgetting a check that someone set up years ago and never documented. Community is free and open source and is described as suited to small infrastructures, so licensing is rarely the deciding factor at this size.

• Discovery replaces copying: Run service discovery on each host instead of exporting XI service definitions, then compare the result against the old list.
• Plugin checks: Keep any custom plugin in /omd/sites/<site>/local/lib/nagios/plugins as an active check and test its output format.
• Notifications: Rebuild contacts and notification rules by hand, since a small team can test each one with a real alert.
• Installation: Choose a Linux package or the Docker container image, and confirm which one your team can patch and back up.
• Parallel run: Keep XI running for a short overlap so you can compare alerts before switching off.

Before cutover, confirm with your own inventory that every host and check on XI has a counterpart in Checkmk, and that the on-call person knows where alerts now come from.

A large estate with many nodes, many XI wizards and a library of in-house plugins changes the project from a configuration exercise into an inventory exercise. Discovery can cover most standard checks, but custom plugins, thresholds tuned by hand and host groups built over years need explicit decisions. Commercial editions can also create sites with the Checkmk Micro Core by default, which is relevant to how much load the new monitoring server must carry. Scale-related figures for the Micro Core come from Checkmk's own benchmarks, so test with your own host and service counts before you size hardware.

• Plugin inventory: List every custom plugin, its owner and whether it still runs, then decide whether each one stays, is rewritten or is retired.
• Rule-based configuration: Replace repeated per-host edits with rules and host tags, which changes how changes are reviewed.
• Core choice: Decide between Community on the Nagios core and a commercial edition with the Micro Core, and test your load on each.
• Automation: Ask whether push-mode agents and automatic host registration are needed, since Checkmk documents them as Ultimate features.
• Staged cutover: Move host groups in waves so that one failing plugin does not affect the whole estate.

Ask your vendor or implementation partner to show, in writing, how each custom plugin is classified and tested before any host moves.

Multi-site estates and regulated environments add requirements that a single server does not meet: remote sites that must keep monitoring during a network outage, separate administrative domains, and records that an auditor can read. Checkmk supports distributed monitoring in its commercial editions, and that feature belongs in the design review before anyone chooses Community. Regulated teams also need to show who changed a rule, when a notification was sent and how access was controlled, so the audit trail is part of the migration scope rather than an afterthought.

• Distributed monitoring: Confirm which edition provides distributed monitoring for each remote site and how remote sites report back during an outage.
• Access and change control: Map XI user roles to Checkmk roles and document who can edit rules and notifications.
• Evidence: Export configuration history and alert records you will need for your control framework, and confirm the format with your auditor.
• Parallel running: Keep old and new alerting in parallel for longer where incident response or reporting depends on it.
• Support model: Decide who patches the site, whether you need 8x5 support, and who responds out of hours.

DeployOpen prepares systems and evidence for compliance assessments, but independent auditors decide whether the evidence is sufficient, so confirm the requirements with them early.