Zabbix vs Checkmk: when each platform is the right choice
A team choosing agent-based monitoring for servers, networks and applications should pick Zabbix when it wants explicit, template-based control over what is monitored, no license fee for the software, and staff comfortable tuning a SQL database. Zabbix has no license fee, no device limits and no feature gates, and paid support is optional and sold separately. Pick Checkmk when the team wants rule-based configuration and automatic service discovery, a free Community edition for a small estate of about 100 hosts, or a paid Pro or Ultimate edition for distributed monitoring and mass rollouts. The two platforms reach the same goal by different routes, so the choice depends on how the team wants to maintain configuration over the next several years.
Four questions usually settle the decision. First, how many hosts will the platform watch within the next year, since the Community edition is positioned for small infrastructures of about 100 hosts. Second, how many sites or network segments need distributed polling, because Checkmk lists distributed monitoring as a Pro feature and Zabbix handles it through proxies and proxy groups. Third, who will own the configuration: if a small group of engineers will write and review templates, Zabbix's model fits well, while a larger team that wants discovery to propose checks may favor Checkmk's rules. Fourth, does the organization need a paid edition with vendor-backed features, or is paid support for an open-source core enough? Checkmk's commercial pricing is published per month, so confirm the current figures on its editions page before you budget.
Zabbix vs Checkmk by scenario: which fits your environment
This table maps common team and estate profiles to the platform that fits each one better, and names the condition under which that holds. Read each row against your host count, skills and feature requirements, since the same estate can favor different tools depending on which constraint is strongest. The main takeaway is that Zabbix wins on license cost and SQL and template depth, while Checkmk wins on discovery, rule-based configuration and built-in scale features in its paid editions.
| Scenario | Better fit and why | Where the other platform still fits |
|---|---|---|
| Small estate under about 100 hosts | Checkmk Community, because it is free, self-hosted and documented for small infrastructures up to about 100 hosts, with automatic service discovery out of the box. | Zabbix fits well if the team already knows its templates and does not need Checkmk's discovery workflow. |
| Large mixed estate with many sites | Zabbix, when the team is ready to run proxies or proxy groups and a database-backed HA server, since distributed polling is built into the open source product. | Checkmk Pro or Ultimate fits if distributed monitoring and the Micro Core are needed without designing the proxy layout yourself. Confirm the scale ceiling for your edition. |
| Team with strong SQL and template skills | Zabbix, because templates, item keys and direct database tuning give a team full control over data collection and history storage. | Checkmk suits teams that prefer rule-based configuration over writing and maintaining templates and database tuning. |
| Team that wants automatic service discovery | Checkmk, because its service discovery and rule-based configuration reduce manual template mapping, which its vendor page contrasts with Zabbix (vendor claims, verify on a pilot). | Zabbix with low-level discovery can cover many hosts well once templates are mature, so discovery alone is not decisive. |
| Strict no-paid-features requirement | Zabbix, because its open source software has no license fee, no device limits and no feature gates, and paid support is optional. | Checkmk Community is free, but distributed monitoring, push-mode agents and automatic registration sit in paid editions, so confirm each feature you depend on. |
| Team that needs push-mode agents or multi-tenancy | Checkmk Ultimate, because push-mode agents, automatic host registration and multi-tenancy are listed as Ultimate features in the vendor documentation. | Zabbix can meet some of these needs through its own design, but the team should verify agent mode and tenant isolation against its requirements. |
| Team that needs a long support window on a fixed release | Zabbix 7.0 LTS, which has full support until June 30, 2027 and limited support until June 30, 2029, according to the Zabbix life cycle policy. | Checkmk releases are tracked through its tags, so confirm the support window of the edition and version you plan to run. |
How Zabbix and Checkmk are built, and what that means for operations
Zabbix and Checkmk both monitor servers, networks and applications through agents, but they store configuration, run checks and scale across sites in different ways. The cards below cover the parts an operator installs, backs up and patches, and the points where the two platforms shift work between the database, the proxies and the monitoring core.
Zabbix server and its SQL database
The Zabbix server keeps configuration, history and trends in a relational database, which the operator must choose, size, tune and back up. Zabbix 7.4 supports MySQL, MariaDB or PostgreSQL, with TimescaleDB as an optional extension for PostgreSQL. Because the database holds all monitoring history, its sizing and tuning are a recurring operating task. Checkmk's vendor page argues that Zabbix's SQL footprint needs tuning, so confirm the expected item count and polling interval with your own database administrator before you commit.
Native server high availability
Zabbix can run several server nodes against one shared database. One node is active, the others stand by, and failover occurs when the active node exceeds a configurable failover delay. The cluster protects the monitoring server, but it does not make the database highly available, so that layer needs its own design. Ask who owns database failover and test how long monitoring gaps last during a node loss before you rely on this for alerting.
Proxies and proxy groups
Zabbix proxies collect data at remote sites, buffer it while the link is down and offload polling from the central server. Since Zabbix 7.0, proxy groups redistribute monitored hosts when a proxy goes offline. The operator must still plan proxy placement, versioning and certificates for each site, and keep proxy and server versions aligned. Checkmk's vendor page describes Zabbix remote polling through proxies as needing manual configuration and maintenance, so count those sites and tasks in your operating model.
Checkmk Micro Core and its in-memory engine
The commercial Checkmk editions create new sites with the Checkmk Micro Core (CMC) by default, which replaces the Nagios core for check execution. Checkmk's documentation reports benchmark figures for CMC, but these are vendor benchmark claims measured on specific hardware, so they are not a substitute for a test on your own host count and check mix. Ask for a proof of concept with representative load before you size hardware.
Checkmk sites and the Nagios core in Community
A Checkmk site is an isolated monitoring instance with its own configuration, core and data. Community edition is built on the Nagios core, while the commercial editions keep Nagios only as an optional core for migration. An operator running Community must plan for the Nagios-based stack, and anyone migrating to a commercial edition should plan the move from that core to CMC. Confirm which core each planned site will run and what the migration path looks like before the first production site goes live.
Installation options and appliances
Checkmk installs from Linux packages on Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or as Docker container images for Community and commercial editions. Virtual and physical appliances are available only for commercial editions. Zabbix is typically installed from its packages and its own database, so the operator owns the OS, database and web tier either way. Decide whether your team prefers packaged appliances or self-managed Linux hosts, and confirm patching responsibilities for each.
Zabbix vs Checkmk feature by feature, from supplied facts
This table sets Zabbix against Checkmk across licensing, editions, configuration, distributed monitoring, high availability, database needs, engine, agents, synthetic monitoring, support and installation. Read each row against your own environment, because several Checkmk entries are the vendor's own positioning and some cells name a step to confirm. The main takeaway is that Zabbix's full feature set is open source with paid support, while several Checkmk capabilities depend on which paid edition you buy.
| Feature | Zabbix | Checkmk |
|---|---|---|
| License | AGPL-3.0 from Zabbix 7.0 onward; versions up to 6.4 were GPL-2.0 | Checkmk source repository is GPL-2.0; Community edition is free and open source |
| Editions | One open-source product with paid support tiers, no paid edition | Community (free, self-hosted), Pro and Ultimate (self-hosted, paid), plus a SaaS Cloud edition |
| Configuration model | Manual template mapping of hosts to templates (Checkmk's description of Zabbix) | Automatic service discovery and rule-based configuration (Checkmk's own positioning claim) |
| Distributed monitoring | Zabbix proxies and proxy groups are included in the open-source product; proxy groups redistribute hosts when a proxy goes offline | Distributed monitoring is a Pro feature, so it is not in the free Community edition |
| High availability | Native server HA cluster: nodes share one database, one active, failover after a 10 second to 15 minute delay | Confirm the HA design for your chosen edition and site layout with Checkmk documentation before planning |
| Database requirements | Server stores data in MySQL, MariaDB or PostgreSQL with optional TimescaleDB; SQLite only for proxies | Checkmk's Zabbix comparison describes Zabbix's SQL load as needing tuning; confirm Checkmk's storage needs for your scale |
| Core engine | Zabbix server with its own polling and data model | Community uses the Nagios core; commercial editions create new sites with the Checkmk Micro Core by default |
| Push-mode agents and automatic host registration | Not a supplied feature for comparison; confirm agent modes in Zabbix documentation | Checkmk Ultimate feature only, per the Checkmk setup guide |
| Synthetic monitoring | Not a supplied feature for comparison; confirm with Zabbix before assuming coverage | Add-on available only with Checkmk Pro and Ultimate |
| Support tiers | Silver, Gold, Platinum, Enterprise and Global, from 8x5 with 1 day response to 24x7 with 1 hour response | Pro includes 8x5 support per the editions page; confirm support terms for Ultimate and Cloud in a quote |
| Installation methods | Confirm package and container options against the Zabbix requirements and installation documentation | Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or Docker images; appliances only for commercial editions |
What is free and what is paid in Zabbix and Checkmk
Zabbix is released under the GNU Affero General Public License version 3 from version 7.0 onward. Earlier versions, up to 6.4, were released under GPL-2.0, so the license you inherit depends on the version you install. Zabbix states that its open source software has no license fee, no device limits and no feature gates. The money goes to paid technical support, which Zabbix sells as subscriptions on top of the free software.
- License change: AGPL-3.0 applies from 7.0. If you modify Zabbix and let users interact with it over a network, have counsel review those obligations before you deploy.
- No license fee or feature gates: The open source software carries no device limits and no paid-only features, according to the Zabbix license page.
- Support tiers: Silver offers 8x5 support with a 1 day response, Gold a 4 hour response, Platinum 24x7 support with a 2 hour response, Enterprise a 1.5 hour response and Global a 1 hour response, according to the Zabbix support page.
- Recurring cost: Support subscriptions are the main recurring spend. Ask whether the quote includes upgrade help and how billing renews.
Confirm the current support tier terms, response commitments and billing cycle on the Zabbix support page before you budget, because these terms can change.
Checkmk Community is the free, self-hosted edition. The Checkmk/checkmk source repository is licensed under GPL-2.0, and the setup guide describes Community as free, 100 percent open-source software that incorporates Nagios as its core. The editions page positions it for small infrastructures, easily scaled up to about 100 hosts.
- Source license: The repository is GPL-2.0, so the code you run is open source under a copyleft license.
- Host ceiling: The editions page cites about 100 hosts as the practical size for Community. Above that, the vendor points teams to the paid editions.
- Nagios core: Community is built on the Nagios core. The commercial editions create new sites with the Checkmk Micro Core by default.
- No distributed monitoring: Distributed monitoring is a Pro feature, so Community does not include it.
- Cost shift: There is no license fee, but staff time, hosting, backups and any outside help still cost money.
Count your hosts against the about 100 host guidance and confirm the current Community limits on the Checkmk editions page before you commit to this tier.
Checkmk's paid editions add features to the self-hosted platform and offer a SaaS option. The editions page lists Pro at 190 euros per month and Ultimate at 275 euros per month, both billed annually, and Cloud at 240 euros per month billed yearly, capped at 50,000 services. Each paid tier unlocks a different set of features, so the choice depends on what your team needs to run.
- Pro: 190 euros per month, billed annually. Adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support. Synthetic Monitoring is an add-on for Pro.
- Ultimate: 275 euros per month, billed annually. Adds full-stack observability, multi-tenancy, advanced security compliance and automated mass rollouts. Push-mode agents and automatic host registration are Ultimate features, per the setup guide.
- Cloud: 240 euros per month, billed yearly, capped at 50,000 services. The vendor runs the platform as SaaS, so hosting is outside your infrastructure.
- What the page does not state: The pricing basis, such as per host, per instance or per service, and what overage costs look like need confirmation with the vendor.
Before budgeting, check the current prices, billing terms and feature lists on the Checkmk editions page, since these figures are vendor-published and can change.
The two platforms charge for different things. Zabbix charges for support on free software, while Checkmk charges for the edition itself, and some Checkmk features only exist in the paid tiers. A fair comparison needs the same cost lines for both sides, which means asking for written quotes that match your scope.
- Support scope: Ask Zabbix which tier covers your sites, response times, upgrade help and whether it applies to proxies and the database layer.
- Edition fit: Map the features you need, such as distributed monitoring, push-mode agents or multi-tenancy, to the edition that includes them.
- Pricing basis: Confirm how Checkmk counts hosts, instances or services, and whether taxes and currency conversion apply to the euro figures.
- Hidden effort: Estimate the staff time for template work in Zabbix and rule configuration in Checkmk, and the database tuning Zabbix may need. Vendor marketing treats these as overhead, so test them in your own environment.
Request written quotes for each option, and compare them against the same host count and feature list before you choose.
What drives the running cost of Zabbix and Checkmk
The license line is the smallest part of running either platform, so the useful question is who is paid for what. Zabbix has no license fee, no device limits and no feature gates, according to Zabbix's own statement, so its recurring cost is the infrastructure it runs on, the database it writes to, the staff who maintain templates and proxies, and any paid support subscription you choose. Checkmk Community is also free, but Pro and Ultimate are billed per year, with list prices of 190 and 275 euros per month, billed annually, according to the Checkmk editions page. Those prices are the vendor's published list figures and may not match a negotiated quote. Ask each vendor, or the partner quoting the work, to state the price basis (per host, per service or per instance), the billing period and whether support is included.
Several costs are one-time and several recur. The one-time work is the initial build: designing templates or rules, discovering and mapping hosts, and migrating existing checks. The recurring work is the database and server capacity, the staff time to maintain templates or rule sets, proxy or site operations, on-call effort, subscription renewals and upgrades. Zabbix standard releases are supported for 12 months and LTS releases for 5 years, so a standard release forces a yearly upgrade cycle while an LTS track spreads that effort. Checkmk 2.5.0 was tagged on April 24, 2026 and patch 2.5.0p15 on September 30, 2026, which shows the patch cadence your team should budget for. Zabbix support tiers run from 8x5 with a 1 day response (Silver) to 24x7 with a 1 hour response (Global), and Checkmk Pro includes 8x5 support, so compare response windows against your on-call model rather than the headline price.
Checkmk's own claim is that total cost of ownership includes the operational overhead of maintenance, not only Zabbix's free license. That argument holds when your team would otherwise spend significant time tuning the Zabbix SQL footprint, managing manual template mapping and maintaining proxies across sites, and when Pro or Ultimate removes that work. It weakens when you already run a database team, a stable template library and a proxy design, or when your host count stays small enough for Community. Treat the claim as a hypothesis to test. Ask for a written quote that lists subscription tier, host or service count, support response times, migration scope and the staff hours assumed for year one and for steady state, and ask each vendor which of its own cost assumptions it would change in your environment.
Moving from Zabbix to Checkmk, or the reverse, step by step
This sequence moves monitoring from one platform to the other without a gap in alerting, ending with a verified cutover and retired Zabbix or Checkmk components. Each step produces a checkable output so you know when to move on.
Inventory hosts, items and triggers
Export the current state from the source system: host list with groups and interfaces, item keys, trigger expressions, active proxies or sites, and the notification actions tied to each trigger. Zabbix administrators can pull much of this through the API or configuration exports, while Checkmk teams can list hosts and check configuration from the site. Record which checks drive paging and which only feed dashboards, because those two groups get different treatment later. The step is done when you have a signed-off inventory that counts every monitored host and every alert that reaches a person or a ticketing system.
Map templates to rules and services
Translate each Zabbix template into its Checkmk counterpart: Checkmk discovers services automatically on a host, so many items map to discovered services, while thresholds and exceptions become rules. Zabbix templates with custom item keys or script-based checks usually need a new Checkmk check or plugin written and tested. Confirm with Checkmk which existing checks and special agents cover your device types and which require custom work. The step closes with a mapping sheet that lists, for each template, the Checkmk rule set or service it replaces and any gap that has no equivalent.
Confirm the import path with the vendor
Checkmk Community is built on the Nagios core, and the commercial editions create new sites with the Checkmk Micro Core by default, keeping Nagios only as an optional core for migration. Ask Checkmk whether a Zabbix configuration can be imported directly, which elements it covers, and whether the import reproduces thresholds, host tags or history. Do not assume a conversion tool exists for your version pair. The step is done when the vendor has answered in writing and you know which items will be imported automatically and which must be recreated by hand.
Rebuild dashboards, alert logic and templates
Plan the work that does not transfer: Zabbix templates, Checkmk rules, dashboards, graphs and alert logic such as escalation, maintenance windows and dependency suppression. Rebuild these in the target system and test each alert against a known fault. Zabbix's standard trigger expressions and Checkmk's rule-based notification setup are not the same model, so review every escalation path rather than copying it. The step closes when each rebuilt alert has been triggered in a test and has delivered to the expected recipient.
Run both systems in parallel
Keep the source system active while the target monitors the same hosts. Compare alert volume, false positives and missed events for an agreed period, and watch database and server load on both sides. Expect differences in check timing and state changes, and document each one with its cause. Zabbix load is driven by its SQL footprint, which Checkmk's own comparison material says requires database tuning, so record database metrics on both platforms to confirm the change in load profile in your environment. The step is done when the parallel results are reviewed and every difference is either fixed or accepted by the service owner.
Migrate alerting and notification paths
Move notifications one channel at a time, starting with low-impact channels such as chat or email, then paging and ticketing integrations. Confirm that on-call schedules, escalation timing and acknowledgment flows behave the same way in the new system. Remove the old notification action only after the new one has been exercised by a live or simulated incident. The step is complete when each channel has been cut over, a test incident has reached every responder, and the old action is disabled but kept available for rollback.
Retire proxies or sites
Once the target handles all hosts, decommission Zabbix proxies or the remote Checkmk sites that the source system relied on. Zabbix remote polling uses proxies that need manual configuration and maintenance, so confirm that the target's distributed design covers each network segment before removing any proxy. Note that distributed monitoring is a Checkmk Pro feature, so a Community deployment will not provide it. The step closes when every host reports to the target and no remaining component depends on a retired proxy or site.
Decommission and archive the source
Stop the source monitoring services, export and archive its configuration and history under your retention policy, and revoke its credentials and API tokens. Remove agents or update them so they report only to the new platform, and update runbooks, CMDB records and on-call documentation. Record the final state in your change log. The step is done when the source system is stopped, its archive is verified as readable, and no active alert or agent still points at it.
Where Zabbix and Checkmk implementation projects usually run long
Zabbix projects most often slip in template design and macro standardization. Every host inherits templates, and macros such as thresholds and credentials decide how one template behaves across hundreds of hosts. Teams that clone templates per team, or override macros on individual hosts, spend the parallel run fixing inconsistent alerts. Before work starts, agree a naming convention, an ownership model for templates and a rule for when a macro belongs at the template level versus the host level. Proxy placement is the second common slip: the Checkmk comparison page notes that Zabbix remote polling relies on proxies that need manual configuration and maintenance, so confirm early which networks need a proxy, which proxy groups provide failover, and who maintains each proxy after handover.
Checkmk projects slip in a different place. Automatic service discovery produces many services quickly, and the work moves to rule design: which rule sets apply to which folders, how discovered services are grouped, and how discovery is tuned so that ephemeral or noisy services do not reach the alerting layer. Site placement across networks also needs a decision before rollout, because Community, Pro and Ultimate have different distributed monitoring and deployment options. Check the editions page for the features your chosen tier includes, and confirm whether push-mode agents and automatic host registration are needed, since the setup guide lists them as Ultimate features.
Both platforms share two risks that are easy to underestimate. Database tuning and sizing for Zabbix's SQL footprint (MySQL, MariaDB, PostgreSQL with or without TimescaleDB) must be planned against your history retention and item count, and the database team needs to own that work. Identity integration and the access model also take longer than expected: decide early how Zabbix user groups and authentication methods map to your directory, or how Checkmk roles and contact groups map to teams. Alert noise during the parallel run is the final slip point, since both systems will notify people at once. DeployOpen plans and delivers implementation work as fixed-scope engagements, and the scope, deliverables and timelines are agreed in writing before work starts, so these items are settled in the statement of work rather than discovered mid-project.
Zabbix vs Checkmk questions buyers ask before hiring help
Is Zabbix free to use in production?
Yes, the open source Zabbix software has no license fee, no device limits and no feature gates, according to Zabbix's support page. The recurring spend is paid technical support, which comes in Silver, Gold, Platinum, Enterprise and Global tiers, and it is optional. Your costs are then infrastructure, the database, staff time and any outside help you buy. Ask for support tier response times in writing if uptime depends on vendor response, and budget for the operating effort that the license does not cover.
What does Checkmk Community limit?
Checkmk Community is free and open source, built on Nagios as its core, and the editions page describes it as suited to small infrastructures, scalable up to about 100 hosts. Distributed monitoring is a Pro feature, so Community does not include it. Community also lacks the Micro Core that the commercial editions use by default. If your host count or multi-site design is near those limits, plan for an edition change before you build around Community.
What do Checkmk Pro and Ultimate cost?
The Checkmk editions page lists Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually. These are list prices from the vendor, so confirm current pricing and any tax or reseller terms directly with Checkmk. Pro adds advanced analytics, automation, distributed monitoring and 8x5 support, and Ultimate adds full-stack observability, multi-tenancy, security compliance features and automated mass rollouts. Ask for a quote that matches your host count and the features you need, not the highest tier by default.
Does distributed monitoring require a paid edition in Checkmk?
Yes. Distributed monitoring is listed as a Checkmk Pro feature, so the free Community edition does not include it. In Zabbix, distributed monitoring uses proxies, and proxy groups from Zabbix 7.0 onward handle load balancing and failover without a paid edition. The cost question is therefore different for each product: Checkmk puts distribution behind a subscription, while Zabbix's proxy design is free but needs your team to configure and maintain it. Ask your provider to show how many sites you need and who operates them.
How long does a migration take, and what drives that time?
No supplied fact gives a migration duration, so treat any number from a vendor or partner as an estimate until it is tied to scope. The main drivers are the number of hosts and services, how much of your alerting is built from custom scripts or manual Zabbix templates, the number of notification and escalation paths, how many dashboards and reports must be rebuilt, and how much history you need to keep. Checkmk's rule-based model and automatic service discovery can shorten some steps but still require rule review. Ask for a fixed-scope plan with deliverables and a written timeline before work starts.
Can our own team run the migration without outside help?
Often, yes, if you have a capable Linux and monitoring operator, a clear inventory of checks and a test environment that mirrors production. The harder parts are rebuilding alert logic, validating that nothing silently stops alerting and aligning notifications with on-call rotations. Checkmk's vendor material says it uses automatic service discovery and rule-based configuration, which many teams find faster to maintain, while Zabbix requires more manual template mapping. Outside help is most useful for scoping, parallel running and cutover, not for every check. A fixed-scope engagement can cover the parts you choose.
What skills and staff time does each platform need after go-live?
Zabbix needs people who can manage templates, proxies, the server database and its upgrade cycle, since standard releases are supported for 12 months and LTS releases for five years. Checkmk needs people who can work with rules, sites and the Micro Core in commercial editions, and the Community edition uses Nagios as its core. In both cases, ongoing work includes upgrades, backups, access control and alert tuning. Ask any provider for a named staffing model, a runbook for routine tasks and a written handover plan. Retainers for upgrades and continuous support are available from DeployOpen if you prefer ongoing help.
How does database load compare between Zabbix and Checkmk?
Checkmk's vendor page says Zabbix has a resource-intensive SQL footprint that needs database tuning, while Checkmk uses an in-memory engine. That is Checkmk's own claim, so validate it with a load test on your hardware. For Zabbix 7.4, the server stores data in MySQL, MariaDB or PostgreSQL with optional TimescaleDB, and the supported versions are listed in Zabbix's requirements documentation. The Checkmk docs report benchmarks of more than 600,000 checks per minute on a desktop Core i7 and a 20,000-host configuration loading in about half a second, but those figures come from the vendor, so ask for a proof of concept at your scale.
How DeployOpen helps choose, implement or migrate monitoring
DeployOpen works on Zabbix vs Checkmk as an implementation partner inside your own infrastructure, not as a product vendor. We help you decide which platform fits your host count, team and edition budget, then plan and deliver the deployment, templates or rules, and documentation in a written scope.
How we scope
- We confirm which hosts, networks and applications need monitoring and where each site and data center sits.
- We compare Zabbix templates against Checkmk rule-based configuration using your real device mix and team skills.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen platform in your cloud accounts, data centers or air-gapped network, with the database layer sized for your load.
- We design distributed monitoring, whether Zabbix proxies or Checkmk sites, and test failover behavior before go-live.
- We build templates or rules, alerting and integrations, and test them against a representative set of hosts.
How we hand over
- We document architecture, configuration decisions, backup procedures and the edition or support tier you chose.
- We run knowledge transfer sessions so your operators can maintain templates, rules, proxies and upgrades.
- We deliver a written migration plan for moving existing Zabbix or Nagios checks, listing what must be rebuilt by hand.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We track vendor release and support windows, so upgrade work follows the lifecycle published by each vendor.
- Support scope, response expectations and retainer terms are set in writing, with a quote following from that scope.
