Migrate from Dynatrace to Zabbix

How to migrate from Dynatrace to Zabbix without losing host alerting

A Dynatrace renewal or a DPS commitment term is usually what starts this move, and the decision that matters first is scope. Zabbix replaces OneAgent host metrics and problem detection for infrastructure, not Dynatrace APM or real user monitoring. That means the migration is mostly a rebuild of host monitoring: Zabbix agents on each server, templates that collect the metrics your teams rely on, and triggers that raise the same problems Dynatrace raises today. Application tracing and front-end monitoring need a separate plan, covered in the sibling pages on OpenTelemetry and session replay. The work is normally done by the platform or infrastructure team that already owns the Dynatrace tenant, with help from whoever administers Zabbix. Start by exporting your current problem list and alerting profiles, then sort hosts into groups by owner and criticality. Confirm the Zabbix version you will run before writing templates, since the Zabbix life cycle and release policy sets full and limited support dates per release. Plan for a period where both systems alert on the same hosts, and make sure on-call routing is changed in one step, not per host, to avoid duplicate pages or silent gaps. The main risk is alert coverage, not data. OneAgent detects many things automatically, while Zabbix only watches what a template or trigger defines, so each Dynatrace problem type needs a named Zabbix trigger or an explicit decision to drop it. Confirm which templates your vendor or partner will maintain, how proxies will be placed for remote networks, and how Zabbix user access will be set up for the teams that act on alerts. Review the Zabbix technical support tiers now if you want contracted response times, and treat effort estimates from anyone, including us, as outputs of a written, host-by-host inventory.

Which Dynatrace host capabilities map to Zabbix and which do not

This table maps the host-level capabilities you rely on in Dynatrace OneAgent to their Zabbix equivalents, and marks each as clean, needs rework or gap. Read the status column first, then the notes, to see where you will rebuild work by hand. The main takeaway is that Zabbix covers host and infrastructure monitoring well, while Dynatrace APM tracing and real user monitoring need separate open-source tools.

Dynatrace capability	Zabbix equivalent	Status	What to confirm or rebuild
OneAgent host metrics (CPU, memory, disk, network)	Zabbix agent or agent 2 with standard OS templates	Clean	Confirm template coverage for your OS versions and the item intervals you need.
Process and service views	Process items and discovery rules in templates	Needs rework	Recreate each process you watch as an explicit item or discovery rule, since OneAgent discovers them automatically.
Automatic problem detection	Triggers with severity, dependencies and maintenance periods	Needs rework	Rebuild baselines and anomaly logic as triggers. Dynatrace AI root-cause analysis has no direct equivalent.
Network and cloud discovery	Network discovery and low-level discovery rules	Needs rework	Discovery needs configured ranges and rules. Confirm cloud API coverage for your providers.
Dashboards	Zabbix frontend dashboards and maps	Needs rework	Rebuild dashboards per team. Grafana can read Zabbix data if your team already uses it.
Alerting and notifications	Actions, media types and user notifications	Clean	Map existing escalation paths to Zabbix actions and confirm delivery channels.
Distributed deployment	Zabbix proxies and proxy groups	Clean	Proxy groups redistribute hosts when a proxy goes offline. Plan proxy placement for each network zone.
Server high availability	Native server HA cluster on a shared database	Needs rework	Failover depends on a configurable delay and a shared database you must size and back up yourself.
User access and authentication	Zabbix user roles, user groups and external authentication	Needs rework	Map Dynatrace permissions to Zabbix roles and confirm the external authentication method you need.
Dynatrace APM tracing and real user monitoring	Not covered by Zabbix	Gap	Use OpenTelemetry with Jaeger or SigNoz for traces, and OpenReplay for real user monitoring.

What Zabbix does not cover from Dynatrace APM and real user monitoring

Zabbix covers the host, network and service layer well, but it does not replace the application-level capabilities that many Dynatrace customers rely on. Zabbix collects data through its own agents, through proxies and through templates that define items, triggers and discovery rules for hosts, network devices and services. It does not provide Dynatrace-style automatic APM tracing that maps requests across services, and it does not provide real user monitoring of browser or mobile sessions. Before the cutover, list which Dynatrace features your teams actually use, such as service flow, code-level traces, database call analysis, and browser session data, and mark each one as covered by Zabbix, covered by another tool or not yet covered.

