Migrate from SolarWinds NPM to Zabbix: what the move involves
A network team facing a SolarWinds renewal or a self-hosting requirement needs to know what the move involves before committing. The migration exports inventory and alerting logic from Orion, rebuilds them in Zabbix as hosts, templates and triggers, and runs both systems in parallel until coverage matches before cutover. The work is mostly rebuilding, not copying, because Orion's node, interface and alert objects do not map one to one onto Zabbix's host, item and trigger model.
Internal network engineers usually own the work, since they know which devices, VLANs, interfaces and thresholds actually matter. An implementation partner typically adds planning, template design, proxy layout and hardening, and a fixed written scope keeps those tasks visible. Effort and risk depend mainly on the device count, the number of custom properties and alert definitions in Orion, how many remote sites need proxies and how much historical data the business must keep. Confirm each of these against your own environment before estimating duration, since no fixed figure applies across estates.
Zabbix 7.0 and later are released under AGPL-3.0, and the open source software carries no license fee, no device limits and no feature gates. Paid technical support is optional and is sold in tiers, so budget it as a separate decision from the software itself. Use the Zabbix license page to confirm the license terms that apply to the version you plan to deploy, and treat the scope document as the place to record which support tier, if any, you need.
Which NPM capabilities map to Zabbix, and which need rework
This table maps the main Orion NPM capabilities to their Zabbix equivalents and marks each row as clean, needs rework or gap. Read the status column as a planning signal: clean rows usually translate with configuration, rework rows need templates or design changes, and gaps need a confirmed workaround before cutover. The main takeaway is that inventory, polling, alerting and HA translate well, while path analysis and cross-metric correlation need deliberate design.
| NPM capability | Zabbix equivalent | Status |
|---|---|---|
| Node and interface inventory | Hosts and discovered interfaces via low-level discovery, created through the Zabbix API from the SWQL export | Clean |
| SNMP polling | SNMP agent items and interface templates, with bulk polling tuned per host group | Clean |
| Custom properties | Host inventory fields and host tags; confirm which Orion custom properties need a mapping | Needs rework |
| Alert definitions | Triggers with severity and recovery expressions; SolarWinds thresholds must be rewritten by hand | Needs rework |
| Maps and topology views | Network maps built in the Zabbix frontend; automatic topology needs confirmation for your device mix | Needs rework |
| Remote site polling | Zabbix proxies at each site; proxy groups redistribute hosts when a proxy goes offline | Clean |
| High availability | Native server HA cluster sharing one database, with a configurable failover delay | Clean |
| NetPath-style path analysis | No direct equivalent; confirm with your team whether it is required or design around it with traceroute checks | Gap |
| PerfStack-style metric correlation | No direct equivalent; plan dashboards in Grafana or Zabbix graphs and confirm the workflow with users | Gap |
How the migration sequence runs from inventory to decommission
The sequence moves the NPM inventory and alert logic into Zabbix in controlled stages, so each phase ends with a checked artifact before the next one starts. NPM is switched off only after a parallel run shows that Zabbix covers the same devices and alerts.
Export the Orion inventory with SWQL
The network team runs SWQL queries through the Orion SDK, or from SWQL Studio, to pull nodes, interfaces, IP addresses, custom properties, pollers and polling intervals from the Orion database. Each export is saved as a dated file that the team can version and review. The step is complete when the record count for each object type matches what the Orion web console shows, and someone outside the export team has checked a sample of rows against the console.
Classify the inventory into migration groups
Engineers group the exported nodes by site, device role, vendor and monitoring need, and mark which items are in scope, retired or duplicated. Custom properties such as owner, location and environment are mapped to Zabbix host groups, tags and inventory fields. The output is a reviewed inventory file with one row per host, a proposed group and template for each host, and a list of exclusions signed off by the service owner.
Import a pilot host set through the Zabbix API
A small, representative set of hosts from different sites and device types is created in a non-production Zabbix instance using the Zabbix API, with the host groups, templates and interface settings from the classification sheet. Polling results are compared with what NPM reports for the same interfaces over the same period. The pilot is complete when every pilot host shows expected items, the values agree with NPM within an agreed tolerance, and the import script can be rerun without creating duplicates.
Build the alert and trigger mapping sheet
The team lists every active NPM alert definition and maps it to a Zabbix trigger, a template macro or a deliberate omission. Thresholds, severity, suppression windows and recipient groups are recorded beside each mapping, and alerts that depended on NPM-only features are flagged for a separate decision. The output is a trigger mapping sheet approved by the operations lead and the owners of the affected services, with each NPM alert marked as rebuilt, replaced or retired.
Place Zabbix proxies at remote sites
Engineers decide which remote segments need a Zabbix proxy, based on the inventory and on the connectivity between each site and the central server, and deploy the proxies close to the monitored devices. Hosts are then assigned to their proxy, and proxy groups are considered where a proxy outage must not stop polling. The step is done when each remote host reports data through its proxy, the server shows the proxies as online, and a test loss of the link at one site does not affect other sites.
Run both systems in parallel
Zabbix monitors the full inventory while NPM keeps running, and both feed notifications into a test channel, not the live on-call path, until the team trusts the results. Each week the team compares device availability, interface status, utilization figures and fired alerts between the two systems and logs every gap. The parallel run ends with a signed-off comparison report that lists each discrepancy, its cause and its resolution, and that the network and operations leads have approved.
Cut over alerts and decommission NPM
Zabbix notifications are switched to the live on-call and ticketing channels, and the old NPM alert actions are disabled in the same change window. NPM is kept in read-only mode for an agreed retention period so that historical reports remain available for audit or trend questions. Once the retention period ends, the Orion server, database and licenses are retired, and the final export is stored with the change records. The sequence is closed when the cutover checklist, the decommission record and the archived NPM data are all filed.
What data moves out of Orion and what integrations to rebuild
Four export paths cover most of what leaves Orion: device inventory, interface and custom property data, alert definitions and historical performance. Each one needs a different amount of rework in Zabbix, so plan them separately and confirm every query against your own NPM version before you rely on it.
Node and interface inventory
The Orion SDK (Apache-2.0) and SWQL queries against the Orion database return nodes, IP addresses, vendors, interfaces and their status. Use this list as the source for bulk host creation in Zabbix through its API, and filter out retired or unmanaged nodes before import. Check that interface indexes and names survive the export, because Zabbix item keys depend on them. Confirm the entity and field names in SWQL Studio for your NPM release, since schema names change between versions.
Custom properties as host tags
Custom properties such as site, owner, cost centre and criticality are often the only structured context NPM holds. Export them with the node list and map each one to a Zabbix host tag or inventory field, so triggers and dashboards can filter on them later. Agree the tag naming scheme before the import, because renaming tags after hosts exist means editing every host. Ask the team which properties are still maintained, and leave stale ones out.
Alert definitions as a rebuild list
Export alert definitions with their conditions, thresholds, schedules and actions using SWQL or the PowerShell module, then treat the output as a specification rather than a configuration file. Zabbix triggers, actions and media types do not map one to one, so each alert needs a written target trigger and owner. Flag alerts that only fire on a single vendor's counters, since those need a template or a custom item first.
Ticketing and notification transports
Email relays, chat webhooks, SMS gateways and ticket creation hooks are configured inside Orion, and their credentials rarely appear in any export. Inventory each transport, record its endpoint and recipient group, and rebuild it as a Zabbix media type with its own test action. Keep the old NPM transports disabled but present until a test alert has reached every destination through Zabbix. Confirm with the service desk owner which fields the ticket integration expects.
Dashboards and maps
NPM views, maps and custom dashboards are presentation layers, and Zabbix maps and dashboards must be recreated by hand or through the API. Start from the views operators open daily, not the full library of NPM screens. Record which dashboards are used for shift handover or executive reporting, because those need sign-off from their consumers.
Historical performance data
Years of interface and node statistics are usually archived rather than imported, since Zabbix history and trend tables are built around its own item model and retention settings. Export the reports your audit or capacity planning needs as files, store them in a system the team can still read, and set Zabbix history and trend retention for the period you actually query. Ask the NPM owner which reports auditors have requested in the last year.
How Zabbix proxies and HA replace NPM at remote sites
Remote sites are where a Zabbix design either holds up or fails, so decide the proxy layout before you import a single host. A Zabbix proxy sits in each remote segment, collects data from the devices there, and forwards it to the central Zabbix server. Map each NPM polling engine or additional poller you run today to a proxy, and group devices by the network segment they can actually reach, not by geography alone. Check that every proxy can open its outbound connection to the server on the ports your firewall rules allow, and test that path before cutover.
Since Zabbix 7.0, proxy groups can take over monitored hosts when a proxy goes offline, redistributing them across the remaining proxies in the group for load balancing and high availability. This matters for remote sites with only one or two proxies: a group with a single member gives you no failover at all. Confirm the proxy group behavior against the Zabbix proxy load balancing and high availability documentation and size each surviving proxy for the extra load, since a standby that cannot carry the hosts will fail quietly.
The central server can be protected with Zabbix's native high availability cluster. Several server nodes share one database, one node is active and the others stand by, and failover happens when the active node exceeds a configurable failover delay between 10 seconds and 15 minutes. Choose the delay based on how long a brief network blip should be tolerated before a switch, and document it. For database backends, Zabbix 7.4 supports MySQL or Percona 8.0.30 to 9.7, MariaDB 10.5 to 12.3, and PostgreSQL 13 to 18 with TimescaleDB 2.13 to 2.29, with SQLite available for proxies only. Confirm your chosen version against the Zabbix requirements page before you build, because your Zabbix version and database must match that matrix.
How the move differs by estate size and starting point
A single-site estate is usually the simplest move because all polling can run from one Zabbix server and the device list lives in one Orion instance. The main work is confirming that SNMP access, credentials and discovery ranges are already in place, then rebuilding the monitoring model in one pass. Little or no proxy design is needed, so the effort concentrates on templates and alert rules rather than network layout.
- Discovery scope: Export the node list from Orion with SWQL, then decide which devices need hosts in Zabbix and which can be retired.
- Template reuse: Map common device types to the standard Zabbix SNMP templates before creating any custom ones.
- Single server sizing: Confirm the server and database sizing for the total number of items the estate will produce, using the requirements page.
- Simple parallel run: Both systems can usually be compared against the same devices for a short overlap, with one set of owners.
- Credential handling: Move SNMP community strings or SNMPv3 users into Zabbix macros once, and check that no secret is left in exported files.
Confirm the device count, the SNMP version used on each device and whether any device sits behind a firewall that Zabbix cannot reach directly.
A multi-site estate changes the design more than the data. Each remote location needs a path for polling, and a proxy placed at each site keeps collection local while the central server stores the results. Proxy groups in Zabbix 7.0 and later can spread hosts across proxies, which matters when a remote site has more than one collector or when a proxy must be replaced.
- Proxy placement: Decide which sites need their own proxy and which can be polled over the WAN, based on latency and the stability of each link.
- Proxy groups: Use proxy groups where a site needs redundancy, since hosts are redistributed when a proxy goes offline.
- Ordering by site: Migrate one site at a time, so each proxy is verified before the next site moves.
- Database placement: Confirm where the Zabbix database sits relative to the central server, because a slow link between them can affect performance.
- Segment access: Check firewall rules from each proxy to its devices and to the central server before cutover.
Confirm which sites have existing Orion polling engines, which links carry monitoring traffic today and whether any site must keep local collection during a WAN outage.
An estate that relies on many custom properties and bespoke alerts takes the longest to rebuild, because those fields often carry business meaning such as owner, service, location or severity. Zabbix does not copy these one to one, so each property must be mapped to a host tag, inventory field, macro or group, and each alert must be reviewed before it becomes a trigger. The work is mostly analysis and agreement with the teams who depend on the alerts.
- Property inventory: Export custom properties with the Orion SDK and list which ones drive reports, alerts or dashboards.
- Target mapping: Decide whether each property becomes a host tag, a host group, a macro or an inventory field.
- Alert review: Rebuild only alerts that are still used, and document the ones retired during the move.
- Trigger logic: Translate threshold and dependency logic into Zabbix triggers and trigger dependencies, testing each with known conditions.
- Owner sign-off: Get the application or service owners to confirm that routing and severity match what they expect.
Confirm how many alerts fire in a typical month and which ones feed incident tooling, because those are the ones that must not go quiet during the overlap.
An environment that already runs Zabbix is not starting from zero, but the migration still adds work. The task becomes consolidation: deciding which Orion data sets belong in the existing Zabbix instance, avoiding duplicate hosts, and aligning templates, naming and ownership. The existing platform may also need an upgrade path, since the supported release that fits the estate depends on its life cycle.
- Duplicate detection: Match Orion nodes to existing Zabbix hosts by name, IP and interface before any import runs.
- Template conflicts: Compare the templates in use with the ones the new devices need, and resolve differences before importing.
- Version check: Confirm the current release and its support end date using the life cycle page, and plan any upgrade before adding new load.
- Ownership model: Decide whether the Orion data lands in an existing team's scope or a new one, which affects permissions and authentication.
- Capacity review: Recheck database and proxy capacity, because the added items will raise the load on the existing server.
Confirm the Zabbix version in use, whether it runs as a cluster and which teams already own its hosts and triggers.
Questions buyers ask before migrating from NPM to Zabbix
What drives the cost and effort of moving from NPM to Zabbix?
The main drivers are the number of nodes and interfaces to rebuild, how much of your NPM alert and report logic needs a Zabbix equivalent, and how many remote sites need proxies. Zabbix itself has no license fee, no device limits and no feature gates, so the cost is mostly the servers, the database, the staff time for templates and triggers, and any support subscription you choose. Ask any implementation partner for a quote built from a written scope that lists these components separately, and ask which items are one-time work and which recur each year.
Can our internal engineers migrate NPM to Zabbix themselves?
Often yes, if the team already knows SNMP, Linux and the Zabbix frontend and has time to rebuild templates and triggers. The work splits into exporting inventory from Orion, creating hosts and templates in Zabbix, rebuilding alerts, and validating results against NPM. Teams without a Zabbix operator on staff usually need outside help for the design and the first deployment. Check your team's skills and capacity against that split before deciding.
What does the work need from our staff during a migration?
You will need someone who can export node, interface and custom property data from Orion using the SDK and SWQL, a person who owns the alert rules and knows which ones matter to operations, and network staff who can confirm SNMP community or credential settings and device access. You also need a change window for cutover and someone who can sign off that monitoring coverage matches NPM for each site. Agree these responsibilities in writing before the project starts so nobody assumes the other team is doing them.
How long should we run NPM and Zabbix in parallel?
In principle, run both systems until Zabbix reports the same device, interface and alert coverage as NPM for every site, and until your team has handled at least one real incident through the new alerts. The exact period depends on your change cycle, reporting cycle and how many alerts need rework, so no fixed duration applies to every estate. Set exit criteria at the start, such as matched inventory counts and tested escalation paths, and confirm the timeline with your implementation partner and your own change board.
Can Zabbix replicate NetPath path analysis?
Not as a like-for-like feature. NetPath-style hop-by-hop path analysis is a capability that Zabbix does not provide out of the box, so teams that rely on it need to plan an alternative. Options include using Zabbix maps and interface data for path context, adding separate path-tracing tooling, or keeping NPM running for that specific use case during the transition. Confirm the exact gap with Zabbix documentation and test it against the workflows your network engineers actually use.
Does the AGPL license affect internal use of Zabbix?
Zabbix 7.0 and later are released under the GNU Affero General Public License version 3, while versions up to 6.4 were under GPL-2.0. Running Zabbix internally for your own monitoring does not require you to publish your configurations, and the license does not charge per node. The AGPL obligations are more relevant if you modify Zabbix and offer it to others over a network. Your legal team should review the license terms on the Zabbix license page and confirm how they apply to your deployment model.
What do Zabbix support tiers add beyond the open-source software?
Zabbix open-source software is free, and paid technical support subscriptions are sold separately in Silver, Gold, Platinum, Enterprise and Global tiers. The tiers differ in coverage hours and response times, ranging from 8x5 support with a 1 day response at Silver to 24x7 support with a 1 hour response at Global. Compare these against how quickly your network operations team needs an answer during an outage. Ask Zabbix for current pricing and terms, since these are not part of this guide.
Which Zabbix versions should a new deployment target?
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 and receives full support until Zabbix 8.0 LTS. Zabbix 8.0 LTS is planned for Q4 2026. Pick the release line that matches your support window and upgrade plans, and confirm the current support dates on the Zabbix life cycle page before you commit.
What usually goes wrong when moving NPM alerts and inventory
Most failed NPM-to-Zabbix moves break in the same few places: the inventory export, the alert logic, the parallel run, the network path to remote sites, the database and the reporting history. Each card below names one failure, why it hurts during this migration, and the check that prevents it.
Incomplete custom property exports
Orion custom properties often hold the fields that drive grouping, ownership and alert routing, such as site, rack, owner or service tier. A standard node export through the Orion SDK may return the built-in fields and miss these unless each custom property is requested explicitly. Before importing, compare a sample of nodes in SWQL Studio against the export file and confirm every custom property has a matching Zabbix host tag or inventory field.
Alert logic that does not map cleanly
NPM alert conditions are often built from thresholds, time windows and object scopes that do not translate one to one into Zabbix triggers, which use item expressions, recovery expressions and dependencies. Some NPM alerts will need to be split into several triggers, and some will need a dependency so one unreachable router does not raise a flood of interface alarms. Review each exported alert definition and record whether it becomes a trigger, a dependency, a trigger with recovery logic or nothing.
Duplicate alerts during the parallel run
Running NPM and Zabbix side by side means two systems can page the same on-call group for the same outage. Route notifications from one system only per host group, or send Zabbix alerts to a test channel until each trigger has been checked against NPM for a full review period. Agree in writing which system is authoritative for each site before the first parallel day.
Proxies placed without firewall and DNS review
Zabbix proxies at remote sites need outbound connectivity to the central server on the trapper port and must resolve the names of the devices they poll. Teams often place a proxy by copying the old NPM polling path without checking firewall rules, SNMP access lists or DNS zones for the remote segment. Map each proxy's required flows, confirm SNMP reachability from the proxy host, and test name resolution before moving any hosts to it.
Database sizing for history
Zabbix stores every collected item value in its database, and history and trend retention determine its size. Teams that copy NPM polling intervals and retention without recalculating storage can run out of disk within the first months of production. Before go-live, ask your database administrator to size history and trend tables using the expected item count and polling interval, and confirm the supported database versions for the chosen release with the Zabbix requirements page.
Loss of NPM report continuity
NPM scheduled reports, capacity trends and monthly bandwidth summaries are often used by finance, audit or service review meetings, and Zabbix will not reproduce them automatically. Export the historical reports you need as files before NPM access ends and document which dashboards in Zabbix replace each one. Agree with report consumers which trend periods must be present in Zabbix on day one and which can be recovered from archives.
What drives migration cost and duration, and how to keep each down
This table lists the factors that change the effort of moving from SolarWinds NPM to Zabbix, why each one matters, and how to reduce it. Read it before requesting a quote, since most of the cost sits in node count, alert rebuild and remote-site proxies rather than in the software itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Node and interface count | Each node and interface needs a host, items and discovery rules. Volume drives export scripting, import runs and validation sampling. | Retire unused nodes before export. Group interfaces by template so bulk creation replaces manual work. |
| Custom property complexity | Orion custom properties must map to Zabbix host groups, tags or inventory fields. Free-text or inconsistent values need cleaning first. | Audit custom properties with SWQL before migrating. Agree a tagging scheme and map only the properties that drive alerts or reports. |
| Alert definitions | Each NPM alert becomes a Zabbix trigger, action and media rule. Alerts with compound logic take longer to rebuild and test. | Export alert definitions and delete inactive or duplicate ones. Rebuild critical alerts first and retire the rest after review. |
| Remote sites needing proxies | Every remote segment needs a Zabbix proxy, its own configuration and network path, and a test of polling through firewalls. | Group sites by network path. Consider proxy groups for high availability and confirm the design with your network team. |
| Database choice and retention | The database sizing and history retention settings determine hardware, storage and purge jobs. Long history adds cost and tuning work. | Confirm supported database versions for your release. Set history and trend retention per item type rather than globally. |
| Integrations and notifications | Ticketing, chat, paging and reporting integrations each need their own media type, credentials and testing. | Inventory every downstream consumer of NPM alerts and reports. Migrate only those still in active use. |
| Staff availability and skills | Migration needs people who know Zabbix templates, SNMP and your network. Shortages extend the parallel run. | Name owners for templates, alerts and cutover. Ask whether vendor or partner training is included in the scope. |
| One-time work | Export, template build, import, alert rebuild, validation and parallel run are paid once, typically as project effort. | Fix the scope in writing so each phase has defined deliverables and acceptance criteria. |
| Recurring costs | Staff time to maintain templates and upgrades continues. A Zabbix technical support subscription, if chosen, recurs by tier (Zabbix support page lists Silver to Global tiers). | Compare support tiers against your response needs. Confirm current tier pricing directly with Zabbix, since none is supplied here. |
How DeployOpen scopes and runs the NPM to Zabbix migration
DeployOpen plans and implements self-hosted Zabbix inside your own infrastructure, so the Orion export, host import, alert mapping and proxy placement are agreed in writing before work starts. The work is delivered as a fixed-scope engagement, with documentation and a supported handover at the end.
How we scope
- Inventory of Orion nodes, interfaces, custom properties and alert definitions to be exported and mapped
- List of remote sites that need Zabbix proxies, with network paths and firewall rules to confirm
- Decision on which NPM alerts become Zabbix triggers, which are retired and which need a new owner
- Written scope, deliverables and timeline agreed before any export or build work starts
How we build
- Export scripts for nodes and interfaces using the Orion SDK and SWQL, run against a copy of your data
- Zabbix server deployed on your chosen database, with the high availability design agreed in scope
- Host import through the Zabbix API, with templates and trigger mappings tested on a sample of devices first
- Proxies placed at remote sites and checked for polling, data delivery and recovery after a link drop
How we hand over
- Runbooks for host onboarding, template changes, proxy maintenance and upgrades to later Zabbix releases
- Side-by-side comparison report showing which NPM alerts map to which Zabbix triggers and where gaps remain
- Access control and user roles documented against your identity policy, with the configuration kept in your environment
- Parallel-run period closed by a written sign-off on coverage, owned by your operations team
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope covers Zabbix version upgrades, proxy changes and new device templates as your network changes
- Quotes follow from the written scope, so ask for the cost of each deliverable and any retainer separately
- Confirm with your own team which Zabbix support tier, if any, you want alongside a DeployOpen retainer
