Migrate from SolarWinds NPM to LibreNMS

How a team migrates from SolarWinds NPM to LibreNMS without losing coverage

The migration is four steps: export the device inventory from Orion, let LibreNMS discover devices over SNMP, rebuild alert rules and transports, and run both systems in parallel until coverage matches. A team that starts from a renewal quote or a self-hosting requirement should treat the inventory export as the first deliverable, because every later step depends on a complete, correct list of nodes, interfaces and custom properties. The exact SWQL queries and field mappings depend on how the Orion instance was customized, so the team should confirm them against its own database schema before writing any export script.

Network engineers usually do most of the work, with a platform owner who sets the polling schedule, retention, access model and backup approach for the new server. The effort is moderate and concentrated in two places: checking that SNMP community strings or SNMPv3 credentials, device access lists and interface naming are ready for discovery, and translating NPM alert thresholds into LibreNMS alerting rules and transports such as mail and Slack. The risk is mostly silent gaps, such as a device class that discovery does not classify as expected or an alert that never fires because its transport was not carried over. A parallel run, with both tools notifying a test group, is the practical way to find those gaps.

Plan for historical data to be only partly portable. Current inventory and configuration can be rebuilt, but NPM's long-term performance history is stored in its own database and rarely maps cleanly to LibreNMS round-robin storage, so teams should decide which reports must be kept as exported files and archived before the NPM subscription ends. Ask the platform owner to confirm retention requirements with auditors and capacity owners early, since those answers determine how much history is archived and how much is simply left behind.

Which NPM capabilities map to LibreNMS and which need rework

This table maps the main Orion NPM capabilities that a network team relies on to the LibreNMS features documented by the project, and marks each row as clean, needs rework or gap. Read the status as a starting point for a proof of concept, not a sign-off, because NPM-specific views and reports often need to be rebuilt in a different form. Items marked for confirmation are areas where the team should test its own devices and workflows before committing.

NPM capability	LibreNMS equivalent	Status	What to confirm or rebuild
Node and interface inventory	Auto discovery and device inventory by SNMP	Clean	Confirm coverage for your vendors and OS versions on a lab device set
SNMP polling of interfaces and devices	Core SNMP polling with interface and device metrics	Clean	Recreate polling intervals and any custom OIDs as LibreNMS settings
Auto discovery of new devices	Auto discovery documented as a core feature	Clean	Review discovery rules and filters so unwanted devices are not added
Alerting with mail and Slack transports	Alert rules with mail and Slack transports	Needs rework	Rebuild each NPM alert as a LibreNMS rule and retest every transport
Custom properties and tagging	Device attributes and groups, scope depends on setup	Needs rework	Map NPM custom properties to LibreNMS fields and groups before import
Distributed polling	Distributed polling documented as a feature	Needs rework	Plan poller placement and test links from each remote segment
Device configuration backup	Oxidized and RANCID integration	Needs rework	Set up Oxidized or RANCID and verify backup jobs for each device type
Spanning tree, OSPF, BGP, VLAN, ARP and FDB data	Collected from devices per the LibreNMS features list	Clean	Check that each vendor and protocol your team uses appears in the collected data
API for automation	API v1, documented as beta	Needs rework	Treat API calls as beta and rewrite any Orion SWQL or SDK scripts
NetPath path analysis	No documented equivalent in the features list	Gap	Confirm against the current LibreNMS feature set and your path troubleshooting needs
PerfStack performance views	No documented equivalent in the features list	Gap	Confirm whether LibreNMS dashboards or graphs meet the reporting you rely on

What to export from Orion with SWQL and what to rebuild in LibreNMS

The documented path is to query Orion with SWQL for the facts you need, then let LibreNMS discover devices over SNMP and rebuild the rest by hand. Each card below covers one item in that path, the decision it forces, and what to confirm in your own Orion version before you start.

Device inventory

Use SWQL against the Orion node and interface entities to list hostnames, IP addresses, vendors, device types and polling status. Treat this export as a checklist for LibreNMS auto discovery, not as data to import row by row. Compare the list with what LibreNMS finds on each subnet, and record any node that SNMP does not reach, such as devices using ICMP only or SNMP v1 community strings that need updating. Confirm the exact entity names and export format in your Orion version with SolarWinds documentation.

Custom properties and tags

