Migrate from PRTG to Zabbix

Migrate from PRTG to Zabbix: what the move involves and who does it

The move from PRTG to Zabbix is an inventory, rebuild and parallel run, not a data import. You list what PRTG actually monitors, recreate that monitoring in Zabbix using templates, items and triggers, and keep both systems alerting until the results agree. Your PRTG renewal date or licensing change usually sets the deadline, and residency or lock-in concerns often set the priority. Internal platform or network teams usually own the work, with the monitoring engineers who already know the sensors doing the mapping. Some organizations bring in an implementation partner for the template design, proxy layout and hardening, but the people who will run Zabbix afterward should be in the room from the start. Start with the inventory. Export the device and sensor lists through the PRTG HTTP API, then group sensors by type (SNMP, WMI, ping, port, HTTP, custom) and by owner. Historic data can also be pulled through the API, but treat it as reference material: Zabbix will not reproduce PRTG's sensor logic, and most teams keep a read-only PRTG archive for the retention period their auditors require. Maps, notification templates and custom sensors have to be rebuilt by hand. Confirm the PRTG API version and the export fields in your own installation before you script anything, since field names differ between PRTG releases.

The software itself carries no license fee and no device limit. Zabbix moved from GPL-2.0 to AGPL-3.0 starting with Zabbix 7.0, and versions up to 6.4 remain GPL-2.0. Ask your legal team whether the AGPL terms affect how you deploy or modify Zabbix, especially if you expose its web interface to outside users. Zabbix support subscriptions are optional and are sold in tiers. Budget for the people who build, tune and upgrade the system, the servers and database, and any support contract you choose. Check the Zabbix life cycle and release policy to decide which release line to standardize on before you start building templates.

Which PRTG capabilities map cleanly to Zabbix and which need rework

This table pairs each main PRTG capability with its closest Zabbix equivalent and marks whether the move is clean, needs rework or is a gap. Read the status column as a starting hypothesis to test in your own environment, since sensor behavior, thresholds and scripts vary by estate. Custom sensors and PRTG-specific scripts are the rows most likely to take real effort.

PRTG capability	Zabbix equivalent	Status
Device and sensor inventory	Hosts and items, exported from the PRTG API and imported by script	Clean
SNMP sensors	SNMP items and SNMP templates, with discovery rules for interfaces and volumes	Needs rework
WMI and Windows sensors	Zabbix agent items or templates; WMI-based checks need mapping to agent or SNMP items	Needs rework
Custom EXE/XML and script sensors	External check items, user parameters or custom scripts; each must be rewritten and tested	Needs rework
Thresholds and limits	Trigger expressions with severities, recreated per template or host	Needs rework
Maps and dashboards	Network maps and dashboards, rebuilt manually; no automatic import of PRTG layouts	Needs rework
Notifications and escalation	Actions with operations, media types and conditions, rebuilt from PRTG notification rules	Needs rework
User access and permissions	User groups, user roles and host group permissions; confirm role scope against your current PRTG access model	Needs rework
Distributed probes	Zabbix proxies, with proxy groups available from Zabbix 7.0 for load balancing and failover	Clean

Which PRTG data can be exported and which integrations must be rebuilt

The PRTG HTTP API covers the inventory and measurement data you need to plan a Zabbix build, but it does not carry over the configuration that makes alerts useful. Treat the export as input for design and validation, and budget time for everything the API does not move. The cards below separate what you can pull out from what your team must recreate in Zabbix.

Device and sensor inventory

The PRTG HTTP API can list devices and sensors, with their IDs, parent groups, hosts and sensor types, in XML, JSON or CSV. Use this inventory as the source for your Zabbix host list and for mapping each PRTG sensor type to a Zabbix template or item. Check that the export captures every probe and group, because a missing branch becomes a host nobody notices is gone. Confirm field names with your PRTG version before writing any import script.

Live sensor readings

Current values from the API show what each sensor reports right now, including status and last-known channel values. These readings are useful for a parallel-run check: compare the same item in Zabbix against PRTG at the same moment to confirm units, scaling and polling interval match. Live data does not give you thresholds or history, so it cannot replace the rules you rebuild. Record the timestamp of each snapshot so comparisons are fair.

Historic sensor data

