Migrate from SolarWinds NPM to Checkmk

Migrate from SolarWinds NPM to Checkmk: what the move involves

Whether the trigger is a renewal, a licensing change or a plain wish for self-hosted control, the move from SolarWinds Network Performance Monitor to Checkmk is an inventory, discovery and alert-rebuild project that runs alongside NPM until the two agree. Nothing about the switch is a single cutover. Your network engineers usually carry most of the work because they know which devices matter, which interfaces are business-critical and which thresholds were tuned over years. An implementation partner is useful for building the Checkmk site, standardizing the rules and writing the handover, but the people who own the network should decide what gets monitored and what counts as an alert. Start by confirming who in your team owns each device group, since those owners sign off on the discovered inventory. The effort is driven less by the software than by how much NPM configuration has accumulated. Count the nodes, interfaces, custom properties and alert definitions you actually use before estimating anything, and ask any vendor or partner to quote against that written inventory. Checkmk Community is free and open source software, and it is a sound choice for smaller estates, with the editions page describing it as scalable to about 100 hosts. Larger or multi-site networks should compare Pro and Ultimate. The editions page lists distributed monitoring and automation in Pro, and automated mass rollouts, push-mode agents and automatic host registration in Ultimate, with Ultimate features also described in the setup guide. Confirm current prices directly on the Checkmk editions page, because those figures recur annually and change the total cost of ownership. The main risk is a gap in coverage that nobody notices until an outage. Plan a parallel run long enough to compare alerts from both systems on the same devices, and track each NPM alert you intend to retire against a Checkmk equivalent before you disable it. Verify SNMP credentials, polling intervals and interface naming on a sample of devices early, because those details decide whether discovery is trustworthy. Keep NPM read-only for historical reference, and record which decisions you made and why, so the handover is auditable.

Which NPM capabilities map cleanly to Checkmk

This table maps the main Network Performance Monitor capabilities to their Checkmk equivalents and marks each as clean, needs rework or gap. Use it to scope the migration before any export work starts. Confirm every feature not covered by the supplied facts against Checkmk's current documentation, and check which edition your design depends on.

Capability	Checkmk equivalent	Status	What to confirm
Node and interface inventory	Host and service discovery, bulk host creation from exported node and interface lists	Clean	Confirm the bulk import method for your Checkmk version and how custom properties map to host tags
SNMP polling of devices	SNMP-based discovery and checks, with Community edition covering standard SNMP monitoring	Clean	Test vendor-specific MIBs on a sample of devices before bulk rollout
Interface and bandwidth checks	Interface discovery with traffic and error checks	Needs rework	Rebuild thresholds per interface class, since NPM alerts may be defined per node or per group
Alert thresholds and notifications	Check parameters and notification rules	Needs rework	Recreate each NPM alert definition by hand or by script, then verify notification routing
Distributed monitoring across sites	Distributed monitoring, available in Pro and Ultimate editions and not in Community	Gap in Community	Price the Pro or Ultimate tier if remote polling is required, per the editions page
Automatic host registration and push-mode agents	Push-mode agents and automatic host registration, Ultimate edition only	Gap in Community	Decide whether pull-mode polling is sufficient before selecting an edition
Network maps	Dashboards and views built from host and service data	Needs rework	Confirm the map or topology features in your edition and rebuild layouts manually
NetPath-style path analysis	No direct equivalent in the supplied facts	Gap	Ask Checkmk whether a path analysis feature exists, or plan to keep NPM for this use case during overlap
Reporting and historical analysis	Advanced analytics and reporting, included in Pro and Ultimate editions	Needs rework	Export historical NPM data before cutover and confirm what Community reporting covers

What to export from Orion and what to rebuild in Checkmk

The migration splits into two kinds of work: data you pull out of Orion through the SDK and SWQL, and configuration you recreate by hand in Checkmk. Planning should treat the first as a repeatable export and the second as a deliberate rebuild, with historical reports decided separately.

Nodes exported through the Orion SDK

Use the Orion SDK and SWQL to pull the node inventory, including hostnames, IP addresses, vendors, and polling status, into a flat file. This list becomes the seed for bulk host creation in Checkmk and the baseline for SNMP discovery. Before you trust it, compare the exported count against the Orion node list, and confirm which nodes are unmanaged, retired, or duplicated under two names.

