Nagios XI vs Checkmk: which monitoring fits

Nagios XI vs Checkmk: when each option fits

For a Nagios XI renewal or per-node quote, Checkmk Community fits small estates where the team can accept building checks by hand, while a commercial Checkmk edition fits a larger estate that needs rule-based configuration, automation and vendor support. Staying on XI makes sense only when its wizards, dashboards and reporting are essential and the renewal cost is acceptable. The decision turns on four factors: host count, how much auto-discovery and rule-based configuration the team needs, whether the monitoring must run on premises or on the Cloud edition, and how much support the team needs. Checkmk Community is built on the Nagios core, so existing Nagios plugins carry over and can stay in use as active checks during a move.

Host count is the first filter. The editions page describes Community as suited to small infrastructures and easily scalable up to about 100 hosts. Above that, the Pro edition adds distributed monitoring and automation, and it lists a starting price of 190 euros per month billed annually. Automatic host registration and push-mode agents are features of the top commercial tier, so a team that depends on agents reporting in without manual onboarding should price that tier, which starts at 275 euros per month billed annually. The Cloud edition is 240 euros per month billed yearly and capped at 50,000 services, so it fits only if a SaaS deployment passes your data residency review. Confirm with Checkmk whether the quote counts hosts or services, and whether taxes apply.

Which option fits which monitoring scenario

This table maps common estate and team conditions to the Checkmk edition or path that fits best. Read each row against your own host count, network layout and tooling, then check the edition details on the Checkmk editions page before committing to a tier.

Scenario	Better fit	Why
Small estate that Community can handle	Checkmk Community	Community is free and open source and is described as easily scalable up to about 100 hosts, so a small estate can start without a license cost. Confirm your host count and growth plan against that figure.
Larger estate needing distributed monitoring	Checkmk Pro or Ultimate	Distributed monitoring is listed as a Pro feature, so beyond the Community scale point it becomes a reason to choose a commercial edition. Ask Checkmk to confirm which remote site model and support level your topology needs.
Team wants push-mode agents and automatic host registration	Checkmk Ultimate	Push-mode agents and automatic host registration are Ultimate features per the Checkmk setup guide. If you rely on pull-only checks today, plan for the agent rollout effort in your scope.
Team wants to keep existing Nagios plugins and XI-style wizards	Checkmk Community with legacy plugin checks	Checkmk is built on the Nagios core, so many Nagios plugins can run as active checks, but XI's wizards and dashboards do not carry over. Test each critical plugin and confirm that Checkmk's rule-based model covers your current alerting.
Organization must run monitoring in its own data center or air-gapped network	Self-hosted Checkmk Community or commercial edition from Linux packages or Docker images	Community and commercial editions install from Linux packages or Docker images, while virtual and physical appliances are limited to commercial editions. Confirm offline package delivery, update channels and license validation requirements for air-gapped operation with Checkmk.
Estate with frequent synthetic web checks	Checkmk Pro or Ultimate with Synthetic Monitoring	Synthetic Monitoring is an add-on available only with Pro and Ultimate, so Community users would need another tool for this need. Confirm the add-on pricing with your Checkmk representative.

How Checkmk rule-based configuration and auto-discovery change daily work

Nagios XI teams usually manage hosts, services and notifications one object at a time, through wizards and configuration files. Checkmk shifts much of that work to service discovery, rule sets and host tags, which can cut effort on large or fast-changing estates but adds a learning curve for teams whose XI setup is small and stable.

Service discovery replaces hand-built services

In Nagios XI, each service is usually defined by hand or added through a wizard, then maintained as hosts change. Checkmk runs service discovery against each host and proposes the services it finds, which the team accepts, removes or changes in bulk. This saves effort when servers are provisioned often and drift from the original definitions. For a small estate with a stable set of checks, discovery adds review work at first, so confirm which discovered services you actually want before turning on automatic acceptance.

Rule sets replace per-object edits

Nagios XI teams often change thresholds, notification contacts or check arguments on individual objects or through templates. Checkmk applies rule sets: a single rule assigns a parameter, such as a threshold, to every host or service that matches its conditions. A change made once then reaches the whole matching group. The benefit grows with the number of hosts. The cost is that rule precedence and conditions must be understood, so test rules on a few hosts before broad rollout.