The API can return historic values for a sensor over a chosen period, in the same XML, JSON or CSV formats. Whether those values can be loaded into Zabbix history depends on a supported import path, so confirm it with Zabbix before you plan around it. If no path exists, keep the PRTG export as an archive for reporting and plan for Zabbix history to start at cutover. Decide this before the subscription end date.

Maps and dashboards

PRTG maps and dashboards are not portable through the API, so each one must be rebuilt in Zabbix as a map or dashboard using the hosts and items you migrated. Start from the views operators use during an incident, not the full list of old maps. Screenshot or export the layout from PRTG as a reference before you retire it. Expect this to be manual work for each view.

Notification templates and escalation rules

Notification templates, schedules and escalation logic are configuration, not sensor data, and must be recreated as Zabbix actions, media types and user groups. Map each PRTG notification to a Zabbix trigger action and confirm that recovery messages, acknowledgements and maintenance windows behave the same way. Test each rule with a controlled failure before PRTG notifications are switched off. Write down who receives which alert so nothing is lost in translation.

Custom sensors, scripts and ticketing hooks

Custom EXE/Script sensors, their parameters, and outbound hooks to ticketing or chat tools are not carried over by the API. Inventory each custom sensor, rewrite it as a Zabbix item or user parameter, and rebuild every webhook or chat integration as a Zabbix media type or script. Check credentials and API tokens during rebuild, and store them in your secrets tooling rather than in scripts. Owners of these integrations should sign off on the replacement before cutover.

How the PRTG HTTP API feeds an inventory for Zabbix

The export script is the first build step in a PRTG to Zabbix move, and its output is a planning artifact that people must check against the live estate before any host is created in Zabbix. The script walks the PRTG object tree through the HTTP API, starting from the root group and descending through groups, devices and sensors, and records for each sensor its sensor type, its parent device, its polling interval and its current upper and lower thresholds. Those fields matter most because they decide which Zabbix template, item and trigger each PRTG sensor maps to. Live data and historic values come from the same API, but for the inventory you only need the structure and the configuration. Confirm the exact endpoints, parameter names and output formats against the PRTG API documentation for your PRTG version, since the field names in the export are what your mapping sheet will reference.

Once exported, the list becomes the input for two steps: creating Zabbix hosts with their interfaces, and assigning templates. Each PRTG device with an IP address or DNS name becomes a candidate Zabbix host, and each distinct sensor type on it points to a template or an item prototype, such as an SNMP interface template for traffic sensors or a Windows agent template for service and disk sensors. Sensors with custom EXE/XML or script logic have no direct equivalent and belong on a separate review list. Use the exported thresholds to draft trigger expressions, then mark every trigger that was rebuilt by hand. Reviewers should compare a sample of hosts against the live devices and against PRTG's own alarm history, not only against the export. The export is also the last reliable snapshot of PRTG's configuration, so save it before the subscription end and keep it under change control. Confirm with your PRTG licensing contact the date your access ends, and schedule the final export well before that date, so a failed script run does not leave gaps.

Migration sequence from PRTG inventory to decommissioned monitoring

This sequence moves PRTG's device, sensor and alerting knowledge into Zabbix in five controlled phases, so each step produces an artifact that can be checked before the next one starts. The end state is PRTG switched off with a signed-off alert set and an archive of historic data.