Interfaces and their polling state

Export interface records per node, including interface names, indexes, types, and whether each interface is currently polled. Checkmk service discovery will find many interfaces on its own, so the export matters mainly for deciding which interfaces must stay monitored and which were excluded in Orion. Flag interfaces that were tuned to skip noisy ports so those choices are carried over deliberately.

Custom properties as host tags

Export the custom properties your team used for location, owner, site, or service tier. In Checkmk these map most naturally to host tags and host labels, which then drive rule matching and folder layout. Agree on the tag scheme before the bulk import, because renaming tags after hosts are created means touching every host again.

Alert definitions to rebuild

Alert definitions in Orion do not transfer as a routine export. Inventory each alert with its trigger condition, threshold, severity, and suppression window, then recreate the intent as Checkmk check parameters and notification rules. Expect some Orion alerts to fold into one Checkmk rule, and expect a few to disappear once you see what they actually protect.

Maps, credentials, and notification integrations

Network maps, SNMP community strings or SNMPv3 users, and notification transports such as email relays, chat webhooks, and ticketing hooks must be recreated by hand. Credentials should move into Checkmk's password store, not into plain host attributes. Ask the team to confirm who owns each credential and which notification endpoints still exist before cutover.

Historical performance data per report

Historical performance data does not move as a routine step. Decide report by report whether you need the raw history, a summarized archive exported to CSV, or nothing beyond the overlap period. Reports used for audits or capacity contracts usually justify archiving, while dashboards nobody opens do not. Record the decision in the migration plan so it is not reopened at cutover.

How the migration sequence runs from inventory to decommission

The sequence moves NPM's device inventory into Checkmk in controlled stages, proving each stage with a written output before the next one starts. The goal is a cutover where Checkmk covers the same nodes, interfaces and alerts that NPM did, and nothing is lost in between.

Export and reconcile the NPM inventory
Pull nodes, interfaces, custom properties and current alert definitions from Orion using the Orion SDK and SWQL queries, then reconcile the export against what the network team knows about the estate. Remove retired devices, duplicate hostnames and stale entries, and tag each host with the site, role and owning team that Checkmk folders and rules will need. The output is a reconciled host list with one row per device, its management address, SNMP settings where known and an owner. The step is done when the owners of the sites have signed off that the list matches the live network.
Run a pilot site with bulk host creation
Choose one site with a manageable number of devices and a team that can review results quickly. Create its hosts in Checkmk in bulk from the reconciled list, organized into folders that mirror the site structure, then run SNMP discovery against them and review what Checkmk finds. Compare the discovered services with the interfaces and nodes NPM reports for the same devices, and correct community strings, SNMP versions and host tags where they differ. The output is a pilot discovery report that lists matched devices, missing services and devices needing manual SNMP changes. The pilot closes when those gaps are either fixed or recorded with a reason.
Extend discovery to the remaining sites
Apply the same bulk creation and discovery pattern to the remaining sites in waves, reusing the pilot's SNMP and folder conventions so that each wave needs fewer corrections than the one before. Keep a running register of devices that Checkmk cannot poll, such as those with restricted SNMP access or vendor-specific OIDs, and assign each one to a named engineer. The output is a complete Checkmk host inventory with a per-site status register. Each site is complete when its discovery review is signed off.
Rebuild alert thresholds and maps
Translate the NPM alert definitions from the export into Checkmk check parameters and notification rules, grouping them by severity and by the teams that receive them. Rebuild dashboards and network maps in Checkmk to show the same sites and links the operations staff use in NPM today. Review each rebuilt rule with the on-call team, because thresholds that were carried over unchanged can be too sensitive or too loose on a different collection model. The output is a signed-off alert set that lists each NPM alert, its Checkmk equivalent and the owner who approved it.
Run both systems in parallel
Keep NPM polling and alerting while Checkmk runs the same estate, and compare the two systems on a regular cadence. Check that device status, interface up and down events, and threshold breaches appear in both, and log each divergence with its cause, such as a discovery gap, a timing difference or a missing rule. Fix the causes and rerun the comparison until the differences are explained and accepted. The output is a coverage comparison report showing matched devices, matched interfaces, matched alerts and the open exceptions. Parallel running ends when that report shows coverage that the network owners have accepted in writing.
Cut over alerting and notifications
Move notification delivery to Checkmk for each site, starting with the lowest-risk sites and confirming that on-call engineers receive test alerts through the channels they use. Disable the matching NPM alerts only after the Checkmk path has been verified for that site, so no device loses coverage during the switch. Record the change date and the approver for each site. The output is a cutover log showing which sites now alert from Checkmk and the test results that confirmed delivery.
Archive history and decommission NPM
Export the historical reports and performance data you need for audit, capacity planning or incident review before shutting down Orion, and store them in a location the security team approves. Decide what can be discarded, then stop NPM polling, remove its credentials from devices and retire the Orion server and database according to your retention policy. Confirm that no monitoring integration still points at Orion. The output is a decommission record that lists archived artifacts, removed credentials and the owner who signed off the shutdown.