Orion custom properties often carry the business owner, site, cost center or service name that your team filters on. Export them with SWQL so you know which fields exist, then decide which ones map to LibreNMS device groups, location fields or device attributes. Properties that only Orion used for its own dashboards can be dropped. Keep a written mapping table so reviewers can see where each property went.

Alert definitions

Orion alert definitions are not copied into LibreNMS. Export the alert names, trigger conditions, severities and target scopes from Orion, then rebuild each one as a LibreNMS alert rule that uses LibreNMS rule syntax and device groups. Start with the alerts that page someone or drive change tickets, because those carry the most operational risk if a condition is written differently. Mark each old alert as rebuilt, retired or deferred so nothing disappears silently during cutover.

Notification transports

Orion sends notifications through its own actions, such as email, SNMP traps, scripts or third-party webhooks. In LibreNMS, configure each channel you still need as a transport, such as mail or Slack, and attach it to rebuilt rules. Test each transport with a sample alert before cutover, and confirm that the mail relay, webhook URLs and credentials are current. Remove or retire any Orion action that writes to a system you are not moving.

Historical performance data

Orion stores polled history in its own database, and that history does not move into LibreNMS. Decide which reports your auditors, capacity planners or billing processes still need, then export them from Orion as reports or CSV before the old system is switched off. Keep the exported reports in a location with the same access controls as the source. Ask SolarWinds to confirm which retention and export options apply to your version and license.

The migration sequence from inventory to decommissioning NPM

This sequence moves NPM's device inventory and alert logic into LibreNMS in stages, so each site is proven before NPM is switched off. The result is a LibreNMS instance that covers the same devices, with signed-off evidence at every gate.

Export the device inventory from Orion
The network team runs SWQL queries against Orion to pull nodes, interfaces, IP addresses, SNMP settings where accessible, locations and custom properties into CSV files. A platform engineer checks the export against Orion's node count and tags each record with its site and device role. Output: an approved device list that names every device LibreNMS must discover, plus a list of nodes whose SNMP community or v3 credentials must be obtained from the owning team. Confirm the exact SWQL entities and fields with your Orion version, since schema names differ between releases.
Build the LibreNMS host
The platform team deploys LibreNMS on a supported Linux distribution such as Ubuntu 24.04 or Debian 12, or uses the librenms/librenms Docker image if the organization runs containers. The stack needs PHP 8.4, MariaDB, NGINX (recommended) or Apache, and Python 3, as listed in the install guide. The build is checked against the install guide's current requirements before go-live. Output: a running instance with a verified web login, a working poller cron job and a documented hardening baseline covering OS patching, database access and TLS on the web interface.
Run a pilot discovery on one site
Choose one site with a mix of switches, routers and firewalls and add its subnets to LibreNMS for auto-discovery using SNMP credentials that match the device list. The network team compares discovered devices, interfaces and routing or VLAN data against the Orion export and records gaps, such as devices with unsupported OS types or SNMP views that hide tables. Output: a pilot sign-off document listing matched devices, unresolved exceptions and the fixes applied to SNMP configuration or device profiles.
Rebuild alert rules and transports
Map each NPM alert definition to a LibreNMS alert rule, prioritizing alerts for interface down, device unreachable and high utilization. Configure transports such as mail and Slack, then test each route with a controlled event. Owners of on-call routing confirm that notifications reach the same people as before. Output: a rule mapping table that links every retained NPM alert to its LibreNMS rule, with a test record for each transport and a note on any NPM alert that was intentionally retired.
Add distributed pollers for remote segments
For sites that NPM reached through remote polling engines, deploy LibreNMS distributed pollers that write to the central database. The team confirms that each remote segment can reach its devices over SNMP and that poller traffic is allowed through the firewall path the organization approves. Output: a poller inventory showing which devices each poller covers, the last successful poll per segment and a documented fallback if a link fails.
Run both systems in parallel
NPM and LibreNMS monitor the same devices for an agreed overlap period set by the migration owner. Operators compare device status, interface counters and alert events each week and log any mismatch in polling intervals, thresholds or alert timing. Output: a coverage comparison showing matched devices, alert parity and open discrepancies, which the owner signs before cutover. Note that NPM data continues to accumulate during this period, so historical reports should be exported before NPM is changed.
Cut over and archive NPM reports
The team moves dashboards, reports and on-call procedures to LibreNMS, then disables NPM polling and alerting. Before shutdown, the team exports the reports that audits or capacity reviews depend on and stores them in an approved archive. The archive should be checked for readability by the people who will need it later. Output: a cutover record, a signed archive manifest listing each exported report and its location, and a confirmation that no active alert still routes through NPM.
Decommission NPM and its hosts
After the archive is verified, the team removes NPM services, the Orion database and any Windows or SQL Server hosts that existed only for NPM, following the license and data retention terms the organization has agreed with SolarWinds. The security team confirms that credentials stored in NPM are revoked or rotated. Output: a decommissioning checklist with dated sign-off from the infrastructure, security and network owners, and a record of which licenses and maintenance agreements were ended.