For the application and user layer, the pairings to plan are separate. Teams that need distributed traces should instrument services with OpenTelemetry and choose a trace backend, such as Jaeger or SigNoz, as described on the sibling pages for those tools. Teams that need session replay, browser errors or the link between a user session and a backend trace should review the sibling page on OpenReplay. Dynatrace itself notes that OpenTelemetry has no stable real user monitoring specification, so expect to adopt a second tool for that area rather than expect one OpenTelemetry pipeline to supply it. Assign an owner for each gap and decide whether it is retired, moved or kept on Dynatrace until the subscription term allows an exit.

Confirm every Zabbix capability you plan to rely on against the current Zabbix documentation for your target version, since template coverage, discovery behavior and supported database versions change between releases. Ask your Zabbix support provider, if you buy a support tier, to confirm how the features you need behave in the version you deploy. Document the gaps in your runbook so that operations staff know which alerts come from Zabbix and which must be checked in the APM tool.

What to export from Dynatrace and what to rebuild in Zabbix

Dynatrace holds configuration, inventory and history in different forms, and each one moves differently. Some items can be exported as files or pulled through APIs and then recreated in Zabbix, while collected telemetry history mostly stays behind and needs a deliberate retention decision. The cards below separate what you can carry forward from what you will rebuild and what you will let go.

Configuration as Monaco files

Dynatrace can download much of its configuration as Monaco configuration-as-code files, covering settings, classic configuration APIs, automations, documents and SLOs. For this migration the useful output is a reference list of alerting profiles, tags, maintenance windows and host groups, not a file you can import into Zabbix. Treat the export as documentation of intent, then map each item by hand to Zabbix host groups, templates, actions and maintenance periods. Confirm the export scope against your Dynatrace version before you rely on it.

API access to metrics and entities

The Dynatrace API returns entity records such as hosts, host groups and process groups, along with metric time series. These records are the most reliable source for your host inventory during cutover. Script an extract that lists monitored hosts, their names, IP addresses, operating systems and tags, then compare it against the Zabbix host list. Metric series can be queried for baselines, but they do not import into Zabbix, so use them to set trigger thresholds and check that the values are comparable.

Host inventory and tags

Dynatrace tags and host groups carry the ownership and environment labels that your alerts and dashboards depend on. In Zabbix, these become host groups, host tags and template assignments, so define the taxonomy before you import hosts. Decide which Dynatrace tags map to Zabbix tags and which become host groups, because Zabbix uses host groups for permissions and tags for filtering. Script host creation through the Zabbix API, and run a reconciliation report that lists hosts present in one system but missing in the other.

Alerting and notification routes

Dynatrace problem detection is automatic and does not rely on rules you wrote, so there is little to export directly. Rebuild the important conditions as Zabbix triggers, with severities, recovery expressions and dependencies so that one failed network path does not produce a flood of host alerts. Recreate notification routes as Zabbix actions and media types, and test each escalation path with a controlled event. Expect this rebuild to be the largest manual task, because Zabbix does not infer problems the way Dynatrace does.

Dashboards and reports

Dynatrace dashboards and documents are recreated in Zabbix as dashboards, maps and reports, or in Grafana when you need richer visualization over Zabbix data. Start from the questions each dashboard answers rather than copying its layout, since many Dynatrace views depend on automatic entity relationships that Zabbix does not reproduce. Keep a short list of the executive and on-call views that must exist on day one, and check whether each one can be built from items you actually collect.

Collected telemetry history

Historical metrics, problems and logs held in Dynatrace are generally not exported in a form that Zabbix can ingest, so plan on a split retention model. Keep Dynatrace read access until audit, capacity and incident review needs are covered, and record which periods you must retain for compliance. Confirm the retention limits and export options with Dynatrace for your subscription, because they determine how much history you can move and how much stays in the platform until the commitment ends.

The migration sequence from inventory to decommission

This sequence moves host and infrastructure monitoring from Dynatrace OneAgent to a self-hosted Zabbix deployment in controlled stages, so each host group is verified before alert routing changes and Dynatrace access is retired.

