For companies looking to migrate from PRTG Network Monitor to Zabbix, one of the most critical aspects is making sure a smooth migration of monitored devices and configurations. While there is no official tool to directly migrate between the two platforms, creating a bridge using custom export/import scripts allows for an effective and large migation. This blog post outlines a practical approach to achieving that migration based on the export/import methodology we at Opensource ICT Solutions previously implemented for one of our clients.
Why migrate?
While PRTG offers an intuitive interface and is popular for its ease of use, Zabbix provides:
- Greater flexibility and scalability
- Full open-source licensing
- More powerful automation and templating
- A robust API for integrations
- Lower costs, especially since Paessler was sold to an investor
These features make Zabbix an attractive choice for teams looking to scale or standardize on open-source infrastructure.
Migration overview
The migration involves two key steps:
- Exporting PRTG device information
- Importing data into Zabbix
Because the two systems are conceptually and structurally different, we focused our scripts on migrating what is most transferable: device names, IP addresses, and interface types. SNMP versions or PRTG-specific sensor details were excluded or simplified where not applicable to Zabbix. PRTG, for example, will only export probes that have an OID that was not built-in in PRTG but added later, making our export incomplete. This does not mean we did a partial migration, it just means we have not included it in the automated approach.
Step 1: Exporting from PRTG
We developed a Python-based script that interacts with the PRTG API to extract monitored device data and export it to a CSV file. The script filters out irrelevant objects and organizes the output for easy Zabbix processing.
This creates a clean CSV, like this:
Device Name, IP Address, Interface Type
zabbix-server,10.0.0.10,agent
ServerA,192.168.0.2,SNMP
ServerA,192.168.0.2,agent
core-switch,192.168.0.1,SNMP
This file serves as a clean, structured inventory of monitored devices.
Note: SNMP version fields were excluded in the final export, as Zabbix does not currently display or rely on an SNMP version in the same way PRTG does.
Step 2: Importing into Zabbix
Using Zabbix’s API, we created an import script that reads the CSV and:
- Creates host entries
- Assigns them to the appropriate host group
- Adds relevant interfaces (e.g., Agent,ILO,SNMP or a combination of …)
Each host is configured based on its detected interface type in PRTG.
On the Zabbix side, we used the Zabbix API to automate the creation of hosts, interfaces, and template assignment. The import script reads the CSV line-by-line and takes action based on the interface type.
Considerations and “gotchas”
- Templates: We didn’t add templates, as there is no 1:1 solution – PRTG has a different concept and adding a standard template would be possible but probably not the best solution.
- Host Groups: For ease of use and the limited time we had, we added all hosts in a temporary host group made for the migration. Although we do have scripts that take it out from PRTG and create it in Zabbix, in this particular migration it was not needed.
- Permissions: The API token used in the import script must have sufficient privileges to create hosts.
What is NOT migrated
Because of fundamental differences between the platforms, the following are not directly migrated:
- Historical data or sensor readings: Mainly because the customer had no hard requirement for it.
- Custom PRTG notifications or dependencies: It was easier to manually re-create them.
- Maps or dashboards: The Zabbix approach is so different that it was easier to recreate it manually (and improve).
- Sensors: Zabbix is working with a different concept.
Post-migration tips
- Validation: After the import, verify that each host is reachable and monitored correctly in Zabbix.
- Discovery: Consider using Zabbix’s LLD (Low-Level Discovery) to dynamically find interfaces, disks, or other entities.
- Housekeeping: Disable PRTG monitoring only after confirming Zabbix is fully operational.
Conclusion
Migrating from PRTG to Zabbix is not a one click operation, but with some scripting, planning, and experience from a partner like us, it can be done efficiently and with minimal disruption. The custom export/import scripts act as a reliable bridge between the two systems, allowing for a clean transfer of your monitoring inventory. From there, Zabbix’s automation and scalability features can help take your monitoring to the next level.
If you need assistance with the migration or want to ensure best practices for scaling and optimizing Zabbix, don’t hesitate to reach out to OICTS. We are a Zabbix Premium Partner operating globally, with offices in the USA, UK, Netherlands, and Belgium ready to help you every step of the way.
Interesting.. it would be cool if u share the python script..
“I’d love to, but then who’s going to cover my coffee budget?”
Hello!
Thanks for you post!
What i would like to add (my personal opinion):
– PRTG had clear and easy to understand licencing policy, it was fair and it was reasonably priced (now it not).
– PRTG still has very usefull interface which can be used by IT specialist (and not only) of any level. It still conbines a good cooperations of several very important tools, like maps designer, reporting generator and etc. and supplied as a single product.
But!
– PRTG (first of all) has a weak performance and it can’t be scaled vertically! You can’t use it as SNMP-traps reciever, NetFlow tool and monitoring tool at the same time. It’s all because of poor database performance. It starting to work unstable when you above some items (sensors) level, no matter hardware you have.
– Has a poor integration with side modules.
Same time Zabbix:
– Has a very good database performance (relying of hardware and tuning)
– Has a very good integration with side modules (like grafana and etc.)
– Very customazable system in all system aspects
– Has a lot of “ready to use” templates from companies and developers all over the world and very usefull guides all across the net
In conclution:
PRTG it’s a mid-size monitoring system with low entry threshold
Zabbix it’s a industry standart (already) enterprise level monitoring system, but has quite high entry threshold
More to add: relying on Zabbix road map the product is striving to become much more than monitoring tool, so it’s better to call it “Infractructure Comminication System”! In my opinion that express the real nature of that software much better.
I think your insights are spot on, thanks a lot for taking the time to share them.
Great to publish however nasty to create the article with only images of the script here. You could include maybe a link to a repository somewhere with this…???
Hi Adam,
Thanks for your comment. As you understand, building (+ testing +validating) these type of migrations isn’t something that is done within 5 minutes. As such, we put a lot of effort in helping our customers in the best possible ways which unfortunately means we cannot share all our work for free (who’s gonna pay the mortgage at the end of the month in that case?).
Of course the other option is that we do not write any blog post at all, but again: we try to help as much as possible whomever can take something from these blogposts!
If you are looking for a ready to use, tested, solution feel free to contact me: [email protected] and i will be more than happy to discuss your project!