How discovery and thresholds get rebuilt in Checkmk

In Checkmk, the node polling that NPM performs is replaced by two steps: bulk host creation, which registers the devices exported from Orion, and service discovery, which asks each host which SNMP interfaces, disks and sensors it exposes. Discovery produces a proposed service list, and that list is the thing to review before any alerting goes live. Confirm that SNMP credentials and community strings work on a sample of devices from each vendor family first, because a discovery run against a host that rejects the credentials returns an empty or misleading service list rather than an error that is easy to spot. Checkmk's setup guide, linked from this page's sources, describes the installation and host onboarding steps you will follow.

Thresholds should not be copied one-for-one from NPM. Orion alert thresholds were often set per node or per interface during years of tuning, and copying them into Checkmk recreates that drift. A better approach is to define check parameters per host group, such as core switches, edge routers, firewalls and access switches, and apply them through rules. Then review the high-utilization and error-rate rules with the operators who acknowledge those alerts today, and keep a short list of the exceptions that really need a per-host override. This also makes the Community and commercial edition decision easier, because the rule set is the same either way.

The engine underneath matters for how fast these checks run. The commercial editions create new sites with the Checkmk Micro Core (CMC) by default, while Checkmk Community is built on the Nagios core, which the commercial editions keep only as an optional core for migration. Checkmk's own documentation reports that the CMC executed more than 600,000 checks per minute on a desktop Core i7 and loaded a configuration of 20,000 hosts and 600,000 services in about half a second. These are Checkmk's published benchmark claims, not results from your network, so run a timed discovery and check cycle on your own largest site before relying on them. Confirm with Checkmk which core a Community site uses before you plan capacity.

How the migration differs by estate size and starting point

A small estate is the case where the free Checkmk Community edition is most likely to fit. The editions page describes Community as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. For a team moving a single site of routers, switches, firewalls and a few servers, the work is mostly the inventory export and SNMP discovery, with no licence purchase needed.

Inventory count: Count nodes and interfaces in Orion before choosing an edition. If the total stays near the stated 100-host scale with room to grow, Community is the starting point.
Sites: A single monitoring site on one Linux host keeps the setup simple. Install from a Linux package or a Docker image, both available for Community.
Agents: Community covers SNMP and the standard agent model. Plan to deploy agents manually on servers that need them.
Core: Community runs on the Nagios core. Commercial editions default to the Checkmk Micro Core, so confirm which core you need for your check volumes.
Growth: If the estate is expected to pass about 100 hosts within the planning horizon, price Pro before go-live.

Before committing, confirm the host count and whether the team will need features beyond the free edition.

What drives cost and duration in the move

The cost of moving from NPM to Checkmk is set by a few decisions made early: which edition you run, how many devices and interfaces you bring across, how many alert thresholds you rebuild, and how many remote sites need collectors. Each card below names one of these drivers and the question to settle before anyone asks for a quote.

Edition choice drives the recurring bill

Checkmk Community is free and open source, but the editions page describes it as suited to small infrastructures, easily scaled up to about 100 hosts. Pro and Ultimate add distributed monitoring, automation and 8x5 support, and Ultimate adds automated mass rollouts and push-mode agents with automatic host registration. The editions page lists Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually. Confirm which features your NPM estate actually depends on before choosing an edition.