Inventory hosts, agents and problem rules
The operations team lists every host and host group that OneAgent covers, the Dynatrace problem detection settings and alerting profiles, and the notification channels tied to each one. Include hosts that run OneAgent only for APM, because Zabbix does not replicate that coverage. The output is a written inventory with one row per host group, its owner, its alert destinations and a column marking which signals Zabbix can replace with agent items, templates or triggers. Confirm the inventory with the owners before moving on.
Pilot Zabbix server, database and proxies
The platform team installs a Zabbix server, a database and one or more proxies in a test environment, then connects a small host group selected from the inventory. Choose the database from the supported set for Zabbix 7.4: MySQL or Percona 8.0.30 to 9.7, MariaDB 10.5 to 12.3, or PostgreSQL 13 to 18, optionally with the TimescaleDB extension 2.13 to 2.29. Decide early whether you need the native high availability cluster, where several server nodes share one database and failover occurs after a configurable delay between 10 seconds and 15 minutes, and whether proxy groups should balance hosts across proxies. The step is done when the pilot hosts report items, triggers fire on a controlled test condition and the notification path works.
Run Zabbix in parallel with OneAgent
Keep OneAgent running on the pilot and then the wider estate while Zabbix collects the same host metrics. For each host group, compare Zabbix trigger outcomes with the Dynatrace problems raised for the same period, and record gaps such as missing process checks, log-based detections or dependency maps. Adjust templates and trigger thresholds until the two views agree on the conditions that matter to the owners. Alerts stay routed to the current Dynatrace channels during this stage. Done means the owners have signed off the parity log for each group.
Cut over host group by host group
Move one host group at a time by switching its alert routing from Dynatrace to Zabbix, starting with lower-risk groups and leaving production-critical services for later. Confirm that on-call staff receive the Zabbix notifications, that escalation and acknowledgement work, and that any runbooks reference the new problem names. Keep the Dynatrace routing ready to reverse until the group has run cleanly through its normal operating cycle. The output is a cutover record per group showing the date, the owner who approved it and the rollback status.
Decommission OneAgent and retire Dynatrace access
After every host group has run on Zabbix and the owners have accepted the result, remove OneAgent from the hosts and disable Dynatrace alerting profiles that no longer receive traffic. Export the configuration and any history you need to keep before the subscription or Managed deployment is reduced, because collected telemetry history mostly does not transfer to Zabbix. Revoke API tokens and user accounts, then record the final state. The step is complete when no host reports to Dynatrace and the retained exports are stored under your data retention policy.

How the move differs by estate size and starting point

A single data center is usually the simplest starting point. Most hosts can reach one Zabbix server directly, so a proxy is often optional and is added mainly to reduce load or to isolate a network segment. The main design question is availability of the monitoring itself, because a single server and database become a single point of failure for alerting.

Direct polling first: Start with the Zabbix server and agents on hosts that already have reachable network paths, and add proxies only where a segment needs one.
Database sizing: Plan the PostgreSQL or MySQL backend for the history volume that OneAgent metrics currently produce, and confirm the supported versions in the Zabbix requirements.
High availability: Zabbix server has a native high availability cluster in which several nodes share one database and one node is active, with failover after a configurable delay of 10 seconds to 15 minutes. Decide whether that second server node is needed before cutover.
Trigger rebuild: Dynatrace problem detection will need to be recreated as Zabbix triggers and actions, which is the largest manual effort in a flat estate.
Support decision: Ask whether a paid Zabbix support tier is needed for on-call coverage, since the software itself carries no license fee.

Confirm with your team which Dynatrace alerting profiles map to which Zabbix hosts before you turn off any OneAgent.

How to run Dynatrace and Zabbix side by side during the DPS term

Run both paths in parallel for host monitoring, and treat OneAgent alerts stay live until Zabbix alerting has been validated against real incidents. Start by mapping every host that OneAgent covers to a Zabbix host with an agent and a matching template, then compare the two systems over a full business cycle. For each Dynatrace problem that opens, confirm that a Zabbix trigger fired for the same condition, and for each Zabbix trigger that fires, check whether Dynatrace saw it. Record mismatches in both directions: missing triggers, thresholds that fire too early or too late, and Dynatrace problems that merge several symptoms into one event. Do not switch off a OneAgent alert until the mismatch log is empty for the agreed validation window, and make that window and the sign-off owner explicit in the migration plan.