Host tags group hosts by role

Nagios XI groups hosts through hostgroups, contact groups and manual object references that someone must keep current. Checkmk uses host tags, such as role, site or location, to classify hosts, and rule sets select hosts by those tags. When a server changes role, updating its tags moves it into the right rules automatically. Plan the tag scheme before migration, because renaming tags later touches every rule that uses them.

Notifications follow rules and contacts

Nagios XI notifications are defined per contact and per object, and teams often rebuild them when ownership changes. Checkmk expresses notification behavior as rules that match hosts or services and route them to users or groups. This suits organizations with frequent on-call or ownership changes, because routing follows tags instead of object lists. Teams with a few fixed contacts may find the XI model simpler. Confirm the notification methods you need, since the supported channels and any edition-specific options must be checked against the current Checkmk documentation for your version.

Plugins and active checks carry over

Many Nagios XI checks are standard Nagios plugins that run as active checks. Checkmk can run existing plugins as active checks, so custom scripts are not automatically lost. Checkmk also brings its own agent-based checks, which often replace a plugin with a more detailed check on the same host. Inventory every custom plugin before migration and decide per check whether to keep the plugin, use a built-in check or write a new one. Do not assume every XI wizard has a Checkmk equivalent, and confirm mapping for each specific check.

Dashboards and reports need rebuilding

Nagios XI ships with dashboards, reports and wizards that many teams use for daily views and management reporting. Checkmk provides its own dashboards and reporting, which are configured inside the product rather than copied from XI. Teams should list every XI dashboard and report that people rely on, then check each one against Checkmk's views and reporting features. Some may need to be rebuilt, reduced or replaced by exports to another tool. Expect this work to take real time in organizations with many custom reports.

Which Checkmk edition matches your monitoring needs

Checkmk Community is the free, open-source edition of the product. Checkmk describes it as free and open-source monitoring for small infrastructures, easily scalable up to about 100 hosts. Unlike the commercial editions, Community is built on the Nagios core, which Checkmk includes as its monitoring engine. Its source is published under GPL-2.0, so the software itself carries no license fee.

No subscription fee: The software is free to download and run, so the cost is the server, storage and staff time to operate it.
Nagios core engine: New sites run on the Nagios core, which keeps Nagios plugin behavior familiar to teams migrating from Nagios XI.
Self-hosted packages: Community installs from Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or as Docker container images.
Vendor support: Support is not part of the free edition, so confirm with Checkmk which support options exist for Community before you depend on them.
Scale limit: Checkmk positions Community for smaller environments, so confirm how your planned host and service counts will perform on it.

Before choosing Community, check that your host count, alerting needs and staff capacity fit the free edition's scope.

Nagios XI and Checkmk compared capability by capability

This table compares Nagios XI and Checkmk across engine, configuration, discovery, distributed monitoring, agents, synthetic checks, installation and licensing. Checkmk entries follow its editions and setup documentation, while Nagios XI entries tell you what to confirm against current XI documentation and your own license. Read the Checkmk column closely for edition limits, since several features depend on which tier you buy.

Capability	Nagios XI	Checkmk (Community or commercial edition)
Core engine	Built on Nagios Core with the XI web interface on top. Confirm current engine components in XI documentation.	Community is built on the Nagios core. Commercial editions create new sites with the Checkmk Micro Core by default and keep Nagios as an optional migration core.
Configuration model	Object definitions managed through XI interfaces and wizards. Confirm how changes are stored and applied in your XI version.	Rule-based configuration applied to groups of hosts and services, so one rule can cover many objects.
Auto-discovery	Host and service discovery through XI wizards and scans. Confirm scope and automation in your edition.	Service discovery is supported. Automatic host registration is limited to the highest commercial tier.
Distributed monitoring	Supported through remote and distributed setups. Confirm supported topology and license terms with Nagios.	Community is described as scalable to about 100 hosts. Distributed monitoring is listed for Pro and higher editions.
Push-mode agents	Confirm agent and passive check options in current XI documentation.	Push-mode agents are available only in the highest commercial tier.
Synthetic monitoring	Confirm whether XI includes synthetic checks and whether they carry an extra cost.	Synthetic Monitoring is an add-on available only with Pro and the highest commercial tier.
Installation options	Confirm supported operating systems and appliance formats for your XI release.	Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, and Docker images for Community and commercial editions. Appliances are commercial only.
Licensing	Perpetual per-node license with optional Enterprise add-on and maintenance renewals. Confirm terms in your agreement.	Checkmk source is GPL-2.0. Community is free and open source. Commercial editions are priced per month and billed annually.