Device and interface count sets the server footprint

The number of nodes and interfaces you bring from Orion determines how many services Checkmk polls and how much storage the history needs. Export the counts from NPM first, then separate them into active devices and stale entries that should not migrate. Ask the implementation partner to size the Checkmk server against that written inventory, not against a rough estimate of the network.

Threshold rebuild volume is the largest one-time effort

Each NPM alert threshold, such as interface utilization or node availability, has to be rebuilt as a Checkmk rule set with matching notification behavior. The effort scales with the number of distinct alert definitions and with how many of them are overrides for specific devices. Count the alert definitions in the Orion export and group them by type before estimating rebuild hours. This work is one-time, but it recurs in part whenever a new device class is added.

Remote sites add collectors and network paths

Every remote site that NPM reaches through a poller or direct SNMP path needs a Checkmk site or a distributed monitoring setup to poll it reliably. Distributed monitoring is part of the Pro and Ultimate editions, so remote site count can move you up an edition. Document each site, its link capacity, and whether it sits behind a firewall that limits SNMP or agent traffic.

Parallel running and staff time

Running NPM and Checkmk side by side until coverage matches adds monitoring staff time for comparison, alert tuning and sign-off, and it extends the overlap period. Staff time is the main recurring cost after go-live, covering operations, patching, rule maintenance and on-call response. Ask for the effort split between one-time migration work and ongoing operations in any quote.

Request a quote from a written scope

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A useful quote lists the edition, the device and interface counts from the Orion export, the number of alert definitions to rebuild, the remote sites, and the parallel run period. Ask the partner to separate one-time migration fees from any recurring support or retainer, and to state what is excluded.

Effort drivers and how to keep each one down

This table lists the factors that most change the effort of moving from NPM to Checkmk, with the practical step that keeps each one manageable. Read each row as a lever you control before export starts, since most of the work is decided during inventory and cleanup rather than during the Checkmk build.

Driver	Why it changes effort	How to keep it down
Device count	Every node in Orion becomes a Checkmk host with discovery, rules and notifications, so the host list sets the size of the rebuild and the bulk import.	Export the node list through the Orion SDK, then drop retired, duplicate and decommissioned devices before any host is created in Checkmk.
Interface count	SNMP interface services multiply quickly on core and access switches, and each one can need its own threshold or bandwidth rule.	Monitor only operationally relevant interfaces, use service discovery rules to exclude down or unused ports, and set rules at folder level rather than per interface.
Custom property volume	Orion custom properties often hold owner, site and criticality data that must map to Checkmk host tags, folders or labels, and inconsistent values create manual fixes.	Audit custom properties before export, remove unused fields, standardize values such as site codes, and agree a tag scheme with the network team first.
Alert rule count	Each NPM alert definition has a threshold, scope and notification path that must be recreated as a Checkmk rule or check parameter, and many NPM alerts duplicate each other.	Group NPM alerts by intent (availability, interface errors, bandwidth, CPU), rebuild one rule per intent, and retire alerts nobody acted on in the last review cycle.
Remote sites	Remote locations need their own Checkmk site or distributed setup, and firewall rules, time sync and notification routing must be checked per location.	Plan the site layout from the device inventory, confirm which segments can reach the central site, and migrate one remote location at a time as a pilot.
SNMP v3 credential handling	SNMP v3 users, authentication and privacy passphrases must be re-entered or stored securely in Checkmk, and mismatched settings cause silent discovery failures.	Confirm which SNMP v3 users exist in Orion with the network team, store credentials in Checkmk's password store, and test one device per model before bulk discovery.
Map rebuild	NPM network maps and their layouts do not transfer as-is, so each map view must be recreated in Checkmk dashboards or a separate visualization tool, and the effort depends on how many views teams use.	Export a list of maps that are opened regularly, rebuild only those, and agree with users which views they need before starting.
Parallel run length	Running NPM and Checkmk side by side adds licensing and staff time for every week of overlap, and a longer overlap means more duplicate alerts to manage.	Set exit criteria in advance, such as matched device and interface coverage and reconciled alert volume, and ask your vendor for the license end date that aligns with that exit point.