Export the device and sensor inventory
The network or monitoring engineer pulls the device list, sensor list, sensor types, thresholds and tags from the PRTG HTTP API into a structured file, then runs SNMP discovery in Zabbix against the same network ranges to find devices that PRTG may have missed or never monitored. Maps, notification templates and custom sensors are not part of this export and must be listed by hand. The step is done when every PRTG device has a matching row in the inventory and the discovery results are reconciled against it, with gaps recorded as explicit decisions. Output: a device list reconciled with the Zabbix discovery results.
Map sensors to templates and items
Run a pilot on a small group of devices with mixed types, such as a few switches, a Windows server and one web service. For each PRTG sensor type, the engineer chooses a Zabbix template or builds an item and trigger, and records the thresholds and polling intervals carried over. Sensors with no clean equivalent, such as custom EXE/XML or script sensors, are flagged for rewrite. The pilot is complete when the pilot devices report the same values in Zabbix that PRTG shows for them. Output: a template map covering each sensor type in the pilot, with the rewrite list for unmatched sensors.
Run both systems in parallel
Keep PRTG polling and alerting while Zabbix monitors the full inventory and sends alerts to a test notification channel, not to on-call staff. The team compares alerts from both systems for the same events, including down states, threshold breaches and recoveries, and logs every difference with its cause. Differences usually come from thresholds, dependencies or time windows and should be fixed in Zabbix before the next run. Confirm the Zabbix database and proxy layout can carry the full polling load during this phase. Output: a parallel-run comparison log showing each mismatch and its resolution.
Cut over notifications and maps
Rebuild notification rules, escalation paths, on-call recipients and maintenance windows in Zabbix, then recreate dashboards and network maps for the operations teams that use them daily. Switch notifications for one team at a time, starting with the team that has the lowest alert volume, and keep PRTG's notifications disabled for the same devices so nobody receives duplicates. Ask the operations owner to confirm each team's alert set and map views in writing. Output: a signed-off alert set and a list of maps and dashboards approved by their owners.
Decommission PRTG and archive history
After every team has confirmed the alert set and the parallel-run mismatches are closed, disable PRTG polling and notifications and keep the server in read-only state for a period agreed with the business owner. Before removing it, export historic sensor data from the PRTG API in XML, JSON or CSV and store it in an archive that the retention policy and any audit requirement can reach. Confirm the license and support end date with Paessler so the subscription is not renewed by accident. Output: an archive of exported history, a closed-out inventory and a written decommission record.

What drives migration cost and duration, and how to keep each down

This table lists the factors that most change the effort and cost of moving from PRTG to Zabbix, why each one matters, and the lever that reduces it. Read it before requesting a quote, because the same rows also make a fixed-scope written proposal easier to compare across providers.

Driver	Why it changes cost or effort	How to keep it down
Number of devices and sensors	Each PRTG sensor usually needs a matching Zabbix item, trigger or template link, so inventory size sets the bulk of build and verification work.	Export the device and sensor lists through the PRTG API first, then drop sensors that are paused, duplicated or no longer used before mapping.
Share of custom or scripted sensors	EXE/Script and custom sensors have no direct Zabbix template equivalent and need hand-written items, scripts or external checks, which is slower to build and test.	Inventory scripted sensors early, group them by purpose, and retire those with no owner rather than porting them.
Notification rules and escalation paths	Each PRTG notification trigger, schedule and recipient must be rebuilt as Zabbix actions, media types and user groups, and tested for each path.	Consolidate duplicate notification rules and agree the target routing with the on-call owners before building anything.
Maps and dashboards	PRTG maps and dashboards are not moved automatically, so each one is rebuilt by hand in Zabbix maps or Grafana.	Keep only maps that operators use daily and replace the rest with templated host views.
Distributed probe layout	PRTG remote probes map to Zabbix proxies, and proxy placement, firewall rules and host assignment drive how much network design is needed.	Mirror existing probe sites one-for-one at first, and consider proxy groups once the layout is stable so hosts redistribute when a proxy goes offline.
History retention needs	Long retention of trends and history increases database size, backup volume and query load, and PRTG history cannot simply be copied into Zabbix.	Agree retention per item class with the business owner, set shorter history for noisy items, and keep trends for capacity reporting.
Database and proxy design	Zabbix runs on MySQL, MariaDB, PostgreSQL or TimescaleDB with versions set by the release requirements, and the server design decides high availability and sizing work.	Pick a supported database version from the Zabbix requirements page, decide early on TimescaleDB, and size the cluster before the cutover.
Internal staff availability	Someone must learn Zabbix templates, discovery and operations, and attend review sessions, and this time is often the largest unpriced cost.	Name an internal owner, schedule time in the current sprint plan, and ask the implementation partner to document each template.
Zabbix technical support subscription (if chosen)	Support is optional, since Zabbix open source has no license fee or device limits, but paid tiers add a recurring cost that varies by response level.	Decide between Silver, Gold or higher tiers against your own outage tolerance, and ask the vendor for current pricing rather than assuming it.

How the move differs for small networks, large estates and distributed sites

A single-site estate that relies mostly on SNMP devices such as switches, routers, firewalls and UPS units is usually the simplest starting point. In Zabbix, most of this work comes down to host creation, SNMP interface settings and matching existing PRTG sensors to standard network templates. Because the device count is modest, a single Zabbix server often handles polling without a proxy, and discovery rules can be tested against a small subnet before anything is switched on.

