Zabbix migration from Nagios or PRTG

What a Zabbix migration involves

A move from Nagios, PRTG or another tool is a rebuild of the monitoring model, not a copy of the old checks. In Nagios, each host and service is usually defined by hand in configuration files. In Zabbix, a check becomes an item that collects a value, a trigger that evaluates that value against a condition, and an action that decides who is notified. Host groups and templates replace most per-host configuration, so one template can cover every Linux server or every switch model. Plan the mapping before any host is added: list each existing check, decide whether it becomes a template item, a host-level item, or is retired, and record the threshold logic behind it.

Alert routing needs the same attention. Nagios contacts and contact groups, PRTG notification objects and any escalation paths do not transfer automatically. In Zabbix, media types, user groups, actions with conditions and operations, and maintenance periods have to be rebuilt and tested against real alert scenarios. Confirm with the on-call teams which alerts must page, which create tickets and which only log, because a routing gap often surfaces only after go-live.

Several triggers usually start the project: a change in license or support terms, the end of life of the current tool, consolidation of several monitoring stacks, or a monitored estate that has outgrown the current product. Confirm the timing of your own trigger, including any contract or support renewal dates, because those set the deadline. Zabbix itself is open source under AGPLv3 from version 7.0, and earlier versions under GPLv2, so license terms should be reviewed with your legal team rather than assumed.

Most teams that run a small, well-documented estate with staff who already know Zabbix can do the migration in-house. A partner is more often worth considering when the estate is large, when many remote sites need proxies, when years of history or SLA reporting must carry over, or when the team has no Zabbix experience. Ask any partner to state in writing which checks, dashboards and alert rules are in scope, and how parallel running will be verified.

What the migration work includes

A Zabbix migration is a sequence of work packages, each ending in a document or configuration the client keeps. The cards below follow the order most migrations run in, from the first inventory of old checks through decommissioning the old tool.

Inventory and discovery of existing checks

Every Nagios service, PRTG sensor or other monitoring item is listed with its host, check command, threshold, owner and notification target. Checks that nobody can explain are flagged for review rather than copied. The output is a complete inventory that the rest of the work is measured against, so gaps found here are cheaper to fix than gaps found after cutover.

Check-to-template mapping register

Each old check is mapped to a Zabbix template, item, trigger or host prototype, and the register records which mappings are direct, which need a custom item or user parameter, and which are dropped on purpose. Discovery rules replace hand-maintained host lists where the source tool allowed it. The client receives the register and a reviewed template set.

Notification routing rebuild

Alert routing is rebuilt as Zabbix media types, actions and escalation steps, using the same recipients, schedules and severity rules that the old tool applied. Maintenance periods and acknowledgement behavior are checked against real on-call expectations. The result is an alert parity report that shows which old notifications map to which new actions.

Dashboards and maps

Operator views from the old tool, such as status overviews, site maps and per-service pages, are rebuilt as Zabbix dashboards and maps. Each view is checked with the people who use it daily, since a view that loads but hides a critical host is a regression. Access to dashboards follows the user groups and roles defined in the new system.

Parallel run and alert comparison

Both systems monitor the same hosts for an agreed period, and the team compares what each one detects and notifies. Differences are logged as either intended changes or defects to fix. The parallel run period, its exit criteria and the owner who signs off on them should be agreed before the work starts.

Cutover and decommissioning of the old tool

Notifications are switched to Zabbix in a planned window, with a rollback step documented in advance. After cutover, the old tool is kept read-only for an agreed retention period, then its agents, checks and database are removed. The client receives a runbook covering cutover, rollback, decommissioning and ongoing ownership of the new configuration.

What drives migration effort and cost

The table lists the drivers that move migration effort and cost, why each one matters, and what you can do to reduce it before work starts.