Questions buyers ask before moving from NPM to Checkmk

How much effort does a move from NPM to Checkmk take?

The effort depends mainly on how many nodes, interfaces, custom properties and alert definitions you need to carry over, and how many of those alerts map cleanly to Checkmk checks. No supplied figure sets a duration, so ask for one based on your own inventory. The main drivers are:

The size and consistency of the Orion node and interface inventory
How many alert thresholds, maps and reports must be rebuilt by hand
Whether you run distributed sites that need their own configuration
How long you keep NPM running in parallel before you cut over

Ask any provider to break the estimate down by these items so you can see which parts drive the total.

Can our network team migrate to Checkmk without outside help?

Yes, a capable team can run the migration in-house, provided it has time, Linux administration skills and someone who knows the current NPM alerting well. Checkmk Community is free and open source software, and the Checkmk setup guide documents installation on Red Hat-based systems, SUSE Linux Enterprise Server, Debian, Ubuntu and as Docker images. The harder part is usually the alert and map rebuild, not the installation. If your team lacks spare capacity during the overlap period, an implementation partner can take the work under a fixed scope agreed in writing. DeployOpen plans and implements self-hosted platforms in your own infrastructure and does fixed-scope work like this.

What skills and staff time does a Checkmk migration need?

Plan for staff who understand SNMP, network device configuration and Linux server operations, because Checkmk discovery and service checks depend on them. Expect someone to own the Orion export, someone to run bulk host creation and SNMP discovery in Checkmk, and someone to validate alerts against real network events. Ongoing operations also need a named owner for upgrades and patches. Checkmk 2.5.0 was tagged on April 24, 2026, and patch 2.5.0p15 was tagged on September 30, 2026, so budget time for routine version updates. Confirm the required skills and hours with your provider before the work starts.

Can we keep NPM historical performance data after moving to Checkmk?

Historical data does not move automatically, so plan for an archive rather than a direct import. Export the inventory, interfaces, custom properties and alert definitions with the Orion SDK before you retire NPM, because those are the parts Checkmk needs to rebuild the monitored estate. For performance history, decide which reports and trend data your auditors or capacity planners still need, then export only that subset in a format you can read later. Confirm with your own compliance and records team how long NPM data must be retained, and keep NPM in read-only form for that period if the requirement applies.

What does an implementation partner add to a Checkmk migration?

A partner adds planned scope, written deliverables and experience running the steps in order, from Orion export and bulk host creation to threshold rebuild, parallel running and cutover. It does not replace your ownership of the network. Work is usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support or upgrades can follow as a retainer. DeployOpen implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure, and it prepares evidence for compliance assessments, although it does not issue audit reports. Ask any partner for a written list of what is included and what stays with your team.

Is Checkmk Community enough to replace NPM?

Checkmk Community may be enough for a smaller estate, but check the limits first. The Checkmk editions page describes Community as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. Pro adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support, and Pro is listed from 190 euros per month billed annually. Ultimate, listed from 275 euros per month billed annually, 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 requires Pro or Ultimate. Compare your NPM feature use against these lists, and confirm current prices with Checkmk before you decide.

What does a Checkmk migration cost over time?

The cost has one-time parts and recurring parts. One-time costs cover the inventory export, the Checkmk build, bulk host creation, alert and map rebuild, parallel running and testing, and any partner scope. Recurring costs cover the server infrastructure, operating staff time, support subscriptions if you choose Pro or Ultimate, and upgrades. Checkmk Community is free to use, so its licensing cost is zero, but staff time and hosting are not. Ask any quote to separate these categories and to state which items recur each year, and compare the total against your current NPM licence and hosting.

What usually goes wrong and how to prevent it

Most failed NPM-to-Checkmk migrations fail at the edges: the inventory export, the alert paths, and the credentials that polling depends on. The cards below describe each risk, why it matters for this move, and the check that prevents it before cutover.

Incomplete SWQL export

An export that pulls nodes but skips interfaces, custom properties or polling settings leaves Checkmk with a partial inventory that looks complete. Compare record counts per node type between the SWQL output and Checkmk host and service lists before any host is created. Export the node-to-interface relationships explicitly, since a host without its interfaces will not produce bandwidth checks. Keep the raw export files under version control so the baseline can be rerun.