How LibreNMS auto discovery and distributed polling replace NPM node imports

LibreNMS builds its device list by SNMP discovery, so the Orion export works as a validation and prioritization list rather than a source of hand-entered hosts. Each device that answers SNMP is classified by LibreNMS according to its operating system and hardware, and interfaces, VLANs, ARP and FDB tables, and routing data such as OSPF and BGP are collected from it. Compare what discovery finds against the node list exported from Orion. Devices that appear in Orion but never answer SNMP usually point to missing credentials, a filtered management path, or a device that was retired and never removed from NPM. Devices that LibreNMS finds but Orion never monitored are worth reviewing too, because they often reveal unmanaged gear. Mark the nodes that carry critical services first so that they are validated and alerting before the lower-priority tail is imported.

Distributed polling is how LibreNMS covers remote sites without opening every device to the central server. A poller in each segment runs discovery and polling for the devices it can reach and writes results to the central database. Before adding a poller, confirm three things for each segment: the SNMP version and community or SNMPv3 credentials that the devices accept, the route from the poller to each device on UDP 161, and the time synchronization and database connectivity that the poller needs. Test these per segment, not only from the main server, because a credential that works from the core network may fail on a branch router with a different access list. Then compare the polled device count per site against the Orion node count for the same site. Any gap is either a reachability problem or a scope decision that should be recorded, not a silent omission.

What drives the cost and duration of an NPM to LibreNMS move

This table lists the factors that move effort and cost in an NPM to LibreNMS migration, why each one matters, and how to keep it down. Read it before requesting a scoped quote, because most of the spend follows from inventory size, alert rebuild work and remote-site design rather than from the software itself.

Driver	Why it moves cost or effort	How to keep it down
Device count and vendor mix	Each device class needs SNMP discovery checks, interface mapping and validation. Mixed vendors, such as Cisco, Juniper, HP and Linux hosts, add more OS-specific testing than a single-vendor estate.	Group devices by OS and model, migrate the largest uniform group first, and retire unsupported hardware before the move.
Custom properties and alert definitions	Orion custom properties and alert logic must be mapped by hand to LibreNMS device attributes, alert rules and transports. Complex conditions take the most engineer time.	Export definitions with SWQL, remove unused alerts, and rebuild only the rules that still drive an on-call action.
Remote sites needing distributed pollers	Each segment behind a firewall or WAN link needs a poller, network path rules and monitoring of the poller itself. Site count drives both build and testing time.	Standardize a poller build, document required ports and SNMP reachability per site, and pilot one remote site before the rest.
SNMP version and credential hygiene	SNMPv1 or v2c communities on older devices must be replaced with SNMPv3 credentials where supported, which requires device changes and change windows. Credential storage and rotation also need a design decision.	Inventory SNMP versions per device, plan SNMPv3 where the hardware supports it, and confirm the secrets handling model with your security team before rollout.
Scope of historical reports to keep	Migrating raw NPM performance history is usually impractical. Each report kept as a dashboard, export or archive adds design and validation work.	Limit history to the reports auditors or capacity planners actually use, and archive the rest from the NPM server during the overlap period.
Staff availability and parallel running	Running NPM and LibreNMS side by side needs engineers who can compare results, sign off coverage and handle change windows. Shared staffing slows every other driver.	Assign a named owner for inventory, alerts and sites, agree the coverage checklist up front, and schedule cutover around existing change calendars.
Hosting: servers and database	Hosting is a recurring cost for the LibreNMS server, the MariaDB database, pollers and backups. Polling volume and retention set the size. The LibreNMS install guide lists the supported OS and PHP, MariaDB and web server requirements, so confirm these with your platform team.	Size hardware from your actual device and interface count, use a pre-built image where your standards allow, and ask the implementer to quote hosting separately from one-time work.
Engineer time, support and consulting	Most one-time effort is engineer time for export, build, rule rebuild, testing and cutover. Optional support or consulting adds a recurring or project-based fee that depends on the scope you agree.	Ask for a written scope with deliverables per driver above, and compare quotes on the same device count, site count and report list rather than on headline rates.

