PRTG vs LibreNMS: when LibreNMS is enough on its own
A network team facing a PRTG renewal, a licensing change or a data residency rule should ask one question first: is the estate mostly devices that speak SNMP? If it is, LibreNMS is often enough on its own, because it is built around auto-discovery of switches, routers, firewalls and bandwidth. If application checks, server internals or Windows performance counters must stay in the same console as the network view, PRTG or a second tool will still be needed. The decision turns on five things: the device mix, whether non-SNMP checks are required, whether you need traffic billing or routing data, who on the team has Linux and database skills, and who will own upgrades and backups of the platform.
Start with the device inventory. LibreNMS supports a wide range of network hardware and operating systems, including Cisco, Juniper, Brocade, Foundry, HP and Linux or FreeBSD hosts, and it collects STP, OSPF, OSPFv3 and BGP data along with VLAN, ARP and FDB tables. For a routing-heavy core, that depth is the main reason teams choose it. Traffic billing by quota or 95th percentile is also built in, which matters if bandwidth is charged back to departments. Confirm, device by device, that the SNMP MIBs and counters you rely on in PRTG are exposed by your hardware, because a sensor that works in PRTG may not have a direct equivalent. Check the LibreNMS device support list for each model before you commit.
Be explicit about what LibreNMS does not replace. Database queries, web transaction checks, certificate expiry on application endpoints and most agent-based server metrics sit outside its core scope, so those checks need a second tool, custom scripts or an agent-based platform. The platform itself is a PHP, MySQL or MariaDB and Python application on Linux with a supported web server, so the team must be comfortable with package upgrades, database maintenance and polling capacity. Plan that ownership before the renewal date. A useful trial is to run LibreNMS beside PRTG for one site for a full reporting cycle and compare the alerts each raises, in writing, before you retire anything.
Which option fits which network scenario
This table maps common network monitoring scenarios to the tool that fits best, with the condition that favors LibreNMS and the condition that favors keeping PRTG or adding another tool. Read each row against your own estate, since a mixed environment often needs LibreNMS for the network and a second tool for applications and Windows servers.
| Scenario | Better fit | Why |
|---|---|---|
| Campus or branch estate of switches and routers polled over SNMP | LibreNMS | Auto-discovery across Cisco, Juniper, HP and other SNMP devices reduces manual sensor setup. Choose PRTG instead if your team relies on existing sensor-based dashboards for these devices and retraining costs outweigh the gain. |
| Bandwidth billing or 95th percentile reporting for a carrier or hosting provider | LibreNMS | LibreNMS includes traffic billing by quota or 95th percentile. Confirm that its billing output matches your contract method and invoicing workflow before you retire PRTG reports. |
| Routing protocol visibility for OSPF and BGP | LibreNMS | LibreNMS collects OSPF, OSPFv3 and BGP data along with STP, VLAN, ARP and FDB tables. Keep PRTG or add a dedicated routing tool if you need path analysis or protocol troubleshooting beyond what the collected data shows. |
| Windows-heavy server estate with application checks | Keep PRTG or add another tool | LibreNMS focuses on network devices and SNMP-capable systems. Application-level checks, WMI-style server metrics and service monitoring usually need Zabbix, Checkmk or a separate agent-based tool. |
| One console for network, servers and applications | Keep PRTG or add another tool | LibreNMS alone will not give one console across network and application monitoring. Consider Zabbix or Checkmk if a single platform is the requirement, and confirm coverage against your own sensor list. |
| Regulated site that needs all monitoring data on its own servers | LibreNMS | LibreNMS is self-hosted on your own Linux servers with MariaDB, so polling data, device inventories and alert history stay in your environment. Confirm that any notification transports you enable also meet your data handling rules. |
What LibreNMS does well for network teams
LibreNMS is built around SNMP and device data rather than sensors per check. The capabilities below are the ones that decide whether it can replace the switch, router and bandwidth views a team uses in PRTG, and each one depends on the device models and protocols in your own estate.
SNMP auto-discovery across vendors
LibreNMS is an auto-discovering, SNMP-based system that supports a wide range of hardware, including Cisco, Juniper, Brocade, Foundry, HP and Linux or FreeBSD hosts. This matters most when a team manages many switches and routers from several vendors and wants devices added without building each one by hand. Check that every model in your estate exposes usable SNMP, and confirm the supported device list for each platform before counting on discovery to find everything.
Traffic billing by quota or 95th percentile
LibreNMS can bill traffic either by a fixed quota or by the 95th percentile method, which suits teams that recharge bandwidth to departments or check provider invoices. This capability matters when bandwidth cost allocation is a formal process rather than a chart for capacity planning. Confirm which billing method your transit or peering contracts use, and verify that the interface counters you need are available on your devices before relying on the figures.
Routing and switching table collection
LibreNMS collects STP, OSPF, OSPFv3 and BGP data, along with VLAN, ARP and FDB tables from devices. This gives network engineers a view of adjacency, routing state and MAC or ARP mappings during troubleshooting, which is useful when a fault spans layers rather than a single interface. Check which of these tables your device firmware exposes over SNMP, since coverage varies by platform and software version.
Alerting through mail and Slack
LibreNMS sends alerts through transports such as mail and Slack, so network events can reach the on-call channel your team already uses. This matters when PRTG notifications are wired to email or chat and those rules must be rebuilt during a move. Plan the alert rules as a list of conditions and recipients, and test each transport end to end, because the rule logic has to be recreated rather than copied across.
Distributed polling for remote sites
LibreNMS supports distributed polling, which lets collection run from more than one poller across remote sites or network segments. This is relevant when devices sit behind firewalls or on links where a single central poller would be slow or unreachable. Confirm the poller placement, the network paths to each device, and how results are stored and reviewed centrally before committing to a multi-site layout.
Device backup with Oxidized and RANCID
LibreNMS integrates with Oxidized and RANCID for device configuration backup, so changes to switch and router configurations can be tracked over time. This matters for teams that need configuration history for change control or audit evidence, and for teams that want backups alongside monitoring data. Both tools run as separate components, so plan their installation, credentials and storage, and confirm which device types each one supports in your environment.
PRTG and LibreNMS side by side on network features
This table compares how PRTG and LibreNMS handle the network features that usually drive a PRTG renewal: switches, routers and bandwidth. LibreNMS entries come from its documented feature set, while PRTG cells tell you what to confirm in Paessler's documentation or a trial. Treat the open gaps as checks to run before you decide, especially for application monitoring.
| Capability | PRTG (commercial) | LibreNMS (open source) |
|---|---|---|
| Discovery method | Confirm sensor auto-discovery options in PRTG's documentation. | Auto-discovers devices over SNMP. |
| Supported device types | Confirm SNMP and vendor coverage for your specific models during a trial. | Covers Cisco, Juniper, Brocade, Foundry, HP, Linux and FreeBSD, among others. |
| Traffic and bandwidth monitoring | Confirm interface traffic sensors and reporting in PRTG's documentation. | Traffic billing by quota or 95th percentile, suited to bandwidth accounting. |
| Routing protocol data | Confirm which routing protocols PRTG reads natively before relying on it. | Collects STP, OSPF, OSPFv3 and BGP data, plus VLAN, ARP and FDB tables. |
| Application and server checks | Confirm application and server sensor coverage for your estate. | Focused on network devices; confirm application checks in LibreNMS docs before relying on them. |
| Alerting channels | Confirm notification channels available in your PRTG edition. | Alerts through transports such as email and Slack, plus other transports. |
| API | Confirm HTTP API coverage for export and automation in PRTG's documentation. | API v1 for automation, documented as beta. |
| Backup integration and distributed polling | Confirm config backup options and remote probe support with Paessler. | Integrates with Oxidized and RANCID for backups; supports distributed polling. |
| Documentation and license | Commercial, sensor-based subscription. Confirm current terms with Paessler before renewal. | GPLv3 with exceptions for included third-party packages; docs at docs.librenms.org. |
Where the monitoring data lives and who controls it
Monitoring data is sensitive: it maps your network, lists your devices and can expose credentials. This section compares where PRTG and LibreNMS keep that data, who holds the keys and what evidence you need to produce for your own assessors.
Data location with LibreNMS
LibreNMS runs on a Linux server you control or in a container built from the supplied Docker image. Polled metrics, device inventory, topology and SNMP community or credential settings stay in your database and on your disks. Confirm where the MariaDB data directory, RRD files and backups sit, and whether any integration sends data to an external service you enable.
PRTG hosting options compared
PRTG is offered on premises, where the core server runs in your environment, and as PRTG Hosted Monitor, where Paessler operates the service. Your choice changes who administers the server and where the data is stored. Ask Paessler to confirm the data location, backup responsibility and support access for the hosted option against your residency requirement.
Access control and SSO
Decide who may view device credentials, change polling settings and approve alert changes before you migrate. Confirm which role model LibreNMS offers, whether its web login can federate to your identity provider, and how API tokens are issued and revoked. Compare these points with your current PRTG user groups and their permissions.
Audit logging
Auditors will ask who changed a device, a threshold or an alert route, and when. Confirm what LibreNMS records in its own logs and database, where those logs can be forwarded, and how long you keep them. Map the PRTG audit trail you rely on today and make sure the replacement captures the same events before you retire PRTG.
Licensing and third-party code
LibreNMS is covered by the GPLv3, with exceptions for included third-party packages. Read the LICENSE.txt file and have counsel confirm how those exceptions apply to your internal use, any modifications you make and any distribution of customized builds. Keep a record of the package versions you deploy so license review is straightforward.
Compliance evidence comes from auditors
Running LibreNMS in your environment gives you control over the systems and records an assessment will examine, but the software does not produce compliance evidence or certification. Independent auditors and certification bodies issue the findings. Use this card to plan which access reviews, change records, backup restores and log exports you will present, and confirm the scope with your assessor before work starts.
What each option costs to run, by component
The recurring cost of staying on PRTG is the subscription itself, which is sold by sensor tier and grows as the sensor count grows. Each device with several interfaces, disks or services adds sensors, so the fee rises with the size of the estate rather than with the work the monitoring does. For a switch and router estate, the sensor count is driven mostly by interfaces and bandwidth channels, which is why a network team should export its current sensor inventory before comparing options. Confirm the tier, renewal date and any add-on costs directly with Paessler, and treat the invoice as the only source for those figures. LibreNMS has no license fee under GPLv3, so its costs sit in infrastructure and people. One-time costs include the server or virtual machine, the initial install on a supported Linux release with PHP, MariaDB, NGINX or Apache and Python 3, and the initial discovery and alert rule build. Recurring costs include the server itself, storage for polled data (which grows with device count, polling interval and retention), operating system and PHP maintenance, database backups, and staff time for upgrades. The most variable item is staff time: discovery tuning, device-specific polling problems and alert rule maintenance usually take more hours in the first months than in later years. Ask who on your team owns PHP and MariaDB patching, and whether that work already sits in an existing operations rota. A written quote should separate each of these components, so you can compare them with the PRTG renewal line by line. Ask for the scope of setup (server build, LibreNMS install, device discovery, polling tuning and alert transports), testing (a parallel run period and acceptance criteria for bandwidth and routing data), backups and restore testing, and the handover, including documentation and training for the staff who will run it. Also ask what happens after go-live: whether upgrades, support and retainer hours are included or priced separately, and how many hours are assumed for each. Confirm with the quote whether any items are excluded, such as storage expansion or a second site for distributed polling.
What moving from PRTG to LibreNMS involves
The sequence moves network device coverage from PRTG sensors to LibreNMS discovery, one segment at a time, so each device is only retired from PRTG once LibreNMS alerts and reports match what the team relied on. Application and custom checks usually need a separate tool and are tracked on their own list.
Inventory devices and the sensors that matter
The network team lists every PRTG device and marks the sensors that drive real decisions, such as interface traffic, CPU and memory on routers and switches, uptime checks and bandwidth quotas. Anything that tests an application, a URL, a database query or a custom script goes on a separate list, because LibreNMS does not cover it and a second tool will be needed. The step is done when each device has an owner, a segment and a short list of the alerts people actually act on.
Export or document what PRTG holds
Before any change, the team pulls the device and sensor lists and the historic data it needs for capacity reviews or billing disputes, using the PRTG HTTP API where possible. Maps, notification templates and custom sensors are documented by hand, since they usually do not carry over automatically. The sibling page on exporting data from PRTG covers what the API returns and how to time the export against the subscription end. The step is done when the exports are stored somewhere the team can still read them after PRTG is switched off.
Install LibreNMS on a supported platform
The platform team installs LibreNMS on a supported release such as Ubuntu 24.04 or Debian 12, or a RHEL derivative from the install guide, with PHP, MariaDB, NGINX and Python 3 as the documented stack. Confirm the PHP version and the other requirements against the install guide for the release you choose, because minimums change between releases. Teams that prefer containers can use the official Docker image, and an Ubuntu-based VM image is available for evaluation. The step is done when the web interface loads over HTTPS, the database is backed up and the service restarts cleanly after a reboot.
Run discovery against a pilot segment
The team adds SNMP credentials for one non-critical segment, such as a branch or a lab VLAN, and runs auto-discovery to see which devices LibreNMS identifies and which it places in the wrong device type. Routing and switching data such as STP, OSPF, BGP, VLAN, ARP and FDB tables appear here if the devices expose them. Each device is compared against its PRTG entry, and gaps in SNMP access are fixed on the device side. The step is done when the pilot segment shows every device the team expects, with interfaces and routing data populated.
Rebuild thresholds, alerts and bandwidth reports
The team recreates the alert rules that matter in LibreNMS, sets interface and quota thresholds, configures transports such as mail or Slack, and builds traffic billing by quota or 95th percentile where finance or capacity planning needs it. Device backups through Oxidized or RANCID can be wired in at this point if the team uses them. The step is done when each rebuilt alert has a documented owner, a test notification has been received and the bandwidth reports match a known sample from PRTG.
Run both tools in parallel until alerts match
PRTG and LibreNMS monitor the same pilot devices for a period the team sets, and the on-call team logs every alert from each tool. Mismatches are investigated: a missing alert is a rule gap, an extra alert is usually a threshold that needs tuning. Once a segment's alerts agree, PRTG sensors for those devices can be paused and then removed, and the remaining segments follow the same pattern. The step is done when the team signs off that LibreNMS handles every alert the business relies on for that segment.
Retire PRTG sensors and plan the second tool
Once a device is covered, its PRTG sensors are removed and the device is recorded as moved in the inventory. Application checks, URL monitors and custom scripts from the first step are assigned to a second tool, which may be a separate open-source monitoring product or an application observability stack. Confirm with the vendor and the subscription terms which PRTG licences or sensor counts are released at each stage. The step is done when the PRTG inventory shows no active devices that LibreNMS does not cover, and the second-tool list has an owner.
What LibreNMS does not cover and when that matters
LibreNMS is built around SNMP-based network monitoring, so it is strongest on switches, routers, firewalls and the interfaces and routing data they expose. Application-level checks, custom script sensors and Windows service checks are not its focus. If your PRTG estate relies on any of those, treat them as open questions to confirm against the current LibreNMS documentation at LibreNMS features rather than assuming a equivalent exists. Some of these checks may be possible through extensions or scripts, but that is custom work you will own and maintain after the migration.
The gap matters when a meaningful share of your PRTG sensors are not network sensors. An estate with many web services checking HTTP response and certificate expiry, database query checks, mail server probes or Windows service status will need a second tool or a different primary platform. Many teams keep LibreNMS for network devices and pair it with Zabbix, Checkmk or a lightweight probe tool for the rest, so alerting and dashboards are split across two systems. Decide early whether that split is acceptable for on-call and reporting, because it adds a second install, a second set of credentials and a second place to maintain notification rules.
Before you size the migration, export your PRTG sensor list through the PRTG API and classify every sensor as SNMP, flow or traffic, ping or port, application or script, or Windows. Then pilot each non-SNMP check in a test environment: confirm the check exists or can be built, measure whether it produces the same alert on a forced failure, and note who will maintain it. A check that cannot be reproduced with confidence is the one to resolve before you retire PRTG.
Questions buyers ask before moving from PRTG to LibreNMS
How much effort does a move from PRTG to LibreNMS take?
The effort depends mainly on how many devices you monitor, how many of them are switches and routers that LibreNMS discovers over SNMP, and how much of your PRTG setup is custom. Discovery of SNMP-capable network gear is largely automatic, so the bulk of the work is usually the platform build, the alert and notification rules, the dashboards and maps your operators rely on, and checking that polling covers every device class you care about. Ask any partner to split their estimate into those components so you can see where the time goes.
Can our team migrate from PRTG to LibreNMS without outside help?
A network team with Linux administration, MySQL or MariaDB, PHP and web server experience, and SNMP knowledge can run LibreNMS in-house. The install guide lists PHP 8.4, MariaDB, NGINX or Apache and Python 3 as the core requirements, and the Docker image gives an alternative deployment path. The skills most often missing are routing protocol familiarity for the OSPF, BGP and STP data you intend to use, and the time to rebuild alerting and billing reports. Many teams do part of the work internally and bring in outside help for the platform build or the cutover.
How long does a LibreNMS migration take?
No fixed duration can be given without your device count, the scope of the move and your change windows. Plan around the work itself: a production install with hardening and backups, discovery and tuning across the estate, rebuilding alerts and billing, and a parallel run before PRTG is switched off. Ask a provider to tie each phase to a written milestone and to state which assumptions, such as the number of devices and sites, the timeline depends on.
Does LibreNMS replace PRTG's application and server checks?
Not on its own. LibreNMS is strongest on network devices, using SNMP auto-discovery, interface and traffic data, and routing protocol data such as OSPF, OSPFv3 and BGP. If your PRTG instance runs application-level sensors for web services, databases, Windows performance counters or custom scripts, those checks need a separate tool or an add-on approach. Inventory every sensor type in PRTG before you decide, because that list shows whether LibreNMS alone is enough or whether you need a complementary monitoring system.
What does the LibreNMS license mean for commercial use?
LibreNMS is covered by the GPLv3, with exceptions for included third-party packages listed in its LICENSE.txt file. Internal use in a company does not require you to pay license fees, and the GPL governs how you distribute modified versions. Have your legal or compliance team read the license and the third-party package notices, and confirm how any custom code you write will be shared or kept internal before you build on it.
How does traffic billing work in LibreNMS?
LibreNMS supports traffic billing by quota or by 95th percentile, so you can calculate usage for circuits, links or customers against agreed commitments. Accuracy depends on polling every relevant interface consistently and on your billing definitions, such as the measurement window and how you treat committed and burst traffic. Before cutover, compare the billing numbers from both tools for the same period and confirm that your finance team accepts the method.
Should we run PRTG and LibreNMS in parallel during the change?
Yes, for a limited period, is the common approach. Running both lets you compare device status, interface counters, alert behavior and traffic figures before you retire PRTG. Set a clear exit criterion, such as alerts matching across an agreed set of devices and billing data reconciling, and keep PRTG history exported before its subscription ends. Avoid duplicate notifications by disabling the PRTG notification channels that LibreNMS replaces as each segment is validated.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists the device classes and approximate device count, the sites, the platform components to be installed, and whether hardening, backup and upgrade procedures are included. Request the deliverables for discovery, alert and notification rebuilds, dashboards, billing reports, documentation and knowledge transfer, plus the acceptance criteria for each. Also ask what is excluded, such as application checks or custom integrations, and how ongoing support or upgrades would be handled after go-live. DeployOpen works from a written scope like this and does not publish a price list, so a quote follows from the scope you agree.
How DeployOpen helps evaluate and migrate to LibreNMS
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a PRTG vs LibreNMS decision, we start by confirming which PRTG sensors actually carry network value and which need a different tool, then build and hand over only what the written scope covers.
How we scope
- Inventory which PRTG devices, sensors and bandwidth views a LibreNMS deployment must replace.
- Mark application and server checks that LibreNMS does not cover, and assign them to another tool or keep PRTG for them.
- Agree the written scope, deliverables and timeline with you before any work starts; engagements are fixed-scope.
How we build
- Install LibreNMS on your chosen supported Linux distribution with PHP, MariaDB, NGINX or Apache and Python 3.
- Configure SNMP credentials, auto-discovery ranges, polling, alert transports and traffic billing or 95th percentile reports.
- Test discovery results against your device inventory and document any gaps or manual device additions before cutover.
How we hand over
- Deliver configuration records, runbooks, alert rule documentation and a list of retained PRTG checks with their owners.
- Run LibreNMS and PRTG in parallel for the agreed period so your team can compare alerts and graphs side by side.
- Walk your network and operations staff through daily tasks, upgrades and API use before the written scope closes.
How we support
- Provide ongoing support, upgrades and continuous review of the LibreNMS deployment as a retainer.
- Keep release upgrades, backups and configuration documentation current as your device estate changes.
- Ask any support provider to confirm response terms, upgrade handling and access to your environment in writing.
