Migrate from New Relic infrastructure monitoring to Zabbix: what the move involves
A team that uses New Relic mainly for servers, network devices and hosts can usually move that work to Zabbix, which covers most host and network monitoring through agents, SNMP and templates. The main gap is APM: Zabbix does not replace New Relic's transaction tracing, code-level profiling or service maps, so application performance data needs a separate path such as OpenTelemetry feeding Jaeger or Prometheus. Decide that split before you start, because it sets the scope of the migration and of any renewal or licensing conversation.
The work is normally done by an internal platform or infrastructure team, with or without an implementation partner. Start with an inventory of what New Relic currently collects: host and infrastructure integrations, network polling, custom events and the alert conditions tied to them. Then map each item to a Zabbix equivalent, such as an agent item, an SNMP template or a proxy-collected check. Confirm the template and item coverage for your specific device models and operating systems in your own environment, since the vendor catalogs change between releases. Plan for the fact that triggers and notification actions must be rebuilt by hand, so the alert logic is usually the largest source of rework and the largest risk of silent gaps.
Run both systems in parallel for a period you agree with the on-call owners, and compare alert behavior, not just dashboards. Check the Zabbix version you are standardizing on against the Zabbix life cycle and release policy so the support window covers your planned operating life, and note that Zabbix 7.0 and later are released under AGPLv3, which your legal team should review for your use case. Confirm the database and high availability design early, including the server cluster and proxy groups, because those choices drive the infrastructure you will run and maintain after go-live.
Which New Relic infrastructure capabilities map cleanly to Zabbix
This table maps the host, network and alerting capabilities most teams use in New Relic infrastructure monitoring to their Zabbix equivalents. Read each row as clean (direct equivalent with standard setup), needs rework (possible, but templates, triggers or pipelines must be rebuilt), or gap (no equivalent in Zabbix, so another tool is needed). The main takeaway is that Zabbix covers host, network and alerting work well, while APM tracing needs OpenTelemetry with Jaeger or Grafana alongside it.
| Capability | Zabbix equivalent | Status | What to confirm or rebuild |
|---|---|---|---|
| Host metrics (CPU, memory, disk, processes) | Zabbix agent or agent 2 with built-in and template items | Clean | Confirm the agent version supports your operating systems and that item keys match what your dashboards read |
| Agent-based collection and custom checks | Zabbix agent items, user parameters and scripts | Needs rework | Re-create each New Relic custom event or script as a user parameter, then test intervals and error handling on a staging host |
| SNMP and network devices | SNMP items, discovery rules and network templates | Clean | Check MIB coverage for each vendor model, and export the device inventory before running discovery |
| Dashboards | Zabbix dashboards, maps and graphs | Needs rework | NRQL dashboards do not convert automatically, so rebuild panels by hand and review which charts teams actually use |
| Triggers and notifications | Triggers, actions, media types and escalations | Needs rework | Map each New Relic alert condition and notification channel to a trigger, action and recipient, then test each path |
| Remote sites and proxies | Zabbix proxies and proxy groups (Zabbix 7.0 and later) | Clean | Confirm proxy sizing and the database option for each site, since proxies support SQLite but the server requires a supported database |
| High availability for the monitoring server | Native server high availability cluster on a shared database | Needs rework | Plan the shared database, failover delay and backup procedure as part of the design, not after go-live |
| APM traces and transactions | No equivalent. Zabbix does not trace requests through application code. | Gap | APM tracing is a gap that needs OpenTelemetry with Jaeger or Grafana alongside Zabbix, so plan that instrumentation as a separate workstream |
What Zabbix does not cover compared with New Relic APM
Zabbix is an infrastructure monitoring system. It collects metrics, discovers hosts, evaluates triggers and sends notifications for servers, network devices and services. It is not a distributed tracing or application performance monitoring backend. If your New Relic agents report transactions, service maps, slow database calls or code-level stack traces, none of that has a direct equivalent in Zabbix. Before you start, list every New Relic APM view your engineers use weekly, because those views will disappear with the migration unless you rebuild them elsewhere.
Treat APM as a separate track rather than a Zabbix project. Instrument the services with OpenTelemetry SDKs or the Collector, then send traces to Jaeger, or metrics and traces to a Grafana stack backed by Prometheus. This keeps application telemetry on its own pipeline, with its own owners, retention and access rules. Zabbix can still hold the host-level signals underneath those services, such as CPU, memory, disk and database process health. Decide early which team owns each track, and who answers when a service is slow but its hosts look healthy.
Confirm the integration scope against the Zabbix documentation for the version you will run, since feature coverage differs between releases and the cloud-native and application integrations change over time. Ask your Zabbix support provider, if you buy a subscription, which integrations and templates are supported for your stack. Then test the exact signals your on-call engineers rely on, not a sample of them. Any gap you find should be written into the migration plan as an accepted risk or a named replacement, so it is not discovered during an incident.
Which data, configurations and integrations to move or rebuild
Moving from New Relic infrastructure monitoring to Zabbix is mostly a rebuild, not an import. Each category below needs its own inventory, owner and cutover decision, because host data, alert logic, notifications, access and dashboards do not move in the same way.
Host inventory and item definitions
Start by listing every host New Relic currently reports on, with its role, operating system, owner and the metrics you actually alert on. In Zabbix, each host needs an agent or an SNMP interface, and each metric becomes an item tied to a template. Many hosts share the same items, so group them by role before writing templates. Expect some metrics to have no direct Zabbix equivalent and decide early whether to drop them or build a custom item.
Triggers and alert thresholds
New Relic alert conditions and their thresholds rarely translate one to one into Zabbix triggers. Review each condition, record its window, threshold and recovery behavior, then rewrite it as a trigger expression in the template that owns the host class. Treat this as a rule-by-rule review with the team that receives the pages, since silent changes in threshold logic are the most common source of missed incidents during cutover.
Notification channels and escalation
List every destination that receives New Relic notifications, including email lists, chat channels, paging integrations and webhooks. In Zabbix, these become media types, actions and user media entries that you must configure and test again. Confirm which channels remain in use, who owns each one and how escalation changes when a trigger fires for a host that is still reporting to New Relic during the parallel run.
User accounts and authentication
Inventory the New Relic users, their roles and any single sign-on settings, then map them to Zabbix user groups and permissions. Zabbix supports several authentication methods, so confirm which one your identity provider requires before creating accounts by hand. Remove stale accounts during the move rather than copying them across, and document who approves each new Zabbix user.
Dashboards and exported history
New Relic dashboards are built from NRQL queries that Zabbix does not read, so each one must be redrawn with Zabbix dashboards or Grafana panels. Historical data is a separate exercise: New Relic data exports follow their own documented export paths, which depend on your plan and account settings. Confirm the export options, formats and retention in your own account before you decide how much history the new monitoring needs.
Templates as the unit of rebuild
Most configuration should be rebuilt as Zabbix templates rather than imported host by host. A template bundles items, triggers, discovery rules and graphs for a host class, and hosts inherit it when linked. Build templates for your most common host types first, test them on a small set of hosts, then link the remaining hosts in groups. Keep template changes under version control so that reviewers can see what changed.
How to sequence the migration from inventory to decommission
This sequence moves host, network and server monitoring from New Relic infrastructure agents to Zabbix in controlled stages, so each stage produces evidence before the next one starts. Notification routing moves last, and New Relic billing ends only after both systems have run side by side and the team has signed off.
Inventory hosts, checks and alert conditions
Export the list of hosts with New Relic infrastructure agents, the integrations and checks running on them, and every alert condition and notification channel attached to them. Group hosts by role, owner and business service, and mark which ones carry data your team relies on for capacity planning or audit. Your operations lead and the owners of each service should review the list. The output is a signed inventory that maps each New Relic alert to a planned Zabbix item, trigger or template, with unmapped conditions flagged for a decision.
Build and validate the Zabbix template set
Install a Zabbix server with its database and web interface in your environment, then deploy proxies where hosts sit in separate networks. Choose or build templates for the operating systems and network devices in the inventory, and recreate each mapped trigger with the same thresholds and severities. Test templates against a few non-critical hosts and confirm that items return data and triggers fire as expected. The output is a validated template set with a short test record for each template family.
Run a pilot group with Zabbix agents
Install Zabbix agents on a small pilot group of hosts that represent the main operating systems and network roles in your inventory. Keep New Relic agents running on the same hosts so you can compare values. Confirm that host registration, item collection, discovery rules and notification routes behave correctly from the pilot hosts. The output is a pilot report listing each host, the items collected, any gaps against the New Relic baseline and the fixes applied to templates or proxies.
Parallel run with both systems alerting
Extend Zabbix agents and templates to the full inventory in waves, and keep New Relic alerting active during the run. Route Zabbix notifications to a test channel first, then compare each alert from both systems for the same event. Review false positives, missed events and duplicate pages with the on-call team. Ask your team to agree in writing how long the parallel period lasts and what counts as a passing comparison. The output is a parallel-run sign-off that lists the alert pairs compared and the decisions taken on each mismatch.
Cut over notification routing to Zabbix
Move production notification routing from New Relic channels to Zabbix actions, starting with the lowest-risk services and ending with the most critical ones. Update escalation paths, on-call rotations and any ticketing or chat integrations that receive alerts. Disable the matching New Relic notification policies once each service has been validated, and keep a rollback path documented until the service owner accepts the change. The output is a cutover log that records each service, the date of its routing change, the owner who approved it and the rollback steps.
Decommission New Relic agents and confirm billing
Remove New Relic infrastructure agents from each host once its alerting has moved, and uninstall any integrations that no longer feed a dashboard. Export or archive the dashboards and alert definitions your auditors or service owners still need, using your own records because they are your evidence. Review your New Relic subscription and usage with your account team before the next billing cycle so you know which charges stop and which remain. The output is an agent removal record per host and a written confirmation of the billing position from New Relic.
How Zabbix server, proxies and database fit your environment
The Zabbix deployment has three layers you need to size and place before you move a single host: the Zabbix server that evaluates items, triggers and actions, the database that holds configuration and history, and the proxies that collect data close to remote networks. Decide early which of your sites need a proxy. Each proxy takes on collection for a set of hosts, so a proxy placed in a segment that New Relic agents currently reach directly is a change you must test with the firewall and credential owners, not just the Zabbix team.
For the server layer, Zabbix supports a 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 that ranges from 10 seconds to 15 minutes. Choose that delay with your monitoring team, because a short value can trigger failovers during a brief database slowdown. From Zabbix 7.0 onward, proxy groups automatically redistribute monitored hosts between proxies when one goes offline, which covers proxy failure without manual reassignment. Confirm in your own test environment how quickly hosts move and whether your alert timing tolerates the gap.
For the database, 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 the TimescaleDB extension 2.13 to 2.29 as an option. SQLite is available for proxies only. Check the requirements page for the exact version you will deploy, because the supported range is tied to the Zabbix release you select. Plan the database as the shared dependency of the whole cluster: its storage growth, backup schedule and restore tests determine how long your history survives, so agree those settings before you size the servers.
How the migration differs by estate size and starting point
A single data centre with agent-based hosts is usually the shortest path. The Zabbix server, its database and the web frontend sit in one place, and most of the effort goes into installing Zabbix agents, linking existing New Relic host inventory to Zabbix templates and rebuilding the alert paths your on-call staff already use. Because there is no proxy layer, the first pilot can run against a small group of hosts while New Relic keeps reporting for everything else.
- Inventory first: export the list of hosts, tags and current alert conditions from New Relic so you know which hosts need a Zabbix agent and which checks they need.
- Template choice: map each host class to a standard Zabbix template, then add custom items only where New Relic was collecting something unusual.
- Pilot group: move one host class, such as Linux database servers, and run both tools side by side until the alerts match.
- Notifications last: rebuild triggers, then media types and escalation actions, so you do not page people from two systems during the pilot.
- Database sizing: check the supported database and TimescaleDB versions for your Zabbix release before you pick the backend.
Before you commit, confirm with your own team how many hosts each template will cover and whether your change process requires a formal test window.
A multi-site estate needs a design decision that a single site does not. Zabbix proxies collect data at each location and forward it to the central server, which keeps monitoring running when a WAN link is slow or down. Proxy placement, firewall rules between sites and the failover design become the first workstream, and they usually take longer than the template work. Zabbix 7.0 and later support proxy groups, which can move hosts between proxies automatically when one goes offline.
- Proxy placement: decide which sites need a local proxy and which can report directly to the central server over an acceptable link.
- Proxy groups: where a site must keep monitoring during a proxy outage, plan a proxy group rather than a single proxy.
- Firewall paths: document the ports and directions each proxy needs to reach the server and the monitored hosts.
- Central database: the server and its database are a shared dependency, so plan high availability for them before you move more sites.
- Staged rollout: cut over one site at a time, starting with the site that has the least business impact.
Check with your network and security teams which sites can host a proxy, and confirm the exact proxy group behavior in the Zabbix documentation for your release.
A network-heavy estate relies on SNMP for switches, routers, firewalls and load balancers, and that usually changes the migration more than the server work does. Zabbix discovers and polls network devices through SNMP and vendor templates, but each device family may need its own template, community or SNMPv3 credential, and polling interval. Hardware inventories and interface naming often need cleanup before the New Relic dashboards can be recreated faithfully.
- Device inventory: list every network device, its SNMP version, and which New Relic integration or custom query currently collects its data.
- Credential handling: move SNMP community strings or SNMPv3 users into a controlled process rather than copying them into shared spreadsheets.
- Discovery rules: use Zabbix low-level discovery for interfaces and ports so new ports appear without manual work.
- Polling load: test polling intervals on a few devices first, since aggressive polling across a large switch fabric can strain both devices and the server.
- Trap handling: decide which SNMP traps must still produce alerts and how they map to Zabbix triggers.
Ask your network team which device models are in scope and whether vendor MIBs are already loaded, because these details decide how much of the work is template building rather than configuration.
A team that also uses New Relic APM has a split estate. Zabbix covers host, network and infrastructure monitoring well, but it does not provide the application-level tracing, transaction breakdowns and code-level profiling that New Relic APM offers. The practical question is whether you move only infrastructure work to Zabbix, keep New Relic APM running, and connect the two during a transition. Many teams keep APM on its current platform while moving the host layer, so that application owners are not asked to change their tools at the same time as operations staff.
- Scope split: write down which alerts and dashboards are infrastructure-only and which depend on APM data, such as response time or error rate.
- Shared alerts: where an infrastructure alert and an APM alert point to the same incident, plan how the two notifications will be correlated during the transition.
- Agent overlap: check whether New Relic infrastructure agents and APM agents are installed together on the same hosts, and remove only the infrastructure agent once Zabbix covers that host.
- Ownership: confirm which team owns each dashboard after the split.
- APM decision: treat the APM migration as a separate project with its own scope, rather than folding it into the Zabbix work.
Confirm with your application owners which APM capabilities they rely on today, since Zabbix will not replace them.
What drives the cost and duration of moving to Zabbix
This table lists the main drivers of effort and cost when moving infrastructure monitoring from New Relic to Zabbix, with the reason each one matters and how to keep it down. Zabbix has no license fee, so most of the spend is one-time migration work and recurring operations staff time, with support subscriptions as an optional line. Read each row as a lever you can plan around before asking for a quote.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of hosts, devices and network gear | Every host needs an agent or an SNMP or other interface configured, so inventory size sets most of the rebuild work. Hosts you never mapped in New Relic often surface late. | Export your New Relic host list, remove retired systems first, and group the remainder by role so templates can be applied in batches. |
| Template rebuilding | New Relic dashboards and alert conditions do not convert to Zabbix templates automatically. Each recurring host type needs a Zabbix template with items, triggers and graphs rebuilt by hand. | Start from the official Zabbix templates for your OS and network platforms, then add only the custom items your team actually uses. Version templates in Git. |
| Custom checks and scripts | Metrics collected by custom New Relic integrations or in-house scripts need Zabbix user parameters, external checks or HTTP agent items, each of which must be tested. | Inventory custom checks first and retire those with no owner. Prefer native item types over scripts where the Zabbix template offers one. |
| Triggers, thresholds and notifications | Alert logic built in New Relic (NRQL conditions, baselines, incident grouping) must be redesigned as Zabbix triggers, dependencies and actions. Noisy thresholds are the usual cause of rework. | Document each existing alert with its owner and purpose, drop duplicates, and use trigger dependencies to suppress child alerts during a parent outage. |
| Escalation and on-call routing | Media types, user groups, escalation steps and maintenance periods all have to match your current on-call process, and mistakes here can silence real incidents. | Test each escalation path with a controlled trigger during parallel running. Keep the on-call tool decision separate unless you are also replacing it. |
| High availability and proxy design | A single server or proxy is simpler to build, but Zabbix server HA and proxy groups add database, failover and network design work. The design depends on how many sites you monitor. | Decide the topology before building templates. Start with one server and one database for the pilot, and add HA nodes or proxy groups once the host count and sites are known. |
| Database choice and sizing | Zabbix 7.4 supports MySQL or Percona, MariaDB, PostgreSQL and TimescaleDB within stated version ranges, and the choice affects tuning, backup and history retention effort. Confirm the supported versions in the Zabbix requirements page. | Use a database your team already operates and backs up. Set history and trend retention deliberately, since they drive storage growth. |
| Staff skills | Zabbix administration, SQL tuning, template authoring and Linux operations are in-house costs. Teams without these skills usually spend more time on setup and upgrades. | Name an owner for the Zabbix server, budget training time, and ask any implementation partner to hand over templates, runbooks and upgrade notes. |
| Zabbix license and support subscription | The software has no license fee and no device or feature limits, so the license line is zero. Paid technical support is optional and comes in Silver, Gold, Platinum, Enterprise and Global tiers, with response times from 1 day (Silver, 8x5) to 1 hour (Global, 24x7), per the Zabbix support page. | Treat support as a recurring option, not a requirement. Compare the tier response times with your own incident process and ask vendors to price it separately from the migration scope. |
| One-time versus recurring work | One-time work covers inventory, template and trigger rebuilding, notification testing, parallel running and cutover. Recurring work covers patching, Zabbix upgrades within its release cycle, backups, capacity review and on-call maintenance. | Ask for the migration quote split into one-time and annual recurring lines, so the upgrade and operations effort is visible before you commit. |
What usually goes wrong when teams move infrastructure monitoring to Zabbix
Most failed infrastructure monitoring migrations fail in the handover, not in the install. The cards below cover the gaps that appear when New Relic triggers, notifications, dashboards and sizing are rebuilt in Zabbix, and the checks that catch them before cutover.
Alert gaps from untranslated triggers
New Relic alert conditions use thresholds, aggregation windows and baselines that do not map one to one onto Zabbix trigger expressions. Teams often copy the threshold and miss the window, so a brief spike fires in one tool and never in the other. Export every New Relic condition into a spreadsheet with its query, threshold, duration and recovery rule, then write a matching Zabbix trigger for each row. Compare alert counts over a shared test period before you disable the old conditions.
Duplicated or silent notifications in parallel run
Running both tools against the same hosts is the safest cutover pattern, but it creates two alert streams. On-call staff either get paged twice or, after someone mutes one channel, get no pages at all. Assign one owner per notification path, tag each Zabbix action with its target team, and keep New Relic channels in a muted state with a documented re-enable step. Test the Zabbix media types with a scheduled failure before any production switch.
Undocumented New Relic dashboards
Dashboards built over time often hold the only record of which hosts matter, which error rates are expected and which graphs executives read. Those dashboards rarely appear in any runbook. Inventory every dashboard and the owner who uses it before migration, mark each widget as needed, replaced by a Zabbix graph, or retired, and rebuild only the ones with a named consumer. Agree on the retirement list with the teams that use them.
Under-sized database and proxies
A Zabbix server writes every item value to its database, so a database sized for a pilot of a few dozen hosts can fail under full inventory. Monitored hosts also depend on proxies, and a proxy placed in the wrong network segment can leave whole sites unmonitored. Check the supported MySQL, MariaDB, PostgreSQL or TimescaleDB versions in the requirements page, plan storage for history retention, and use proxy groups for failover between proxies. Load-test with the real item count before cutover.
Licensing confusion across GPL and AGPL
Zabbix versions up to 6.4 are GPL-2.0, while Zabbix 7.0 and later are AGPL-3.0. Teams that modify Zabbix, embed it in a product or offer it to users over a network need to know which license applies to the version they run. Record the exact version in your asset register, have legal review the AGPL obligations for any modifications, and confirm that a support subscription does not change the license terms of the code you deploy.
Lost APM coverage after cutover
Zabbix monitors hosts, services, network devices and their metrics. It does not trace requests through application code or show service-level transaction timings the way New Relic APM does. Teams that switch off New Relic agents without a replacement lose traces and error context. Before cutover, list which applications depend on APM, decide whether they keep New Relic, move to OpenTelemetry with Jaeger, or accept reduced visibility, and document that decision.
Questions teams ask before moving New Relic infrastructure monitoring to Zabbix
How much effort does moving New Relic infrastructure monitoring to Zabbix take?
The effort depends mainly on how many hosts, network devices and custom alerts you run, and on how many of your New Relic alert conditions and notification channels must be rebuilt by hand. Zabbix has no automated converter from New Relic, so each trigger, dashboard and notification route is recreated. Most of the work is in three places: installing agents and templates on hosts, mapping alert thresholds to Zabbix triggers, and re-testing escalation paths. Teams with a small, standard estate usually find the rebuild manageable, while teams with many custom NRQL alerts should expect the largest share of effort in review and testing. Ask any implementation partner to size the work from an inventory of hosts, alerts and channels.
How long does a Zabbix migration from New Relic take?
No supplied fact gives a duration for this migration, so treat any number you hear as an estimate that needs your own inventory behind it. The timeline is driven by the size of the host estate, the number of alerts to rebuild, the number of teams that must sign off on new notifications, and whether you run both monitoring systems in parallel before cutover. Running Zabbix alongside New Relic for a period is the safest approach because it lets you compare alerts before you switch off the old ones. Ask for a phased plan with written milestones and confirm whether that plan includes a parallel run.
What does our internal team need to provide for the move?
Your team needs to supply an inventory of hosts, network devices and cloud resources, a list of current New Relic alert conditions with their owners, and the notification routes used by on-call staff. You also need access to the systems being monitored so agents or SNMP and proxy settings can be configured, and someone who can approve changes to firewall rules between monitored networks and the Zabbix server. Network and security teams should confirm the ports and paths used by Zabbix agents and proxies. Without these inputs, any quote or plan will rest on assumptions that tend to change during the project.
Can we migrate from New Relic to Zabbix without a partner?
Yes, a team with Linux and network administration skills can build a Zabbix deployment internally, using the official documentation and its templates. The harder parts are design decisions that affect every later change: database choice, proxy layout, high availability, template customization and alert design. Many teams keep the first deployment in-house and bring in outside help only for the design review or the high availability setup. If you choose a partner, DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, typically under a fixed-scope agreement with deliverables and timelines written down before work starts.
How does Zabbix licensing differ between versions?
The license depends on the version you deploy. Zabbix states that from Zabbix 7.0 onward the software is released under the GNU Affero General Public License version 3, while all versions up to 6.4 were released under the GNU General Public License version 2. Zabbix also states that its open source software has no license fee, no device limits and no feature gates. If your legal or procurement team must approve the license, confirm which version you will install and review the AGPL terms with counsel, particularly if you modify Zabbix and offer it to users over a network. Plan your version choice alongside the support lifecycle, covered in the next question.
Does Zabbix cover APM the way New Relic does?
Zabbix covers infrastructure, server, network and host monitoring well, but it is not a replacement for New Relic APM. New Relic APM traces transactions through application code, shows service maps and links errors to code paths, and those capabilities are not part of Zabbix's host monitoring model. If your applications depend on New Relic APM, keep those agents or move them to OpenTelemetry, and consider a tracing backend such as Jaeger or an OpenTelemetry-native platform for that part of your estate. Confirm this coverage gap with your application owners before you decommission any New Relic subscription, because removing APM and infrastructure monitoring at the same time changes what engineers can see during incidents.
What does a Zabbix support subscription add?
A Zabbix support subscription adds vendor technical support on top of the free open source software, which Zabbix says has no license fee. Zabbix sells support in Silver, Gold, Platinum, Enterprise and Global tiers. Silver offers 8x5 support with a 1 day response, Gold offers 8x5 support with a 4 hour response, and Platinum, Enterprise and Global offer 24x7 support with 2 hour, 1.5 hour and 1 hour responses respectively. Cost depends on the tier, your scope and your contract term, so ask Zabbix for a written quote. Some organizations prefer to rely on internal staff or a partner for daily operations and buy support only for high-severity issues. Confirm response terms in the contract itself.
How DeployOpen scopes and runs a Zabbix migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including Zabbix. For teams moving host, server and network monitoring off New Relic, we start from an inventory of what is monitored today and agree the scope in writing before any work begins.
How we scope
- We inventory the hosts, network devices and alert policies currently sending data to New Relic.
- The written scope lists which hosts, templates, triggers and notification channels move to Zabbix.
- We agree in writing what stays out of scope, such as APM agents and tracing, which Zabbix does not replace.
How we build
- We deploy the Zabbix server, database, web frontend and any proxies inside your cloud accounts or data centers.
- We build or adapt templates for each host class and rebuild triggers and notifications from the agreed inventory.
- We test alert paths end to end and run Zabbix and New Relic in parallel until the agreed cutover criteria are met.
How we hand over
- We document the server topology, proxy layout, template ownership and trigger logic in a handover pack.
- We record which New Relic alert conditions map to which Zabbix triggers so your team can audit the change.
- We train your operators on daily checks, adding hosts and changing notifications before we close the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades between Zabbix releases are planned against the vendor's life cycle and tested in a staging environment first.
- We confirm with your team and the vendor which support tier, if any, you need for Zabbix before the engagement starts.