The DPS commitment term sets the calendar, but it should not set the quality bar. Dynatrace Platform Subscription is consumption-based against an agreement of typically one to three years with a minimum annual commitment, so the cost of keeping OneAgent running during the overlap depends on the terms you signed. Ask your Dynatrace account team which consumption continues to accrue for host monitoring after you stop relying on it, and whether any part of the commitment can be reallocated to other capabilities. Pick the cutover date from the validation results, then confirm the commitment end date separately so you know whether a parallel run extends into a renewal. Zabbix itself has no license fee, so the overlap cost is the Dynatrace consumption and the staff time to maintain two alerting systems.

Avoid duplicate paging by giving each alert path a single owner and a single destination during the overlap. Route Zabbix notifications to a test channel or to a shadow on-call group, and keep the production paging route on Dynatrace until validation passes. When you switch, move one service or one host group at a time, disable the matching OneAgent problem notification first, and then enable the Zabbix action for the same group. Review Zabbix action conditions, escalation steps and maintenance periods so that a host in maintenance does not page twice. If you use a separate on-call tool, confirm that deduplication or correlation is configured on the receiving side, since neither system will know about the other's events by default.

What drives the cost and duration of a Zabbix migration

This table lists the components that set the cost and effort of moving Dynatrace host monitoring to self-hosted Zabbix. Read each row as a question to answer in your own environment before requesting a quote, since the largest variables are host count, custom problem rules and how much alerting depends on Dynatrace-specific workflows.

Cost driver	What changes the cost or effort	What to ask for in a written quote
Host count and variety	Every OneAgent host needs a Zabbix agent or an agentless check, and mixed Linux, Windows, network and cloud estates each need different templates. More hosts and more platform types increase configuration and testing time.	A host inventory by OS, role and location, with the number of hosts assigned to each migration wave.
Custom Dynatrace problem rules	Each custom alerting profile, anomaly detection setting or problem rule must be restated as a Zabbix trigger with thresholds, dependencies and recovery logic. Rules that Dynatrace derives automatically have no direct equivalent and must be designed by hand.	A rule-by-rule mapping from each Dynatrace problem rule to a planned Zabbix trigger, marking which rules are rebuilt, simplified or dropped.
Template and trigger rebuild	Standard templates from Zabbix cover common platforms, but tuned items, discovery rules, macros and trigger expressions for your environment are custom work. Review and tuning against real alert noise usually takes more than the first build.	The number of templates to build or adapt, the review cycle, and who signs off on alert behavior.
Zabbix server and database design	A single server or a high availability cluster sharing one database changes the design, licensing of nothing extra, and operating effort. Database choice from the supported list (MySQL or Percona, MariaDB, PostgreSQL with TimescaleDB) and the history retention setting drive storage and tuning work.	A sizing document covering expected values per second, history and trend retention, database engine, backup method and storage growth assumptions.
Proxy topology	Remote sites, cloud accounts and network segments often need Zabbix proxies. Proxy groups in Zabbix 7.0 and later can rebalance hosts when a proxy fails, which adds configuration work but reduces single points of failure.	The proxy layout by site, the proxy group design, and the network paths and firewall rules the proxies require.
High availability needs	Zabbix server high availability needs a shared database and several nodes, with a configurable failover delay. Teams that currently rely on Dynatrace managed resilience must decide how much redundancy to build and test.	A written availability target from your own operations team, the failover tests planned, and the infrastructure each node requires.
Skills and staff time	Migration needs people who know Zabbix configuration, templating, database administration and the operating system estate. Staff time is the largest recurring cost when internal teams carry the work, and the effort depends on existing Zabbix experience.	Named roles, expected hours by role for each phase, and whether knowledge transfer and runbooks are included.
Integrations with ticketing and paging	Dynatrace problem feeds into ITSM, on-call and chat tools must be rebuilt through Zabbix actions, media types and webhooks. Each integration needs its own mapping, testing and escalation rules.	A list of every downstream tool receiving alerts, the integration method for each, and the test cases agreed before cutover.
Training and support	Zabbix sells technical support subscriptions in Silver, Gold, Platinum, Enterprise and Global tiers, with response times from 8x5 with 1 day response to 24x7 with 1 hour response, according to Zabbix support page. Support is optional, but the tier you choose sets the recurring cost and the response you can rely on during cutover.	The support tier options with their response times, which tier is recommended for your hours and severity needs, and the training scope for administrators and on-call staff.

