SolarWinds Network Performance Monitor vs Checkmk: which fits your network
Start with the trigger. If a renewal notice, a licensing change or a requirement to keep network monitoring on your own servers has forced the question, the useful test is whether your team needs what NPM does as a product or only needs SNMP visibility at a lower operating cost. NPM fits best when the estate is built around Orion: teams already using NetPath for path analysis, PerfStack for correlating metrics across views, and a vendor support contract they treat as a requirement. Checkmk fits when the estate is SNMP-heavy, when you want self-hosted control of the monitoring server, and when a free starting point matters. Checkmk Community is free and open source, with the option to move to Pro or Ultimate later if you need distributed monitoring or push-mode agents.
Confirm the feature gaps before you commit. The editions page places distributed monitoring in Pro and automatic host registration and push-mode agents in Ultimate, so a multi-site design with agent-based hosts may push you off the Community tier. Ask the Checkmk team for a current feature matrix for your target edition, and test SNMP discovery and interface bandwidth checks against a representative sample of your switches, routers and firewalls before you plan a full rollout. Check whether your NPM dashboards depend on NetPath or PerfStack, since those workflows have no direct Checkmk equivalent and will need a different reporting approach.
The decision turns on four things: total device count, the number of remote sites that need local polling, whether you need push-mode agents on servers and endpoints, and your team's capacity to run a monitoring server. Count devices and sites first, because they determine whether Community is enough or whether a commercial edition is needed for distribution. Then ask who will patch, back up and upgrade the server, and how many hours a month that takes. A team with a small platform group can run Checkmk well, but the operating effort is real, and it is the number most often underestimated when comparing a licensed product with a self-hosted one.
Which option fits which network team
This table matches common network team situations to the better fit between SolarWinds NPM and Checkmk, and names the condition that tips each one. Read each row against your own device count, site layout and staffing, since the answer often depends on one constraint.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Single site with a few hundred SNMP devices | Checkmk Community or Pro | Polling is local and the team can run Linux. Community covers small infrastructures, and Pro adds distributed monitoring if sites grow. |
| Many remote sites with limited links | Checkmk Pro or Ultimate, or NPM | Checkmk distributed monitoring is a Pro feature. Stay with NPM if its existing remote polling engines already cover the sites and retraining costs more than the licence. |
| A renewal due soon | Checkmk, after a parallel run | Checkmk is worth testing only if the team can run both systems until interface, threshold and map coverage matches. A renewal date alone is not a reason to switch. |
| Regulated network that must stay on premises | Checkmk or NPM, both on premises | Both can run inside your own network. Checkmk appliances exist only for commercial editions, so confirm which deployment and support model your assessors expect. |
| Team with no Linux operators | NPM, or Checkmk Ultimate appliance | Checkmk Community and Pro are installed on Linux or as Docker images. An appliance is available only on commercial editions, so confirm operator skills before choosing. |
| Team already running Orion modules | NPM, for now | NetPath, PerfStack and other Orion-integrated workflows have no direct Checkmk equivalent. Keep NPM until your reports and path analysis are replaced or no longer needed. |
How Checkmk discovers devices and checks interfaces over SNMP
Checkmk builds its host list in two steps: you create a host, then run service discovery against it, which polls the device over SNMP and proposes the services it finds, such as interface, CPU, memory and temperature checks. Those proposed services are not final. Your team accepts, removes or re-labels them, then sets check parameters that decide when a service turns warning or critical. For interfaces, the parameters that matter most are operational state, error and discard rates, and utilization thresholds, and these are set per rule or per host rather than by a single global default. NPM, by contrast, polls the network for nodes and interfaces through its own discovery wizard and then applies thresholds through alert definitions and node or interface properties. The two models are different, so compare them by outcome, not by menu layout.
Before you plan any bulk import, confirm the specifics against the Checkmk setup documentation and your own devices. Check which SNMP versions your Community or commercial edition supports on your hardware, whether your switches and routers expose the interface counters you rely on (including 64-bit high-capacity counters for bandwidth), and how your vendor's MIBs appear in discovery. Run discovery on a pilot group of representative devices, record which services appear and which are missing, and compare the result with your current NPM interface list for the same devices. Grouping hosts into host groups and tags early keeps the parameter rules manageable, because a single rule can then cover every access switch at a site.
Plan for the operating effort that follows discovery. Each new device class may need its own parameter review, and every change to thresholds should be tested on a small group before it reaches the full estate, because noisy interface alerts are the most common reason teams lose trust in a new monitoring tool. Ask the Checkmk partner or vendor, in writing, which device types and SNMP features are covered for the editions you are considering, and ask how push-mode agents and automatic host registration apply to your environment. Those last two features are described on the editions page as Ultimate capabilities, so do not assume them in a Community deployment. Record the discovery results and parameter decisions in your runbook so the next engineer can reproduce the setup.
SolarWinds Network Performance Monitor vs Checkmk feature by feature
This table compares SolarWinds NPM with Checkmk on the capabilities network teams use most, from SNMP discovery to licensing. Checkmk cells reflect only the edition differences documented by Checkmk, so confirm any cell marked as a check item against the edition you plan to run before you decide.
| Capability | SolarWinds NPM | Checkmk |
|---|---|---|
| SNMP device discovery | Orion network discovery scans subnets and adds SNMP devices as nodes. Confirm discovery scope and credential handling with SolarWinds. | SNMP monitoring is Checkmk's core use case. Confirm the discovery rules and automatic host creation available in your chosen edition. |
| Interface and bandwidth checks | Interface polling and bandwidth utilization are core NPM functions. Confirm the counters and polling intervals for your device types. | Interface and bandwidth checks are supported through Checkmk's service checks. Validate counter coverage for your device models during a pilot. |
| Maps and dashboards | Network maps and customizable dashboards are included in NPM. Confirm map auto-generation and dashboard sharing for your Orion version. | Dashboards are available in Checkmk. Confirm whether network topology maps are included in Community or only in commercial editions. |
| Path analysis and performance trending (NetPath, PerfStack) | NetPath provides hop-by-hop path analysis and PerfStack combines metrics on one chart. Checkmk has no direct equivalent that is documented here, so confirm the gap before migrating. | No documented equivalent to NetPath or PerfStack in the supplied materials. Ask Checkmk how time-series comparison and path tracing are handled in your edition. |
| Distributed monitoring | Additional polling engines extend NPM to remote sites. Confirm the number of engines and licensing impact with SolarWinds. | Distributed monitoring is listed for Pro and Ultimate. Confirm whether Community supports remote sites before planning a single-server deployment. |
| Push-mode agents and synthetic monitoring | NPM is primarily agentless SNMP polling. Confirm whether agent-based or synthetic checks require other SolarWinds modules. | Push-mode agents and automatic host registration are Ultimate features. Synthetic Monitoring is an add-on for Pro and Ultimate only. |
| High availability | Orion offers high availability options through its own deployment guidance. Confirm the HA design, database requirements and failover testing with SolarWinds. | HA design is not covered in the supplied materials. Ask Checkmk how the monitoring site and distributed nodes fail over in your edition. |
| Install options and appliances | Orion installs on Windows Server with SQL Server. Confirm supported versions and sizing for your environment with SolarWinds. | Linux packages for Red Hat-based systems, SUSE, Debian and Ubuntu, or Docker images. Virtual and physical appliances are available only for commercial editions. |
| Licensing model | Commercial license with pricing set by quote. Ask SolarWinds for the license metric, maintenance terms and renewal conditions in writing. | Community is free and open source (GPL-2.0 source). Pro is listed from 190 euros per month and Ultimate from 275 euros per month, billed annually (Checkmk editions page). |
What free Checkmk Community covers and where Pro and Ultimate start
Checkmk ships in four editions: a free self-hosted Community edition and three paid options, Pro, Ultimate and Cloud. The cards below separate what Community covers from the features that begin at each paid tier, so network teams can match their SNMP scale and operating model to the right edition before they compare it with SolarWinds NPM.
Checkmk Community, free and GPL-2.0
Community is free and open source, licensed under GPL-2.0 and built on the Nagios core. The Checkmk editions page positions it for small infrastructures, easily scalable up to about 100 hosts. For a network team, this is the edition to test SNMP discovery, interface checks and bandwidth graphs against a representative subset of devices. Confirm that your host count, polling interval and retention needs fit this ceiling, and check which features your team needs before you commit to a production rollout on Community.
Pro edition and its operating scope
Pro is listed at 190 euros per month, billed annually, according to the Checkmk editions page. It adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support. Distributed monitoring matters most for NPM replacements with remote sites, because it lets you poll segments through remote sites rather than from one central server. Ask Checkmk whether 8x5 support covers your outage response window, and confirm current pricing and terms directly with Checkmk.
Ultimate edition and mass rollouts
Ultimate is listed at 275 euros per month, billed annually, and adds full-stack observability, multi-tenancy, advanced security compliance and automated mass rollouts. Push-mode agents and automatic host registration are Ultimate features per the Checkmk setup guide, so teams that depend on agent-driven registration across many endpoints should plan for this tier. Multi-tenancy is relevant if a managed service provider or a large enterprise separates customer networks. Confirm which of these features your environment actually requires before selecting this tier.
Synthetic monitoring as an add-on
Synthetic Monitoring is available only as an add-on with Pro and Ultimate, according to the Checkmk editions page. It is not part of the Community feature set. Network teams that want to probe service availability from outside their own segments need to price this add-on into the paid tier decision. Community covers SNMP device and interface monitoring, so this is a separate capability to evaluate, not a default. Ask Checkmk which synthetic probe locations and limits apply to your contract.
Cloud edition and its service cap
The Cloud edition is SaaS and is listed at 240 euros per month, billed yearly, capped at 50,000 services, according to the Checkmk editions page. This suits teams that want Checkmk without running the server themselves, but it moves monitoring data into a hosted service. If your network or compliance requirements call for on-premises operation, the self-hosted Community, Pro or Ultimate editions are the relevant comparison. Count your interfaces and checks against the 50,000 services limit before budgeting.
Quote questions before purchase
Prices on the editions page are listed per month and billed annually, but the total cost also depends on your host and service counts, support needs and the labor to run the platform. Ask Checkmk for written terms covering renewal, price changes, support hours and which features are included in each tier. Pair the quote with your own effort estimate for building the monitoring server, configuring SNMP discovery and maintaining checks, since that operating work is paid for by your team whichever edition you choose.
How distributed monitoring changes with the number of sites
When every device sits in one data centre on a local network, a single Checkmk site is usually the simplest design. The central server polls SNMP devices directly, and the main sizing question is how many hosts and services that one server will carry. Distributed monitoring adds value mainly when you need to split load or isolate segments, so the edition question is less pressing here than it is for remote sites.
- Edition check: Confirm with Checkmk which features you need in a single site. Distributed monitoring is listed as a Pro and Ultimate capability on the editions page, so Community may cover one site fully.
- Scaling check: Ask Checkmk how the Micro Core behaves on your hardware and check mix, since the commercial editions create new sites with it by default.
- Discovery: Plan SNMP discovery and rule sets on one site first, before adding complexity.
- Growth path: Note whether your expected host count stays within the range the editions page describes for Community.
Before you commit, check your own device count, service count and polling interval against a test site, because a single data centre rarely stays single for long.
Several branch sites on reliable links usually call for a central site that aggregates results from remote sites. In Checkmk this is handled by distributed monitoring, where each remote site runs its own checks and reports to a central instance. The design choice is whether the branches are polled over the WAN from the center or monitored locally and reported upward, and the answer changes what the central server must sustain.
- Edition check: Distributed monitoring is a Pro and Ultimate feature according to the editions page. Community is described as free and suited to small infrastructures, so confirm your branch count against that scope before you plan.
- Remote reporting: Decide whether each branch site polls its local devices and sends results to the center, which keeps SNMP traffic local.
- Central load: Measure how many services the central site receives from all branches combined, not only its own devices.
- Operations: Ask who patches and backs up each remote site, since every site is a separate installation to maintain.
Ask Checkmk to confirm, in writing, whether your chosen edition includes the distributed features your branch design needs.
Remote or segmented sites with limited connectivity change the design more than the count of sites does. A remote site may lose its WAN link, sit behind a firewall that allows only outbound traffic, or belong to an OT or regulated segment that must not accept inbound connections. In these cases the remote site must buffer and report results when the link returns, and the central server must tolerate gaps without losing history.
- Connectivity: Map which direction each connection may open, and whether push-mode agents are an option. Push-mode agents and automatic host registration are Ultimate features per the setup guide.
- Buffering: Ask Checkmk how a remote site behaves during an outage and how its data is resynchronized afterward.
- Installation: Confirm which packages or container images your segment permits, since appliances are available only for commercial editions.
- Central capacity: Size the center for the catch-up burst after an outage, not only steady-state load.
The CMC benchmark figures in the Checkmk docs (more than 600,000 checks per minute on a desktop Core i7, and a configuration of 20,000 hosts and 600,000 services loading in about half a second) are vendor-reported. They show what that test achieved on that hardware and check mix, and they do not prove your site will sustain the same load across a WAN with your checks, your polling intervals and your hardware. Run a proof of concept with your own check mix before relying on any benchmark figure.
Where monitoring data lives and who operates the platform
Checkmk's hosting choice decides where device inventories, SNMP credentials and alert history sit, and who can change them. The four cards below cover the decisions a network team should settle before replacing SolarWinds Network Performance Monitor (NPM), in the order an assessor or security reviewer is likely to ask about them.
Data location and hosting
Self-hosted Checkmk Community and commercial editions run on your own Linux hosts (Red Hat-based, SUSE, Debian or Ubuntu) or as Docker container images, so host inventories, SNMP community strings and check results stay in your network. The Checkmk Cloud edition is a different data location: it is operated by Checkmk as SaaS, so confirm with the vendor where tenant data is stored before you put device data there. Map each option to your data residency rules.
Hosting model and appliances
Community is free, open-source software built on the Nagios core, and it is intended for smaller infrastructures. Pro and Ultimate are commercial editions that add distributed monitoring, and they can be deployed as virtual or physical appliances, which Community does not offer. Choose the model before procurement, since moving a site from Community to a commercial edition is a licensing and migration decision, not a configuration change.
Identity and change control
Ask who can add hosts, edit SNMP credentials and change alert thresholds, and whether those roles are separated from people who only read dashboards. Checkmk's push-mode agents and automatic host registration are Ultimate features, so if you rely on them, plan the access model for that edition. Confirm how the chosen edition integrates with your directory and single sign-on before go-live, and record who holds the site administrator role.
Audit trail and assessment evidence
An assessment will ask for proof of what was monitored, what changed and who changed it. Keep exported host and rule configurations under version control, retain site and notification logs for an agreed period, and document the backup and restore steps for the monitoring site. DeployOpen can prepare these systems, controls and evidence for an assessment, but independent auditors and certification bodies issue any audit report or certification.
What each option costs to own beyond the license line
The license line is the smallest part of the comparison for most network teams, so start by listing every component on both sides. For SolarWinds NPM, the Orion license is only the first item: the Windows and SQL Server hosts that run the platform, their storage, backup, patching and database administration all carry recurring cost. For Checkmk, the Community edition is free to download and run, but the hardware, the monitoring server or site, the Linux operating system, and the staff who maintain them are still yours to fund. Checkmk's editions page lists Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually, and a Cloud edition at 240 euros per month billed yearly. Confirm with Checkmk whether any quoted fee changes with host count, service count or support level before you compare totals.
Separate one-time work from recurring work. One-time items include the initial SNMP discovery, designing the rule and threshold set, building maps and dashboards, exporting NPM inventory, and running a parallel period until coverage matches. Recurring items include subscription fees, vendor support, operating system and Checkmk upgrades, certificate and credential rotation, and the regular review of alerts that fire too often or not at all. Cost rises most when the number of devices, interfaces and services grows faster than the rule set is maintained, and when distributed sites need their own hardware and patch windows. Commercial Checkmk editions also gate features such as push-mode agents and automatic host registration to Ultimate, which affects how much manual onboarding staff time you should budget for.
Ask every vendor and integrator for a written quote that breaks out: license or subscription fees by year, the number of hosts and services each price covers, which edition includes distributed monitoring and synthetic checks, the hardware or virtual machine sizing for the central server and each remote site, support hours and response terms, and who performs upgrades and backups. For the self-hosted path, add an explicit line for staff time, including the people who will own alert tuning and on-call response. The biggest unknown is usually labor, so ask each side to state assumptions about how many hours of template and rule work the migration needs, and test those assumptions on a pilot segment before you sign.
What a move from NPM to Checkmk involves at a high level
The sequence moves the NPM device inventory into Checkmk, rebuilds monitoring and alerting there, and retires NPM only after both systems show matching coverage. Each step has a clear owner and a check that confirms it is finished.
Inventory nodes and interfaces in NPM
Your network team exports the node list, interface list, custom properties and polling settings from NPM using the export methods your NPM version supports, such as the Orion SDK or SWQL queries. Your team also gathers the SNMP community strings or SNMPv3 credentials and the devices that need them, since Checkmk cannot read these from NPM. Your team confirms it is done when every device in scope appears in a spreadsheet or file with its IP address, device type, interfaces and a named owner, and the credential owner has signed off on who may hold each credential.
Install Checkmk on Linux or Docker
Your platform or monitoring engineers install Checkmk Community on a supported Linux distribution from the Checkmk packages, or run the Docker container image, and create the first monitoring site. Choose the edition before this step, because appliance installs and some features are limited to commercial editions. The step is complete when the site starts, the web interface is reachable only from your management network, and a test host can be added and checked.
Run SNMP discovery and bulk host creation
Your engineers use the exported inventory to create hosts in Checkmk in batches, then run service discovery per host so Checkmk finds interfaces and other SNMP services. Engineers review what the discovery found against the NPM inventory and remove services that are not wanted. This step is finished when each device in scope has a host object, discovery has been accepted for each one, and the count of hosts and interface services matches the inventory list within a documented exception list.
Rebuild thresholds, dashboards and maps
Your team recreates the thresholds that matter from NPM alert definitions and performance baselines, such as interface utilization, error counters and device availability. Engineers also rebuild the network views people rely on, using Checkmk dashboards and the topology tools available in your edition, and note any NPM map feature that has no direct equivalent. The step is done when a network owner has reviewed each rebuilt threshold and view and marked any gap that needs a decision.
Run both systems in parallel
NPM and Checkmk poll the same devices while your team compares their results for availability, interface state and bandwidth over an agreed period. Engineers record every mismatch, such as a missing device, a discovery gap or a threshold that fires differently, and fix the cause in Checkmk. Parallel running ends when the mismatch log is empty or every remaining difference has a written decision from the network owner.
Cut over alert notifications
Your operations team moves notification routes from NPM to Checkmk, including email, chat, ticketing and paging integrations, and tests each route with a controlled alert. The alert inventory from the first step is the checklist, so every alert either has a Checkmk equivalent or a recorded retirement decision. The step is complete when each test alert reaches its recipient and the on-call owner confirms the routing.
Retire NPM with owner sign-off
The service owner and security team approve turning off NPM polling, then your team archives the NPM configuration and any reports the organization must retain, and removes stored SNMP credentials from NPM. Records are kept under your own retention rules, and the decision is written down with the approvers' names. The step is finished when NPM no longer polls any device, the archive is verified as readable, and the written sign-off is filed with the change record.
SolarWinds Network Performance Monitor vs Checkmk: what buyers ask first
How much effort does moving from SolarWinds NPM to Checkmk take?
The effort depends mostly on how many devices, interfaces and alert rules you need to rebuild, and on how closely your NPM setup is customized. Checkmk can discover SNMP devices and build host and service checks, but thresholds, maps, reports and notification routing still have to be recreated and checked against what NPM does today. Teams with a clean inventory and few custom alerts usually have less rebuild work than teams with years of tuned thresholds. Ask any implementation partner for a written scope that lists the device count, the alert and map inventory, and the parallel run period before agreeing on effort.
How long does an NPM to Checkmk migration take?
No timeline can be stated from the researched facts for this migration, so treat any duration you hear as an estimate until it is written down. The main drivers are the size of the device inventory, the number of custom alerts and dashboards, the number of remote sites that need a distributed setup, and how long you choose to run both tools in parallel. Ask for a fixed-scope plan with deliverables and dates agreed in writing before work starts, and confirm which parts depend on your change windows and on access to the network.
What does the migration need from our own team?
Plan on time from network engineers who own the device list, SNMP community or SNMPv3 credentials, and the business meaning of each alert. You will also need someone who can export NPM data through the Orion SDK or SWQL, and an owner for the Linux host or container that runs Checkmk. Monitoring staff should review rebuilt thresholds and sign off on which NPM reports still matter. Confirm these roles in the scope so that nothing waits on an unnamed person during the overlap period.
Can we run the migration ourselves with the free Checkmk edition?
Yes, the Community edition is free and open source, and it can be installed on supported Linux distributions or as Docker container images. It is described as suitable for small infrastructures and scalable to about 100 hosts, so larger estates should check the edition fit before committing. Community is built on the Nagios core, and the commercial editions use the Checkmk Micro Core by default. Your team must cover installation, backups, upgrades and monitoring of the monitoring server. Compare that effort with the support you would need, and confirm the host count and architecture with Checkmk before deciding.
Does Checkmk Community cover distributed monitoring and push-mode agents?
The researched facts place distributed monitoring in the Pro and Ultimate editions, and place push-mode agents and automatic host registration in Ultimate. Community is positioned for smaller environments, so remote sites with heavy polling needs should be checked against the edition list before design work starts. Confirm the exact feature set for your target version directly with Checkmk on the editions page, because the feature split can change between releases. If your design depends on remote polling or push agents, put that requirement in the written scope and price the edition that includes it.
What do Checkmk Pro and Ultimate cost, and what do they include?
The Checkmk editions page lists Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually. 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, and includes push-mode agents and automatic host registration. Synthetic Monitoring is an add-on available only with Pro and Ultimate. Confirm current pricing, tax treatment and any device or service limits with Checkmk, since the figures come from the published editions page and may change.
Can DeployOpen plan and run the migration for us?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, so a Checkmk migration falls within that scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so ask for a written proposal that covers the device inventory, alert rebuild, parallel run and handover.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements and documents self-hosted monitoring inside your own infrastructure, including the choice between Checkmk and SolarWinds Network Performance Monitor for your SNMP estate. We start with a written scope so device coverage, edition decisions and the parallel-run period are agreed before any build work begins.
How we scope
- Inventory the SNMP devices, interfaces and bandwidth checks your NPM instance currently covers.
- Decide which Checkmk edition fits each site, comparing Community limits with Pro and Ultimate features.
- Agree in writing whether distributed monitoring, push-mode agents or synthetic checks are in or out of scope.
How we build
- Install Checkmk on your chosen Linux distribution or container host inside your own network.
- Configure SNMP discovery, host tags, interface checks and alert thresholds to match your NPM baseline.
- Test device discovery and alert behavior in a parallel run until coverage matches what NPM reports.
How we hand over
- Document the site layout, host groups, check rules, notification setup and the NPM-to-Checkmk mapping.
- Provide operator runbooks for adding devices, tuning thresholds and handling distributed site failures.
- Walk your network team through the handover and record which NPM functions were retired or replaced.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Checkmk version upgrades, backup checks and review of new device coverage.
- Ask for a quote based on the written scope, which sets the deliverables and timeline before work starts.