Proxies: Often none are needed at first. Confirm the polling load on the server before adding a proxy, and only add one if you need a separate collection point.
Discovery: Run low-level discovery rules on one subnet at a time so you can review every new host before it reaches notifications.
Templates: Map each PRTG sensor type (interface traffic, ping, uptime) to a built-in Zabbix template item rather than recreating every sensor by hand.
SNMP credentials: Check SNMP version and community or v3 user settings on each device, since these are the most common reasons discovery fails.
Alerting: Rebuild a small set of trigger severities and one notification route, then extend it.

Before you start, confirm the SNMP version on every device, the number of hosts and sensors you intend to move, and whether anyone outside IT relies on PRTG dashboards.

What usually goes wrong in a PRTG to Zabbix migration and how to prevent it

Most failed monitoring migrations do not fail in the tool. They fail in the gaps between what PRTG did quietly and what Zabbix was told to do. The cards below cover the risks that tend to surface during cutover, and the checks that catch them before a critical alert goes silent.

Thresholds recreated with wrong values

PRTG sensors carry warning and error limits, channel-level settings and sometimes per-sensor scan intervals that were tuned over years. When these are re-typed by hand into Zabbix trigger expressions, units, averaging windows and comparison operators are easily mismatched. Export the PRTG limits through the API, then compare each Zabbix trigger against that export for a sample of hosts before cutover. Treat every hand-typed threshold as unverified until a test value fires it.

Silent gaps in alerting during cutover

The most damaging failure is an alert that existed in PRTG and never got a Zabbix equivalent, so nothing pages anyone when that condition occurs. Cutover windows, where a device is removed from PRTG before its Zabbix trigger is live, create the gap. Keep PRTG active for every device until its Zabbix triggers have been proven, and write down which device moved on which date so gaps can be traced.

Unmapped custom sensors

Custom EXE/Script, WMI, database and REST sensors often hold the logic that matters most to application teams, and they rarely map one to one onto a Zabbix template item. Inventory every non-standard sensor, decide whether it becomes a custom item, a script item or an external check, and assign an owner. Sensors with no owner or no decision should block the cutover of their host.

Notification channels not rebuilt

PRTG notifications for email, SMS, chat webhooks and on-call tools live in notification templates that are not part of the sensor list. Zabbix needs its own media types, user media, actions and escalation steps before any alert is trusted. Test each channel with a real message to the person or group that owns it, and confirm that maintenance periods and recovery notices behave as the team expects.

History expectations never agreed

Teams often assume Zabbix will hold the same years of history as PRTG, but history and trend retention are set per item and per the database sizing. Agree in writing which metrics must be kept, for how long, and which can be dropped. Retention settings applied after a migration do not restore data that was never imported, so record the decision before the first export runs.

Single server with no failover plan

A single Zabbix server and database becomes the new single point of failure for monitoring that used to run on a PRTG probe. Zabbix server supports a native high availability cluster in which several nodes share one database, one is active and the others stand by, and failover occurs after a configurable delay between 10 seconds and 15 minutes. Zabbix 7.0 and later also support proxy groups that redistribute hosts when a proxy goes offline. Decide the failover delay, the proxy group layout and the database backup plan before go-live, and rehearse one failover.

Questions buyers ask before moving from PRTG to Zabbix

How much effort and time does a PRTG to Zabbix move take?

The effort depends mostly on the number of sensors, how many of them are custom or hand-built, and how many maps and notification rules must be recreated. Standard SNMP and agent-based checks map to Zabbix templates quickly, while custom EXE/XML sensors, scripted checks and bespoke dashboards take longer because each one needs a matching item, trigger or dashboard. Running PRTG and Zabbix in parallel until alerts match adds a period on top of the build, so plan for an overlap window rather than a cutover date. Ask for a sensor inventory split into standard, custom and unused categories before any estimate is accepted, because that split drives most of the work.

Can our team migrate from PRTG to Zabbix without outside help?

