SolarWinds prices per module (NPM, SAM, NTA, NCM) and then per element inside each module, so a mid-size estate ends up paying for node counts twice. Add the post-SUNBURST supply-chain scrutiny and many shops want a polling engine they can read the source of. Zabbix is the usual destination: one open-source server, SNMP and agent polling, templating, triggers, and dashboards, with no per-node fee. The protocols are the same SNMP and ICMP you already run, so the work is re-modelling, not re-instrumenting.
How the data models line up
SolarWinds thinks in nodes, interfaces, volumes, and applications. Zabbix thinks in hosts, items, triggers, and templates. The translation:
- SolarWinds node → Zabbix host. One host per monitored device.
- Interfaces, volumes, CPU, memory → items, grouped and inherited from a template rather than configured per node.
- NPM/SAM alerts → triggers, expressions over item history.
- Node groups / custom properties → host groups and host macros/tags.
- NetPath / Orion maps → Zabbix maps and dashboards.
The big mental shift is templating. In SolarWinds you largely poll a node and pick metrics; in Zabbix you attach a template (for example Linux by Zabbix agent or Network Generic Device by SNMP) and every item, trigger, and graph comes with it. Get the templates right once and adding the next 200 hosts is a bulk import.
Discovery instead of hand entry
Do not recreate the SolarWinds inventory by hand. Use Zabbix discovery to find hosts and interfaces:
- Network discovery sweeps a subnet by ICMP or an SNMP OID and auto-registers hosts into groups.
- Low-level discovery (LLD) enumerates interfaces, filesystems, and CPUs on a host so you do not declare each
ifIndexmanually.
A working SNMP interface discovery rule keys off the standard IF-MIB walk:
# verify the device answers before trusting discovery
snmpwalk -v2c -c public 10.20.0.5 1.3.6.1.2.1.2.2.1.2
# zabbix_get against the agent to confirm an item key resolves
zabbix_get -s 10.20.0.5 -k 'net.if.in["eth0"]'Tag discovered hosts so trigger thresholds and dashboards inherit automatically.
Triggers and the alerting gap
SolarWinds alerts and Zabbix triggers both fire on thresholds, but the syntax differs. A SolarWinds “CPU > 90% for 10 minutes” becomes a trigger expression:
avg(/Linux by Zabbix agent/system.cpu.util,10m)>90Recreate dependencies too: in Zabbix, a router-down trigger should be a parent so you do not get a storm of “interface unreachable” alerts behind it. Map SolarWinds escalation actions to Zabbix actions with media types (email, webhook to PagerDuty or a chat channel).
Distributed sites: use proxies
Remote and DMZ sites that SolarWinds reached with an Additional Polling Engine map cleanly to Zabbix proxies. A proxy polls locally, buffers during a WAN cut, and ships results back to the server over one port. This also keeps SNMP community strings and agent traffic inside the remote site rather than traversing the WAN per metric.
What the licensing turns into
The headline saving is obvious: Zabbix has no per-node or per-module fee, so the NPM, SAM, NTA, and NCM licensing and the maintenance renewals go away. What replaces them is the infrastructure to run the server, database, and proxies, plus the engineering time to build and maintain templates. That cost is largely fixed rather than scaling per node, which is exactly why templating pays off: the marginal cost of the next few hundred hosts is a bulk import, not a new license line. Watch the database, though, since history and trend retention size it directly. Set housekeeping and retention deliberately per item so a chatty SNMP walk on thousands of interfaces does not quietly balloon storage. Model the recovered per-node and per-module spend in the calculator above against that server, database, and proxy footprint.
Dual-run before you cut over
Stand Zabbix up alongside SolarWinds and poll the same devices in parallel for at least one full cycle of monthly and patch-window events. Compare: do the interface counters match, do the same outages page, are the thresholds tuned. Only decommission SolarWinds modules once an on-call rotation has trusted Zabbix through a real incident.
Where SolarWinds still wins
Be honest about this before you commit:
- NPM polish and NetFlow/NTA. Zabbix flow analysis is weak. If NetFlow, sFlow, and bandwidth forensics are core, SolarWinds NTA or a dedicated flow tool beats anything native in Zabbix.
- Integrated modules. Config backup (NCM), application stacks (SAM), and topology mapping all live in one console in SolarWinds. In Zabbix you assemble that yourself, often adding Oxidized for config backup.
- Vendor support. A paid support contract and a known escalation path matter for regulated or thinly staffed teams. Zabbix has commercial support, but the default posture is you own it.
- Out-of-the-box reporting. SolarWinds reports and SLA views are turnkey; Zabbix reporting is leaner and often pushed to Grafana.
If your value is mostly in flow analysis and turnkey modules, a partial migration (move infrastructure polling to Zabbix, keep NTA) may beat a full rip-out.
The short version
SolarWinds to Zabbix trades per-module, per-node licensing and supply-chain unease for an open-source poller you template once and scale with discovery and proxies. The SNMP and ICMP work is familiar; the real effort is templating, trigger re-expression, and accepting weaker flow analysis and reporting. Dual-run through a live incident before you pull the modules, and model the recovered per-node and per-module spend in the calculator above so the saving reflects the support and flow tooling you may still need to buy.