Zabbix 6.0 LTS to 7.0 LTS upgrade

The supported path is a direct move from the Zabbix 6.0 LTS line to the 7.0 LTS line. Zabbix 6.0 LTS limited support ends on 28 February 2027, so that date sets the outer limit of your window, and 7.0 LTS carries full support until 30 June 2027. The team must start from a supported 6.0 minor release, so the first task is to record the exact version of the server, web frontend, proxies and agents in every environment. Then check the official upgrade procedure for 7.0 that names that starting point. Confirm in the upgrade notes whether any intermediate step is required before 7.0. This page does not list one, and your plan should not assume a stop that the official notes do not name.

Choose between an in-place upgrade and a rebuild on new hosts before writing the task list, because the choice sets the order of everything else. An in-place upgrade keeps the existing server hosts and configuration, runs the database schema migration against your live data, and then moves proxies and agents in stages. Rollback in this case usually means restoring a database backup taken immediately before the upgrade, so that backup must be proven by a restore test before work starts. A rebuild installs 7.0 on new hosts, loads a copy of the 6.0 database, and repoints proxies and agents to the new server at cutover. The old stack stays intact, so rollback becomes a repoint, but any data written to the old database after the copy must be reconciled before cutover.

Database migration is the step that most affects duration and rollback. The Zabbix 7.4 requirements list PostgreSQL 13 to 18 and TimescaleDB 2.13 to 2.29 for the server database, but those are 7.4 figures. Check the requirements for the 7.0 release you target before you choose database and TimescaleDB versions, and confirm the PHP and web server prerequisites in the same material. Copy the production database to staging, measure its size and history table growth, and time the schema migration on that copy. Record the result as your own measured figure from your data, and use it to set the maintenance window.

Sequence the components only after the server decision is made. Follow the order given in the official upgrade notes for the server, frontend, proxies and agents, and confirm which agent versions the upgraded server accepts during the transition. Proxy groups, available from 7.0, redistribute monitored hosts when a proxy goes offline, so decide whether you will use a proxy group before you change proxy membership. Test one proxy, a sample of agents including Windows agents and their configuration paths, and any custom templates in staging before production. Assign a named owner and a go or no-go decision point to each component on the change record.

Finish the prerequisite work before any Zabbix package changes. The 7.0 server and frontend depend on the PHP runtime, the database engine and version, and the TimescaleDB extension if you use it for history tables. Start by reading the Zabbix 7.0 requirements page and recording the exact supported ranges for each component. The requirements page lists current versions, and those entries may differ from the 7.0 values, so confirm the 7.0 figures against that page before you scope the work or agree a timeline with a partner.

These components often need their own upgrades, and the operating system may be the limiting factor. A distribution's default repositories may ship a PHP version older than the 7.0 frontend requires, or a database major version that is out of step with your extension version. Check the OS release, its package sources and any third-party repositories now. If the OS must change, decide between an in-place upgrade and a new host, and plan that step with its own rollback path, since it sits ahead of every Zabbix change.

If the team uses TimescaleDB for history and trend tables, treat the extension as a separate compatibility decision. Confirm which TimescaleDB versions 7.0 supports for your database major version, and sequence the database engine upgrade, the extension upgrade and the Zabbix schema upgrade in that order with a verification step between each. Ask whether compression policies are enabled and how many chunks exist, because compressed chunks can change the migration steps and the time each step takes.

Database upgrade time depends on the size of the history and trend tables, the state of their indexes, and whether TimescaleDB compression or chunking is in use. Fragmented or bloated indexes, large uncompressed chunks and long-retained history all lengthen the schema steps. Do not extrapolate from a small lab database. Restore a recent production backup to a staging system with comparable hardware, run the full upgrade sequence, and record the duration of each step, disk and log growth, and free space headroom. Repeat the rehearsal at least once so you can see variation.

Before you set a date, make a go or no-go checklist covering confirmed 7.0 component versions, the OS and repository plan, a tested restore, the staging timings and a rollback point for each step. When you request a quote, ask for the OS and PHP work, the database and TimescaleDB rehearsal, and the restore test as separate line items, so you can see which parts are one-time and which recur. Ask the partner to state what it assumes about your table sizes and compression settings.

The staging test has one purpose: prove that the Zabbix 7.0 LTS server, frontend, proxies and agents behave like the 6.0 estate before anyone books the production window. Build the staging environment from a copy of the production database at the same size, then time the schema upgrade on that copy. Record how long each step takes and compare the result with the agreed change window. Next, validate items and triggers by comparing counts of enabled, supported and unsupported items, and trigger states and problem generation, against an export taken from production before the upgrade. Import or update the templates you use, then run your API scripts and integrations against the new frontend. Confirm that every proxy reaches the server, and confirm agent checks on each operating system family in the estate, including the Windows agent paths that changed in this upgrade.

Alerting and authentication need their own tests because they fail quietly. Send a test notification through every media type in use, such as email, chat, ticketing and webhooks, and confirm that actions fire and escalations reach the right recipients. If LDAP, SAML or MFA is in use, sign in with a standard user, an administrator and an account that depends on just-in-time provisioning, then check that group mappings still assign the correct user roles and permissions. Ask the identity team to confirm the validity dates of SAML certificates and metadata, because an expiring certificate can look like an upgrade defect. Record each result in the test log with the person who ran it, so the go or no-go decision rests on evidence rather than memory.

The rollback decision depends on one fact: once the schema upgrade runs against the production database, returning to 6.0 usually means restoring the database backup. Identify the last point in the sequence where that restore is still clean, which is normally the backup taken immediately before the schema step. Restore that backup on a separate host and confirm it starts before the change window, because an unverified backup is not a rollback plan. After the schema changes, rollback gets harder for several reasons. The 7.0 server will have written new monitoring data, proxies may already report to the new version, and API clients may depend on behavior that changed. Read the vendor upgrade notes to confirm which downgrade paths, if any, are supported.

Set the rollback threshold in the change record before the window opens, with a named person who has authority to make the call. Define the maximum time the schema step may run, the number of failed checks allowed in the post-upgrade smoke test, and the alerts that must work before the change is accepted. Illustrative example: if the schema step overruns the agreed limit, the change lead restores the backup and reopens the window at a later date, instead of extending the outage on an unknown timeline. Write the threshold once and do not change it during the window.

If the server runs as a high availability cluster, decide how standby nodes are handled before the upgrade starts. Standby nodes share the same database, so the options are to stop all nodes, upgrade them in a planned order, or upgrade one node and keep the others offline until it is verified. Confirm in the vendor documentation how mixed versions behave before choosing. The failover delay is configurable between 10 seconds and 15 minutes, so record the current value and confirm it is appropriate for your alerting needs. After the change, stop the active node in a controlled way and confirm that a standby takes over, that alerts continue, and that the node status matches expectations. In 7.0 and later, proxy groups redistribute hosts when a proxy goes offline, so stop one proxy and confirm its hosts move to another proxy.