What usually goes wrong when moving host monitoring to Zabbix

Most problems in a Dynatrace to Zabbix move come from assumptions carried over from OneAgent: that hosts are found automatically, that alerts fire on the same conditions, and that the platform will be maintained without a named owner. Each risk below has a check you can run before the cutover and after handover.

Assuming discovery matches OneAgent

OneAgent detects processes, services and dependencies on each host without configuration. Zabbix relies on host records, low-level discovery rules and templates that you attach, so a host with no template or no agent check is simply invisible. Before cutover, reconcile the Dynatrace host list against Zabbix hosts and list every host that has no template assigned. Treat that list as the migration backlog.

Triggers that are noisy or missing

OneAgent problem detection uses baselines and correlated events. A Zabbix trigger fires only on the expression you write, so copied thresholds often flood the queue with alerts or miss slow degradation entirely. Rebuild each important Dynatrace problem as a named trigger with a recovery condition and an owner, then run both systems in parallel for a defined window and compare the alerts each one raises.

Losing APM and RUM coverage

Zabbix monitors hosts, services and network devices. It does not trace requests through application code or record real user sessions in the browser. Teams often discover this only after the Dynatrace subscription is gone. Write down which application traces, service maps and front-end metrics you rely on today, then assign each to a separate tool such as OpenTelemetry with Jaeger, or accept the gap in writing.

Database sizing and retention gaps

Zabbix stores history and trends in its database, and history volume grows with item count and polling frequency. Zabbix 7.4 supports MySQL or Percona, MariaDB, and PostgreSQL with the TimescaleDB extension, each within listed version ranges. Size the database from your real item count and polling interval, confirm retention settings for history and trends per item type, and check that the chosen version is on the supported list before you build the cluster.

Unclear ownership of templates after handover

Custom templates, macros and discovery rules become the monitoring baseline once the vendor team leaves. If no one owns them, changes happen by hand on production servers and drift from version control. Name an owner for each template group, store exported templates in Git with review, and document which macros hold site-specific values. Confirm who approves changes before handover, not after the first incident.

Version lifecycle drift

Zabbix standard releases are supported for 12 months, while LTS releases are supported for five years with three years of full support. A deployment left on a standard release or an aging LTS line can fall out of support faster than expected. Choose an LTS line on purpose, record its full and limited support end dates, and schedule upgrades ahead of the limited support deadline. Confirm the support tier you need with Zabbix before you commit.

Questions teams ask before moving from Dynatrace to Zabbix

Can Zabbix replace Dynatrace APM and real user monitoring?

Zabbix can replace the host and infrastructure monitoring part of Dynatrace, but it does not replace APM tracing or real user monitoring. Zabbix collects metrics through agents, templates, SNMP and similar methods, and it raises problems through triggers you define. It does not provide automatic code-level transaction tracing across services or browser session data. Those capabilities need separate tools, such as OpenTelemetry instrumentation feeding Jaeger, and a session replay product for front-end monitoring. Confirm the exact gap list against your own Dynatrace usage before you set the migration scope.

What drives the total effort and cost of a Zabbix migration?

The main cost drivers are the number of hosts, the number of OneAgent-based problem detection rules you rely on, how many dashboards and alerts must be rebuilt as triggers and templates, and the hardware or virtual machines that run the server, database and proxies. Zabbix itself has no license fee, no device limits and no feature gates. Recurring costs are infrastructure, database administration, patching and staff time, plus any support subscription you choose. Ask any partner for a quote that separates one-time work (inventory, template design, cutover) from recurring operations.

What does the client's team need to provide during a migration?