Driver	Why it moves effort	How to keep it down
Hosts and checks	Each host and check needs a mapped template or item, plus validation that it alerts correctly. Volume drives mapping and test hours.	Retire stale hosts and unused checks before mapping. Export the old inventory first and confirm owners.
Custom plugins and PRTG sensors	Each custom script needs an agent item, user parameter, template, or a documented reason to stay outside Zabbix.	Inventory scripts by owner and last run date. Replace simple checks with built-in items and reuse templates.
Alert routes and on-call rules	Every escalation path, time window and recipient must be rebuilt as actions, media types and user groups.	Document current routes with on-call owners. Merge duplicate routes before rebuilding them.
Dashboards and reports	Each Nagios or PRTG view and scheduled report needs a Zabbix equivalent with agreed owners and access.	Limit rebuilds to views people use. Agree a short list of must-have dashboards with each team.
Remote sites and segmented networks	Each site behind a firewall usually needs a proxy, which adds deployment, certificates and firewall rules.	Group sites by network zone. Confirm proxy placement and firewall rules with network owners early.
Environments (test, production, DR)	Each environment needs its own server, database and configuration, so templates must be tested in each one.	Build templates once in test, then promote them through export and import. Size DR to match production needs.
History and trend retention	Historical data from the old tool often does not import cleanly, so retention mainly sets database size and reporting needs.	Decide which history must be kept for audits or capacity trends. Set housekeeping per item type.
Integrations with ticketing and chat	Each ticketing, paging or chat link needs a media type or webhook, plus tests of ticket creation and closure.	List every integration before the build. Reuse one tested webhook pattern across alert types.
Staff available to validate alerts	Alert validation needs people who know the services, so limited staff extends parallel running and threshold tuning.	Schedule a named owner for each service before cutover. Plan review windows where both tools alert in parallel.

Migration phases and what each produces

The sequence moves monitoring from the legacy tool to Zabbix in seven phases, each with a named output, so alert coverage is proven before the old system is retired.

Discover and inventory the existing tool
We export the current checks, contact groups, escalation rules, dashboards and host ownership from the legacy tool, then match each host to a named owner. The output is an inventory register with one row per check, showing its host, owner and alert recipient. The step is done when the client's operations lead confirms the register covers every monitored service.
Decide the target LTS line and layout
The team chooses the Zabbix LTS line, server and database platform, and whether remote sites need proxies or proxy groups. The decision record checks support dates in Zabbix's life cycle policy, including Zabbix 7.0 LTS full support to 30 June 2027 and the planned Zabbix 8.0 LTS in Q4 2026, which the client should confirm before committing. The output is a signed-off architecture decision record.
Map checks to templates and items
Each legacy check is mapped to a Zabbix template, item, trigger or discovery rule, with its threshold and severity recorded. Checks with no direct equivalent are flagged for custom work and costed separately in the scope. The output is a signed-off mapping register, and the step closes when every inventory row has a target or an approved exception.
Build templates and actions in non-production
Engineers build templates, host groups, user groups, media types and notification actions in a non-production Zabbix instance. Each trigger is tested against sample data and a controlled outage, and results are logged against its mapping row. The output is a build record and test log showing which alerts fire, to whom and through which channel.
Run both systems in parallel and compare alerts
The legacy tool and Zabbix monitor the same hosts, while operators act only on legacy alerts. Each alert is compared with the matching Zabbix event by host, check, severity and time, and every difference is classified and fixed. The output is an alert parity log that the operations lead signs before cutover. The length of the parallel period is set in the written scope.
Cut over with written rollback criteria
Alert routing moves to Zabbix on an agreed date, following a cutover checklist that covers notification changes, on-call rotation, runbook updates and a named owner for each step. Rollback criteria, such as a missed critical alert or an unacknowledged escalation, are written in advance, and the legacy routing is kept ready to restore. The output is a cutover checklist and rollback record.
Decommission the old tool
After the parity log is closed and Zabbix has run through the agreed stable period, legacy checks are disabled and historical data is exported to the archive the client chooses. Credentials, access accounts and firewall rules tied to the old tool are then revoked and the service is removed. The output is a decommissioning record and archive manifest showing what was kept and where.

Which parts teams keep in-house and which they outsource

This table shows who usually performs each work stream in a Zabbix migration from Nagios or another tool and which skills it needs, so you can see where a partner adds the most value.