What usually goes wrong when moving NPM alerts and reports to LibreNMS

Most failed NPM-to-LibreNMS cutovers do not fail on device discovery. They fail on alert logic, credentials, remote polling, lost reports and duplicate notifications during the parallel run. Each card below names one risk, the step that prevents it and the check to run before cutover.

Alert logic does not translate one-to-one

NPM alert conditions, suppression windows and trigger scopes do not map directly onto LibreNMS alert rules, which are built from device groups and rule expressions. Export every NPM alert definition first, then rewrite each one as a LibreNMS rule and record which NPM logic it replaces. Check each rebuilt rule against a known past event, such as an interface flap or a high-utilization period, and confirm it fires on the same devices. Treat any alert with no clean equivalent as a documented decision, not a silent gap.

SNMP community and v3 credential gaps

Devices that answered NPM may not answer LibreNMS if the community strings or SNMPv3 users differ, or if the v3 authentication and privacy settings were never recorded. Inventory every credential set by device group before import, including the SNMP version and the source addresses permitted to poll. Store the credentials in the LibreNMS configuration with restricted file permissions rather than in spreadsheets. Before cutover, confirm that each device class returns its interface and system tables from the LibreNMS server, not only from the NPM host.

Remote segments without pollers

A poller placed at the central server cannot reach firewalled branch, plant or lab segments, and devices there will show as down even when they are healthy. Map each remote segment, decide whether it needs a distributed poller, and deploy it before importing that segment's devices. Confirm the poller can reach its devices on UDP 161 and that its results reach the central database. Run a test poll from each remote poller and verify the device counts match the NPM inventory for that site.

Historical reports not carried over

LibreNMS does not import NPM's performance history, so trend reports, capacity baselines and billing-period totals will start from zero on cutover. Decide which NPM reports auditors, finance or capacity planning actually use, and export their current output to PDF or CSV before NPM is switched off. Keep NPM read-only for the retention period your change or audit policy requires. Confirm with the business owner which reports must be reproduced in LibreNMS and which will be retired.

Duplicate alerts during parallel run

Running NPM and LibreNMS side by side sends two sets of notifications for the same fault, which trains on-call staff to ignore the channel. Route LibreNMS transports, such as mail or Slack, to a test channel while NPM stays on production channels. Compare both systems' alert logs for one to two weeks and count the events each one raised that the other did not. Switch the production route only after the unmatched events are explained and accepted.

Undocumented custom properties

NPM custom properties often carry owner, site, criticality or change-window data that teams use in filters and alerts, and few of them are written down. Export every custom property with its values and the views, reports or alerts that depend on it using SWQL before migration. Map each one to a LibreNMS device attribute, group or label, and confirm that the mapping is reflected in the device list. Ask the owners of each property to sign off on its replacement before the NPM copy is retired.

How the migration differs by estate size and starting point

A single-site estate is the simplest starting point because one LibreNMS server, backed by MariaDB and a web server, can often poll every device in the building without remote pollers. Most of the effort goes into discovery and cleanup rather than infrastructure. Because there is only one poll path, you can run both systems side by side from the same network segment and compare results directly.

Sequencing: Export the Orion node and interface list first, then let LibreNMS auto-discover by SNMP in a pilot group before wider rollout.
Poller count: Usually one LibreNMS instance, with the Docker image or a package install on a supported Linux release, as the install guide describes.
Rebuild effort: Concentrate on alert rules and transports such as mail and Slack, since device onboarding is largely automatic.
Overlap: Keep NPM polling until discovered device counts and interface data match for a full reporting cycle.
Cleanup: Retire stale nodes and duplicate custom properties before import so they do not carry into the new inventory.

Before cutover, confirm with your own team that the single server's sizing and backup plan match the device count and retention you need.

Questions teams ask before moving from SolarWinds NPM to LibreNMS

What does a migration from SolarWinds NPM to LibreNMS cost?

The cost is mostly labor and infrastructure, not a license fee, because LibreNMS is GPLv3 software with no per-node charge. The components are the Linux server or VM running PHP, MariaDB and NGINX or Apache, any distributed poller hosts, the staff time to rebuild devices, alerts and transports, and optional support or implementation work. Some costs are one-time (build, rule rebuild, parallel run) and some recurring (hosting, patching, on-call for the monitoring stack). Ask any implementation partner for a written scope listing device count, alert rules, integrations and poller sites, since those drive the quote. Confirm your own NPM renewal terms and retained SolarWinds support costs before comparing totals.