Data location, hosting models and compliance implications

Monitoring data is easy to underestimate in an audit scope. The hosting model you choose decides who operates the platform, where hostnames and service details are stored, and which controls you must evidence yourself. The cards below set out those decisions for Nagios XI and Checkmk.

Self-hosted Checkmk on your own servers

Community, Pro and Ultimate can all be installed on your own Linux servers from packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or run as Docker container images. Monitoring data then stays in your data center or cloud accounts, and your team operates the site, patching and storage. Check which packaging and container options your security baseline allows and where the site's data directories and backups will live.

Appliance option on commercial editions

Virtual and physical appliances are offered only for the commercial editions, not for Community. An appliance shortens the build work, but it still runs in your environment, so the hardening, update and log responsibilities stay with you. Ask the vendor which operating system layers the appliance covers, how updates are delivered into a disconnected network, and what access the vendor retains.

Cloud edition and data residency

The SaaS Cloud edition moves hosting of the monitoring site to the vendor, so hostnames, IP addresses and service names are processed in the vendor's environment. Before choosing it, confirm the hosting region, subprocessors, encryption at rest and in transit, and how the contract handles deletion. Teams with strict residency or sovereignty rules often find that a self-hosted edition is the simpler path to evidence.

Identity, access and retention are yours

When you self-host, role assignments, single sign-on integration, administrator accounts and the retention period for performance data and event history are configured by your team. Auditors will ask who can view or change host lists, notification contacts and check credentials. Document the roles, review them on a schedule and set retention so it matches your policy rather than a default.

Backups and recovery are your responsibility

Monitoring configuration, rule sets, discovered inventory and history must be backed up and restored by your team on a self-hosted site. Test restores, not only backups, and record the results, because an untested monitoring site can fail silently during an incident. Confirm where backup copies are stored and who can read them, since those copies hold the same inventory data.

Monitoring data is sensitive evidence

Hostnames, IP addresses, service names and check output describe your attack surface, and auditors may treat them as sensitive or in scope. This applies to any hosting model, including Cloud. Classify the monitoring data in your asset inventory, restrict who can export it, and have DeployOpen or your internal assessors prepare the controls and evidence for your assessment. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do that work.

What the Nagios XI and Checkmk costs actually cover

Nagios XI cost starts with a perpetual license priced per node, so the one-time purchase grows with the number of nodes you license. Most sites also pay for the Enterprise add-on and annual maintenance renewals. Maintenance is the recurring line that matters most, because it covers updates and vendor support. Take the node tier, the add-on price and the renewal amount from your own contract or a written Nagios quote. Check whether the renewal covers every node you now run, not only the count on the original order, and confirm in writing what happens to your entitlement if maintenance lapses.

Checkmk pricing is published on the Checkmk editions page. Checkmk Community is free and open source software, and the page describes it as suited to small infrastructures and scalable to about 100 hosts. The commercial editions are billed per month with annual billing: Pro at 190 euros per month and the top tier at 275 euros per month, both billed annually, plus the Cloud edition at 240 euros per month billed yearly, capped at 50,000 services. These are list figures from that page. Confirm current rates, taxes and currency terms with Checkmk, and ask whether the price changes with your host or service count.

Both products share costs that sit outside the license. Budget for the servers or virtual machines that run the core, the web interface and the notification path. Budget for storage for metric history, which grows with host count and check frequency, and for staff time spent on configuration, upgrades and testing. Someone must also watch the monitoring server itself, because a monitor that fails silently leaves you blind. Costs rise with the number of hosts, the check interval, the number of sites in a distributed setup and the number of administrators changing configuration. For a written quote, ask for a line per item: license or subscription by node, host or service count, support tier, add-ons such as Synthetic Monitoring (available only with Pro and the top tier), server sizing assumptions, and whether upgrades and migration help are included.