Work stream	Who usually does the work	Skills required
Inventory and business sign-off of checks	Internal owners of each service and host group	Knowledge of what each check protects, which alerts matter to the business, and which checks are obsolete
Zabbix template and item design	Zabbix specialist, often a partner, with internal reviewers	Template structure, item types, triggers, low-level discovery and how Zabbix differs from the source tool's check model
Alert routing and on-call integration	Operations and monitoring engineers, with a partner for design	Media types, escalation rules, on-call tool integration, maintenance windows and alert deduplication
Database and server deployment	Infrastructure team, with partner support for sizing and build	Linux administration, PostgreSQL or MySQL operations, backups, network segmentation and proxy placement
Parallel-run validation	Service owners, with the monitoring team comparing results	Ability to judge whether a missing or extra alert is a gap in the migration or a change in behavior that needs approval
Decommissioning of the old tool	Internal team, after sign-off from service owners	Change control, data retention decisions for historical metrics and clear ownership of archived configuration

How the migration changes by starting point

Nagios checks are commands that return a state, so most map to Zabbix items and triggers. Host and service definitions map to hosts, host groups and templates, but the logic behind them often needs a fresh design.

Maps cleanly: host inventory, host groups, simple check commands with clear OK, warning and critical results, and contact groups that can become user groups and media.
Needs redesign: plugin checks that parse Nagios-specific output, service dependencies and escalation chains, which Zabbix expresses through trigger dependencies and actions.
History: Nagios usually keeps little long-term performance data, so there may be no history to carry over. Confirm what your installation actually retains.
Sequence: build templates before importing hosts, so checks are not recreated one host at a time.

What usually goes wrong and how to prevent it

Monitoring migrations rarely fail loudly. The problems below tend to surface weeks after cutover, when an incident goes unreported or a report comes up empty, so plan the controls before the first host moves.

Alerts that stop firing silently

Nagios notifications, PRTG sensor triggers and their escalation paths often do not map one to one into Zabbix triggers and actions. Keep an alert parity log that lists every source alert, its Zabbix trigger or action, the owner who tested it, and the date it fired in a controlled test.

Undocumented checks found late

Legacy systems often run checks that no one wrote down, such as scripts in cron, plugin calls embedded in configuration files or checks tied to a single engineer. Inventory the old hosts from their configuration and runtime state, not only from the monitoring console, and sign off the inventory with each service owner.

Thresholds copied without review

Thresholds from the old tool were set for older hardware, traffic patterns and business hours. Copying them into Zabbix can create alert storms or hide real degradation. Review each threshold with the service owner and record the reason for any value that changes.

Missing maintenance windows and dependencies

Scheduled maintenance periods, parent-child dependencies and suppression rules often live in the old tool and disappear at cutover, so planned work pages the on-call team. Export those rules, rebuild them as Zabbix maintenance periods and dependencies, and test one planned outage before go-live.

History gaps that break reports

Dashboards, SLA reports and capacity reviews usually need months of history, but a new Zabbix instance starts empty. Decide which history must be imported or retained in the old system, set history and trends retention in Zabbix to match, and confirm that reports read from the right source during the transition.

Parallel runs with no end date

Running both systems is useful only if someone compares their results. Without a comparison method, the parallel run drifts into a permanent second system. Set a comparison schedule, assign an owner for discrepancies, define the criteria for retiring the old tool, and keep a rollback plan until that date.

What you need to provide

The migration only moves as fast as the inputs you supply. Before scoping starts, gather read access to the existing tool (Nagios, PRTG or other) and an export of its configuration, including host definitions, check commands, contact groups and notification rules. Without the export, the team has to rebuild every check from the running system, which is slower and easier to get wrong.

Provide the inventory of hosts and business services in one list, with each service mapped to the hosts it depends on. Name an owner for each service who can approve thresholds, alert routing and on-call rules. Owners should sign off on the mapping before any template is built, because a threshold that was never agreed will either flood the on-call rota or stay silent when it matters.

Confirm network access early. Agents, proxies and the Zabbix server need defined paths to monitored hosts, and firewall changes often take longer to approve than the build itself. You also need a database and server platform to run Zabbix, plus a non-production environment where checks, alerts and dashboards can be validated against real data before any cutover.

Confirm early: which Zabbix LTS line your organization approves, and which database engine it supports. Zabbix 7.4 supports MySQL, MariaDB, PostgreSQL and TimescaleDB within stated version ranges, so the database choice is tied to the release decision. Name one decision maker for cutover and rollback, with authority to pause the old tool's alerts or restore them.

Questions about migrating to Zabbix

Does Zabbix charge a license fee for a migration from Nagios?