How long does it take to move NPM to LibreNMS?

Timeline depends on the number of devices, how many alert rules and transports you run, how many remote sites need distributed pollers, and whether you want a parallel run before cutover. Start by counting these in your own environment, since no duration applies to every network. Discovery itself is quick once SNMP access is in place, so most of the elapsed time usually goes to validating device data, rebuilding alerting and getting sign-off from the operations team. A parallel period lets you compare results before NPM is switched off. Ask for a timeline tied to a written scope, not a generic estimate.

What does the internal team need to supply for the migration?

The team needs people who know the network and the monitoring design. Key inputs include an inventory of nodes and interfaces exported from Orion, SNMP community or SNMPv3 credentials, a list of current alert conditions and who receives them, and the notification channels such as mail or Slack. Network engineers confirm which devices and interfaces matter, and a Linux administrator runs the server, database and web stack. Someone must own the change process and sign-off. Plan for these roles before the project begins so that decisions are not delayed.

Can our team migrate from NPM to LibreNMS without outside help?

Yes, a team with Linux, SNMP and network skills can do it in-house, and LibreNMS is documented for installation on supported Linux distributions. The harder parts are rebuilding alerting and thresholds to match what NPM did, designing distributed polling across segments, and validating results against the old system. Outside help is usually chosen for fixed-scope work such as hardening, integration or a documented handover, or for ongoing support through a retainer. DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with agreed deliverables in writing.

Can we carry NPM historical performance data into LibreNMS?

Usually not as a direct import. LibreNMS builds its own polling history from the point it starts collecting, so older NPM performance data generally stays in NPM or in an archive. Before you decide, export the reports and data you must keep, such as interface utilization, uptime and alert history, using the Orion SDK, SWQL or PowerShell where your licensing allows. Confirm with SolarWinds which export formats your version supports and how long NPM retains data. Many teams keep NPM read-only for a set period for audit or capacity reviews.

Does LibreNMS cover NetPath and PerfStack?

No, LibreNMS does not provide NetPath-style path analysis or PerfStack-style cross-metric dashboards as named features. Its documented strengths are auto discovery, SNMP device coverage, alerting with transports, an API v1 documented as beta, traffic billing by quota or 95th percentile, distributed polling, and Oxidized or RANCID backup integration. It also collects STP, OSPF, OSPFv3, BGP, VLAN, ARP and FDB data. If path visualization or ad hoc metric correlation is critical, plan for Grafana dashboards, custom views or another tool, and confirm the gap with your network team during scoping.

What happens to our config backups and device data during the move?

LibreNMS integrates with Oxidized and RANCID for device backups, so you can keep config backup workflows while changing the monitoring platform. Plan the change in stages: confirm which backup tool you use, point it at the same device list, and verify that backups still run after cutover. Also confirm which data your compliance program needs, since device inventories and change records may be audited. Retain NPM exports for the required period, and document where each record now lives.

How DeployOpen scopes and runs a LibreNMS migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including LibreNMS. For a move away from SolarWinds Network Performance Monitor, we start from a written inventory of what Orion actually monitors and build the LibreNMS side against that list.

How we scope

Written scope lists the Orion nodes, interfaces, custom properties and alert definitions that move to LibreNMS.
Scope names the device families, SNMP versions and credentials each site requires before any discovery begins.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Install LibreNMS on the supported Linux distribution your team standardizes on, with MariaDB, PHP and NGINX configured.
Configure auto discovery and distributed pollers for each remote segment, then validate device counts against the exported inventory.
Rebuild alert rules and transports such as mail and Slack, and test each one against a known condition before cutover.

How we hand over

Deliver a documented device inventory reconciliation showing matched, missing and unmanaged devices from the NPM export.
Provide runbooks for poller placement, alert rules, API use and Oxidized or RANCID backup integration where in scope.
Document the parallel-run period, the retirement criteria for NPM reports and the archived historical data location.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Upgrade planning covers LibreNMS release notes and tests changes in a staging copy before production.
Confirm with DeployOpen during scoping which support hours, response paths and escalation contacts your retainer includes.

Migrate from SolarWinds Network Performance Monitor to LibreNMS