Expect to need a named owner for the monitoring inventory, staff who understand the applications behind each host, and someone who can approve alert thresholds and escalation paths. The team also needs access to the Dynatrace environment for configuration export, to the servers where agents will be installed, and to the network segments where proxies will sit. Database and Linux or Windows administration skills are needed to run the Zabbix server and its backend. Agree on these responsibilities in writing before work begins.

Can our own engineers migrate from Dynatrace to Zabbix without a partner?

A small, well-documented estate can often be moved in-house, provided the team has Zabbix experience and time for template design and testing. Teams usually struggle with three areas: rebuilding problem detection so it does not create alert storms, planning the proxy and high availability layout, and validating that every critical host has an equivalent check before OneAgent is removed. A fixed-scope engagement with DeployOpen covers implementation, customization, integration, hardening, backup and documentation, and its scope and timeline are agreed in writing before work starts. Compare the internal effort with that scope rather than assuming either path is cheaper.

Does the AGPLv3 license change in Zabbix 7.0 affect internal use?

Zabbix moved from GPL-2.0 to AGPL-3.0 starting with version 7.0, and versions up to 6.4 remain GPL-2.0. Running Zabbix internally for your own monitoring does not, by itself, require you to publish your modifications. The AGPL network clause matters if you modify Zabbix and make it available to users over a network, so have your legal team review any custom web interface or integration changes. Keep in mind that Zabbix sells support subscriptions, and the license does not change that. Confirm the interpretation with your legal counsel rather than relying on this summary.

Which Zabbix support tier should we consider?

Zabbix offers Silver, Gold, Platinum, Enterprise and Global support tiers. Silver provides 8x5 support with a 1 day response, Gold provides 8x5 support with a 4 hour response, and Platinum, Enterprise and Global provide 24x7 support with 2 hour, 1.5 hour and 1 hour responses. Choose the tier by how quickly you need a response for production incidents and whether your monitoring is business-critical around the clock. Support is separate from the free software, and it can be combined with an implementation partner for the migration itself. Check current terms with Zabbix before you commit.

How should we handle the Dynatrace DPS commitment during the move?

Dynatrace Platform Subscription usually runs for a term of one to three years with a minimum annual commitment, so the contract will keep running while you migrate. Plan the cutover around the commitment end date and ask your Dynatrace account team how unused commitment and renewal terms work before you reduce usage. Keep Dynatrace running in parallel until Zabbix triggers have been validated against real incidents. Reduce the Dynatrace footprint host by host once each has equivalent checks in Zabbix, and document the decision for procurement.

How long does a migration from Dynatrace to Zabbix take?

The duration depends on the number of hosts, the complexity of your detection rules, how many teams must sign off, and the proxy and high availability design. No general timeline is supplied for this migration, so ask any implementation partner for a schedule based on a written inventory. Build in time for a parallel run where Zabbix and Dynatrace both alert, so you can compare results. Timing should also fit your Dynatrace contract end date and any change freezes in your environment.

How DeployOpen scopes and runs a Dynatrace to Zabbix migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Zabbix inside your own infrastructure, whether that is your cloud accounts, data centers or an isolated network. The engagement starts with a written, fixed scope that names the host groups in scope, the Dynatrace-monitored estate being replaced, the Zabbix components to deploy (server, database, web interface, proxies and agents), and the deliverables and timelines both sides agree to before work begins. Because Zabbix is licensed under AGPLv3 from version 7.0 onward, the scope should also state which Zabbix release line is chosen and how it will be kept current, since standard releases are supported for 12 months and LTS releases for 5 years. Ask us to confirm which release line fits your upgrade calendar before any build starts.

Delivery covers the parts that make a Zabbix deployment dependable in production: a high availability server cluster sharing one database, proxy groups for load balancing, database sizing against the supported PostgreSQL or MySQL versions, backup and restore testing for the Zabbix database, hardening of the web interface and agent communication, and documentation of templates, triggers and escalation paths. Where an audit or internal assessment is expected, DeployOpen prepares monitoring evidence such as configuration exports, access control records, backup test results and change history. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ongoing support, upgrades and continuous testing can be covered by a retainer after go-live. To request a scoped quote, send your Dynatrace host count, the list of applications and services that need APM replaced or retained, your data residency requirements and your target cutover window.