What a move from Nagios XI to Checkmk involves

The sequence moves XI hosts, checks and alerting into a Checkmk site through discovery and rule-based configuration, with both systems running side by side until the new site is trusted to page the right people.

Inventory hosts, checks and notifications in XI
Export the host list, service checks, contact groups, notification rules, escalations and dashboards or reports from Nagios XI. Your monitoring or platform team typically does this work, with help from whoever owns the on-call rota. The customer provides read access to the XI server and its configuration, and names the owners of each host group. The step is done when every host and check is tagged as keep, replace or retire, and each notification path has an owner who has signed off on it.
Choose the edition and install the Checkmk site
Decide between Checkmk Community and a commercial edition based on the features your inventory needs, such as push-mode agents, automatic host registration or synthetic monitoring, which the editions page limits to higher tiers. Install a site on a supported Red Hat-based system, SUSE Linux Enterprise Server, Debian or Ubuntu, or deploy the Docker container image, following the setup guide. Your infrastructure team typically performs the installation and the customer supplies the servers, network access and service accounts. The step is complete when the site starts, the web interface loads and the team has confirmed which core the site runs on.
Re-run service discovery instead of copying checks
Add hosts to the new site and run service discovery so Checkmk proposes services from the hosts themselves, rather than importing XI service definitions line by line. Review each proposed service, accept the ones that match your inventory and remove duplicates. Monitoring engineers typically do this work with the application owners, and the customer must provide access to hosts and confirm which services are business critical. The step is done when every host in the inventory has a reviewed service list and the differences from XI are documented.
Keep legacy Nagios plugins as active checks
Identify checks that depend on custom scripts or vendor plugins that discovery does not cover. Wrap the existing plugin as an active check in the new site and test its output and exit codes against the XI results. Engineers who wrote or maintain those scripts usually do this, and the customer must supply the scripts, their dependencies and any credentials they need. The step is complete when each legacy plugin returns the same state as in XI on a known-good and a known-bad host.
Rebuild notifications, thresholds and reports
Recreate contact groups, notification rules and escalation paths in Checkmk, then rebuild the reports and dashboards your managers use. Thresholds should be set with the service owners, not copied silently from XI. The customer must sign off on alert thresholds and the on-call routing, and the team should test each notification channel, such as email, chat or paging. The step is done when a test alert reaches every intended recipient and each report has been compared with its XI counterpart and approved.
Run both systems in parallel
Keep XI active and collecting while Checkmk runs the same checks and sends notifications to a test group or in a limited capacity. Compare alert timing, false positives and missed states over a period the operations team agrees in advance. The operations lead and the service owners review the differences, and the customer provides a change window for any changes to production hosts. The step is complete when the team has reviewed the discrepancies and closed or accepted each one in writing.
Cut over and retire Nagios XI
Switch notifications and dashboards to Checkmk, disable XI checks and notifications, and keep a read-only copy of its configuration and data for audit and reference. Your platform team carries out the cutover in an agreed change window, and the customer confirms the rollback plan and who approves it. Before retiring the XI licenses or servers, confirm the terms of your Nagios XI agreement with Nagios. The step is done when Checkmk is the only system sending production alerts and the archive has been verified.

Questions buyers ask before switching from Nagios XI to Checkmk

What drives the cost of moving from Nagios XI to Checkmk?

The migration cost is driven by the size and complexity of the estate, not by a single list price. The main drivers are the number of hosts and services, how many custom Nagios plugins you run, how many notification rules and escalation paths you maintain, and how much reporting you need to rebuild. Costs fall into two groups. One-time costs cover planning, rebuilding checks and notifications, testing and the parallel run. Recurring costs cover servers, Checkmk edition fees if you choose a commercial edition, and ongoing administration. When you request a quote, ask for each cost component separately, and ask which items are your team's effort and which are delivered by DeployOpen under the written scope.

How long does a Nagios XI to Checkmk migration take?

The timeline depends on the scope, and it must be agreed in writing before work starts. No reliable duration can be given without knowing the host count, the number of custom plugins, the notification design and the reporting requirements. A small, standard estate with few custom checks will move far faster than a large environment with many integrations. Ask for the phases, the deliverables for each phase, and the points where your team must approve or test before the next phase begins. Also ask how the parallel run will be scheduled, because that period usually determines when the old system can be retired.