Yes, a capable team can do it in-house, provided someone owns Zabbix administration, templates, proxies and database operations after go-live. The skills that matter most are SNMP and network fundamentals, Linux server administration, database basics for PostgreSQL or MySQL, and enough Zabbix knowledge to write or adjust templates. Teams without that bench often bring in a partner for the build and keep the run work in house. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms in your environment on a fixed-scope basis, so the split between your staff and an outside team can be written down before work starts.

What does the work need from our staff day to day?

Your staff need to supply access, decisions and knowledge: who owns each device group, which alerts matter, what escalation paths exist and which sensors are still used. Network staff validate SNMP community or SNMPv3 settings and discovery rules, server staff confirm agent deployment, and the on-call team signs off on alert thresholds and notification routing. After go-live, a named operator needs to watch queues, proxy health, database growth and template updates. Confirm internally how many hours per week these roles can give during the overlap period, because a migration that stalls on sign-off will run long regardless of the tooling.

Can we carry PRTG history over into Zabbix?

Usually not as a direct import. The PRTG HTTP API can export device and sensor lists plus historic data as XML, JSON or CSV, but Zabbix stores history in its own database with its own item structure, so a copy is a data archive rather than a live series. Most teams keep PRTG historic exports as read-only archives for audit or capacity reviews and start Zabbix history from go-live. If long retention in Zabbix matters, check the database size and retention settings on the target platform before deciding. Confirm the exact export fields and retention needs with your own compliance and capacity owners first.

How do Zabbix licensing and support tiers affect the decision?

Zabbix's open source software has no license fee, no device limits and no feature gates, so the main licensing question is the AGPL-3.0 terms that apply from Zabbix 7.0 onward, while versions up to 6.4 remain GPL-2.0. Paid support is optional and comes in Silver, Gold, Platinum, Enterprise and Global tiers, with response times from 1 day on 8x5 Silver to 1 hour on 24x7 Global. Your costs are therefore the servers, database, storage, staff time and any chosen support tier. Ask Zabbix to confirm the current tier terms and whether your use triggers any AGPL obligations before you finalize the design.

Which Zabbix release should we target to avoid support gaps?

Choose a release by its support window, not by its newest version. Zabbix 7.0 LTS was released on 4 June 2024 with full support until 30 June 2027 and limited support until 30 June 2029. Zabbix 7.4 was released on 1 July 2025 with full support until Zabbix 8.0 LTS. Zabbix 8.0 LTS is planned for Q4 2026, with full support to Q4 2029. Standard releases are supported for 12 months, while LTS releases are supported for 5 years. Confirm the current dates on the Zabbix life cycle page before you pick a version, since planned dates can move.

What does a fixed-scope Zabbix migration engagement cover?

A fixed-scope engagement covers the items written into the agreed scope, which typically include the inventory and mapping of sensors to Zabbix templates and items, the Zabbix server and proxy build, notification and dashboard rebuilds, parallel running, documentation and handover. It does not include anything left out of the written scope, such as custom application integrations you have not listed. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that scope. Ongoing support, upgrades and continuous testing are available as separate retainers. Ask for the deliverables list, acceptance criteria for alert parity, and what happens if the sensor inventory differs from what was supplied.

How DeployOpen scopes, runs and supports a PRTG to Zabbix migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a PRTG to Zabbix move is run as a written, fixed-scope engagement in your environment. The work covers the API export, template mapping, discovery, notifications and the parallel run, with each step agreed before it starts.

How we scope

Inventory PRTG devices, sensor types, maps, notification rules and custom sensors that must be carried over to Zabbix
Agree which sensors map to standard templates and which need custom items, triggers or external checks
Set the written scope, deliverables and parallel-run exit criteria before any Zabbix host is created

How we build

Script the PRTG HTTP API export of device lists, sensor definitions and history into reviewable files
Build and test Zabbix templates, host groups, discovery rules and proxies against your network segments
Rebuild notification actions, escalation paths and maps, then compare alert behavior with PRTG side by side

How we hand over

Document the Zabbix configuration, template changes, discovery settings and the mapping from each PRTG sensor
Provide a cutover checklist, runbooks for common alerts and a record of differences found during the parallel run
Walk your operations team through daily use before PRTG access is retired at the agreed point

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Plan Zabbix version upgrades against the published support windows, with the work agreed in writing
Confirm with your team which Zabbix support tier, if any, you need, since that is a separate contract with Zabbix

Migrate from PRTG to Zabbix