Duplicate polling during overlap

While NPM and Checkmk run side by side, both systems may query the same routers, switches and interfaces with SNMP. On older devices this can raise CPU load, slow responses and skew interface counters. Before enabling Checkmk polling on a segment, list which NPM polling engines already cover it and agree on polling intervals with the network team. Stagger the two schedules and watch device CPU during the first full cycle.

Unmapped alert transports

NPM alerts often reach email, SMS gateways, ticketing hooks or chat channels through actions that are easy to forget because they live outside the alert definition. If these transports are not rebuilt in Checkmk notification rules, an outage can generate no notice at all. Inventory every NPM alert action, map each to a Checkmk notification method, and send a test notification for each one. Confirm the on-call contacts are current before the old alerts are disabled.

SNMP credential gaps

Many NPM deployments hold SNMP community strings or SNMPv3 users that were added over years and are not documented anywhere else. Devices that were polled through a shared credential may fail in Checkmk when the user or authentication settings differ, and the failures often appear only on a few older devices. Build a credential inventory from the NPM settings with the owners of each device group, then test each SNMPv3 user and community against a sample of every device model before bulk host creation.

Map and dashboard loss

Network maps, NetPath views and PerfStack dashboards are often the way operators read the network, and they do not move with the host list. Losing them during cutover leaves on-shift staff without their usual views. Document each map and dashboard NPM provides, then rebuild the critical ones in Checkmk views or with a dashboard tool such as Grafana if it is part of the design. Ask the operations team to sign off each rebuilt view before the old one is retired.

Cutover before coverage matches

Switching off NPM once the host count looks right can hide gaps in services, thresholds and notifications. Set a written exit condition covering host count, service count per device class, alert test results and a defined period of parallel running, and compare Checkmk against NPM for that same period. Keep NPM read-only for historical reference until the agreed exit condition is met and reports have been exported.

What your team needs to provide during the move

Your network team has to supply the access before any migration work starts. That means a read-only Orion service account with rights to query nodes, interfaces, custom properties and alert definitions through the Orion SDK and SWQL, plus SNMP credentials (community strings or SNMPv3 users, with auth and privacy settings) for every device Checkmk will poll. Ask the Orion administrator to confirm which polling engines and additional pollers hold those credentials, because some SNMPv3 users may exist only on a remote poller. On the Checkmk side, someone needs root or sudo on the monitoring host, the ability to open the site's web and agent ports, and a named owner for the Checkmk site itself. Confirm who will hold the automation user secret used for API calls, and who may create hosts in bulk. Device ownership is the item teams most often leave unassigned: for each device class, name the team that approves SNMP changes and the team that answers when a discovered service turns out to be unexpected.

Change windows and sign-off roles should be agreed before the first host is created. Plan one window for bulk host creation and SNMP discovery in Checkmk, a separate window for cutting over notifications, and a rollback point that leaves NPM alerting untouched until coverage is signed off. Assign four roles in writing: a technical owner who runs discovery and reviews the service list, a network owner who confirms that each interface and bandwidth check reflects a real operational need, a notification owner who approves which on-call groups receive which alerts, and a business approver who accepts the parallel-run result. Each role should also state what evidence it needs, such as a count of nodes and interfaces matched between Orion and Checkmk, and a list of differences with a disposition for each.

Some decisions only the business can make, and they should be settled before the export starts. The most important is which NPM reports, performance histories and alert records must be kept, for how long, and in what form. Checkmk will not import NPM's historical data, so an auditor or capacity planner who needs a trend from before the cutover will need an exported file or a retained NPM instance. Ask the business to decide whether NetPath-style path analysis or PerfStack views are required, since those are not direct equivalents in Checkmk and may need a separate plan. Also decide which Checkmk edition is funded. The editions page lists Community as free for small infrastructures, while Pro and Ultimate add distributed monitoring and other features, and the Pro and Ultimate prices are published there in euros per month. Confirm with the vendor and your procurement team which features your device count and sites actually require before choosing.

Migrate from SolarWinds Network Performance Monitor to Checkmk