What does the migration need from our own team?

The work needs named people on your side, and the most common delays come from waiting for them. Plan for access to the Nagios XI server and its configuration, access to the target Checkmk servers, and a named owner for each group of checks who can confirm that a check still matters. You will also need approvers for notification changes, because alert routing affects on-call staff. Security or change management teams may need to approve firewall rules for agents and remote checks. Ask the implementation partner to list every access request and approver in the written scope so that these dependencies are visible from the start.

Can our team migrate from Nagios XI to Checkmk without outside help?

A capable team can usually migrate a small, standard estate alone, especially if the checks are mostly standard plugins and the notification model is simple. Checkmk's setup guide and product documentation cover installation and configuration, and service discovery replaces most manual copying of service definitions. Even so, plan for a parallel run in which Checkmk and Nagios XI monitor the same hosts, so you can compare alerts before cutting over. Larger estates, custom plugins, distributed monitoring and strict change controls are where outside help tends to save the most time. Decide early which parts your team will own and which parts you want delivered and documented by DeployOpen.

Is Checkmk Community enough for our infrastructure?

Checkmk Community may be enough for small infrastructures. The Checkmk editions page describes Community as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. If your estate is larger, or you need the features below, compare the commercial editions before you commit. Pro adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support. Ultimate adds full-stack observability, multi-tenancy, advanced security compliance and automated mass rollouts. Push-mode agents and automatic host registration are Ultimate features, and Synthetic Monitoring is an add-on available with Pro and Ultimate. Check these details against the current editions page before you plan.

Which Nagios XI checks and notifications will break during migration?

Checks that rely on Nagios-specific behavior, such as custom scripts that expect particular exit codes, output formats or environment variables, are the most likely to need changes. Notification rules that depend on Nagios contact groups, time periods or escalation chains must be rebuilt in Checkmk's rule model, so they should be tested with real alerts before cutover. Dashboards and scheduled reports will also need to be recreated. Ask for an inventory of every active check, notification and report, and a test plan that shows which items were verified in the parallel run and which were retired on purpose. Legacy Nagios plugins can be kept as active checks where they are still needed.

How do we ask for a quote for this migration?

Ask for a quote based on a written scope. DeployOpen does not publish a price list, so the price follows from the scope, deliverables and timeline that both sides agree in writing before work starts. To prepare, gather your host and service counts, a list of custom plugins and their owners, your notification and escalation design, your reporting requirements, and the target Checkmk edition or Community. Also state whether you want a parallel run, documentation, training for your team and ongoing support after cutover. Ongoing support and upgrades are available as retainers, so ask for those to be quoted separately from the one-time migration.

How DeployOpen helps evaluate and migrate from Nagios XI

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source monitoring inside your own infrastructure, so the Nagios XI vs Checkmk decision rests on your hosts, checks and edition needs. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory of Nagios XI nodes, hosts, services, plugins and custom checks, with the node count your license covers
Review of which checks can be re-discovered in Checkmk and which need legacy Nagios plugins kept as active checks
Decision record on Checkmk Community or a commercial edition, based on the features your teams rely on today
Written scope listing deliverables, environments and timelines before any work starts, with a quote following from that scope

How we build

Install Checkmk in a test environment using the package or Docker option your platform team supports
Rebuild notifications, contact groups and escalation rules in Checkmk and test them against real alert paths
Set up distributed monitoring for remote sites and confirm firewall and certificate requirements
Test alert volume, discovery results and dashboard coverage against the current Nagios XI baseline before cutover

How we hand over

Run-books for discovery, rule changes, site upgrades and backup of the Checkmk site configuration
Documented mapping from each Nagios XI check and notification to its Checkmk equivalent, with open gaps listed
Hands-on knowledge transfer to the operators who will own rules, users and monitoring agents day to day
Evidence pack of configurations, test results and access settings for your internal or external audit reviews

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer scope covers patching of Checkmk sites and plugins at the cadence agreed in writing
Confirm with your Checkmk edition provider which support tier your environment requires before go-live
Periodic review of rule sets and host discovery as your infrastructure changes over time

Nagios XI vs Checkmk