No. Zabbix states that its open source software has no license fee, no device limits and no feature gates, so the cost of a migration is labor, infrastructure and any support subscription you choose. From Zabbix 7.0 onward the software is released under the GNU Affero General Public License version 3, and earlier versions were released under the GNU General Public License version 2. Have your legal or compliance team confirm how those license terms apply to your own use and any modifications you plan to make.

Can our own team migrate our monitoring to Zabbix without a partner?

Yes, many teams do, and the deciding factor is whether they have the skills and free time to do it. In-house work requires people who can design templates, items, triggers and actions, operate a database, and rebuild alert routing and dashboards. Bring in a partner when that experience is missing or when your staff cannot support both monitoring systems during the parallel run. Whichever path you choose, put the scope in writing, including what is migrated, what is retired and who signs off.

What drives the cost and timeline of a Zabbix migration?

Scope drives most of the effort. The main factors are the number of hosts and checks, the number of custom plugins, scripts and notifications in the old tool, the number of remote sites that need Zabbix proxies, and how many dashboards and alert routes must be rebuilt. Integrations with ticketing, identity and on-call tools add work, as does testing. When requesting a quote, ask for each deliverable, the assumptions behind it, and a list of what you must provide, such as access, configuration exports, test windows and named reviewers.

How long should the parallel run last, and who decides when to stop?

No single duration fits every environment. Run both systems long enough for each alert type to fire and resolve at least once, and cover your normal change and maintenance cycle. The service owner and operations lead should decide when to stop, with sign-off from the security or compliance owner where monitoring supports controls. Record the exit criteria in the scope before the parallel run begins, so the decision rests on agreed evidence rather than on pressure to finish.

Can historical monitoring data from Nagios or PRTG be imported into Zabbix?

It depends on what the old tool can export and how that data maps to Zabbix history and trends. Some tools export history in usable formats, while others store data in proprietary structures that need conversion. In many cases the practical approach is to archive the old data for reference and load only the series your reports need. Confirm the export options, required retention and the time range for trend reports during scoping, because these choices affect both the effort and the database sizing.

What do Zabbix support subscriptions cover after go-live?

Zabbix offers paid technical support subscriptions in Silver, Gold, Platinum, Enterprise and Global tiers. Silver provides 8x5 support with a 1 day response, while Global provides 24x7 support with a 1 hour response. These subscriptions cover vendor technical support for the Zabbix software, but they do not replace internal ownership of templates, alert tuning or upgrades. Confirm the tier that matches your operating hours and response needs, and ask whether ongoing support, upgrades and testing should be handled through a separate retainer.

How DeployOpen runs Zabbix migrations

DeployOpen plans, builds, documents and hands over Zabbix migrations from Nagios, PRTG or another monitoring tool inside infrastructure you control. The work is scoped in writing first, so your team knows which checks, alerts and dashboards move, and when.

How we scope

Inventory every existing check, alert, notification route and dashboard, and record which ones are still needed.
Map each check to a Zabbix template, item, trigger or discovery rule, and flag any with no direct equivalent.
Agree the written scope, deliverables and timeline in advance, since most engagements are fixed-scope.
Confirm the Zabbix release line, database platform and proxy layout against the official requirements page before build.

How we build

Build the Zabbix server, database and proxies in your environment, then import templates and hosts in controlled batches.
Rebuild alert triggers, escalation paths and media types so notifications reach the same people through the same channels.
Run Zabbix and the legacy tool in parallel, comparing alert behavior for each migrated host group before cutover.
Test failure cases such as a proxy going offline or a notification channel failing, and record the results.

How we hand over

Document the template structure, host naming, trigger logic and alert routing so your team can maintain them.
Provide a cutover record listing each migrated check, its status and any checks retired on purpose.
Walk your operators through dashboards, maintenance windows and day-to-day alert handling before handover.
Deliver the runbook for decommissioning the legacy monitoring tool once parallel running is complete.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
Plan Zabbix upgrades between LTS lines once the migration is stable, following the vendor life cycle dates you confirm.
Ask your Zabbix support subscription tier and response times with the vendor if you want vendor-level cover alongside DeployOpen.
Review alert noise and template drift periodically so monitoring keeps matching the systems it watches.

Zabbix migration from Nagios or another monitoring tool