Zammad 6.5 to 7.2 upgrade: why it is more than a version bump
The upgrade from Zammad 6.5 to the 7.x line crosses several components beyond the application itself. A team that treats it as a version bump on one server is likely to find its database, search index, cache, reverse proxy and integrations out of step with the new release. Zammad 7.2 was released on 23 September 2026 as a minor release, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026. Security fixes were also published for the 6.5 line in 6.5.5 on 15 October 2026, so a team that needs a patch now does not have to move to 7.x on the same day. The decision is about timing, scope and which release to land on, and it should be made with the full component list in view.
The database is the largest change. Zammad stores its content in PostgreSQL 15 or newer, so a team still on MySQL has to plan a database engine move before the application upgrade can finish. Confirm in the Zammad release notes and upgrade documentation which migration method is supported, how long the data copy takes in your environment and how the cutover will be verified. Redis 7 or newer is required for realtime websocket communication, so check the running version now. Elasticsearch is optional but strongly recommended for search, reporting and attachment content. If you move to the 8.15 line named in the migration plan, the search index will need reindexing, which adds time to the cutover window. Teams running several application nodes should also confirm whether Memcached is needed for multi-instance deployment.
Integration and edge changes need their own owners. The Slack and Twitter integrations are removed in the 7.x line, so every channel, trigger and automation that depends on them needs a replacement or a documented retirement decision before cutover. Ask the business owners which rules they rely on, and test the replacements with sample tickets in a staging copy. The reverse proxy also changes. Zammad supports Nginx or Apache, and the nginx configuration and Content Security Policy headers in the new release may need edits for embedded content, websockets and file uploads. Compare your current configuration against the upgrade documentation line by line, and do not carry the old file forward unchanged.
Check the operating system before anything else. The target release has its own supported operating system list, and an older host may need a rebuild, which changes the schedule. Also check the PostgreSQL version you will run after the move. PostgreSQL 14 reaches end of support on 12 November 2026, while PostgreSQL 15 is supported until 11 November 2027, and the 7.x line requires 15 or newer. Choose the target PostgreSQL major version with its lifecycle in mind, and plan any separate PostgreSQL major upgrade as its own tested step.
Before planning, confirm the supported upgrade path, the minimum component versions and any ordering rules in the Zammad release notes and upgrade documentation. This page does not replace those documents, and the documentation for the exact release you choose takes precedence over any summary here. Name the person who signs off each component, including the database owner, the search owner and the team that manages the reverse proxy. Ask any partner for a written scope that lists each component, who changes it, the backup and rollback approach and the test evidence expected at cutover. Fixed-scope work of this kind is agreed in writing before it starts, and the quote should follow from that scope.
Which Zammad 7.x changes affect your 6.5 installation
This table lists each change in the Zammad 7.x line that can affect a 6.5 installation, with the impact and the action for each one. Work through the rows for what is already running, then the rows that check your target stack. Confirm the exact wording against the 7.x release notes for the version you target before you schedule work.
| Change | Impact | Action needed |
|---|---|---|
| MySQL to PostgreSQL | The 7.x line requires PostgreSQL 15 or newer, so a MySQL installation must migrate its database as part of the upgrade. | Rehearse the migration on a copy, confirm steps in the 7.x notes, and consider a currently supported PostgreSQL major version (15 support ends November 2027). |
| Slack and Twitter integrations removed | Channels and triggers that depend on these integrations stop working after the upgrade. | Inventory every Slack and Twitter channel and trigger, record its purpose, and agree replacements with the people who use them. |
| Elasticsearch 8.15 and reindexing | The search index must be rebuilt against Elasticsearch 8.15, so search results may be incomplete until reindexing finishes. | Confirm your Elasticsearch version, plan the reindex window with operations, and test search and attachment search after it completes. |
| nginx and Content Security Policy changes | Custom reverse proxy settings and CSP headers may block assets or break pages after the upgrade. | Compare your nginx or Apache configuration with the 7.x defaults, then test the CSP headers in staging before cutover. |
| Operating system support | The operating system on your 6.5 host may fall outside the 7.x support list. | Check the supported operating systems in the 7.x requirements before you fix the upgrade order, and plan any OS upgrade separately. |
| Redis 7 or newer on target stack | Realtime websocket communication needs Redis 7 or newer, so older Redis versions block the target stack. | Confirm the current Redis version and upgrade it before cutover if it is older than 7. |
| Memcached for multi-instance deployments | Container or cluster deployments need Memcached, while single installations can use the file system cache. | If you run more than one Zammad node, confirm Memcached is part of the target stack before testing the upgrade. |
How the MySQL to PostgreSQL move changes the upgrade plan
Moving the content store from MySQL to PostgreSQL is a data migration that runs alongside the version change. It cannot be handled as an in-place upgrade, because the data is copied into a different database engine with its own schema, character handling and sequences. That copy needs its own rehearsal and its own cutover window, separate from the application upgrade. Treat the database move as a workstream with a go or no-go decision, a defined freeze point for ticket writes, and a rollback path that keeps the MySQL source intact until the business accepts the PostgreSQL copy. Agents should be told exactly when writes stop, because tickets created during the gap are a common source of data loss.
Confirm the PostgreSQL target before you schedule anything. Zammad stores its content in PostgreSQL 15 or newer, so 15 is the lowest version you can use. PostgreSQL 14 reaches end of support on November 12, 2026, so choosing it would leave the content store without security fixes soon after cutover. PostgreSQL 18 was first released on September 25, 2025, and its final release is scheduled for November 14, 2030. PostgreSQL supports each major version for five years after its initial release, so your target sets how long the database keeps receiving security fixes. Ask Zammad which PostgreSQL version Zammad 7.2 was validated against, and align your target with that answer before you choose a date.
PostgreSQL and Zammad have separate upgrade paths, and each needs its own plan. PostgreSQL minor releases replace executables and restart the server, but major upgrades use pg_dumpall and restore, pg_upgrade, or logical replication. Logical replication can shorten downtime, but it adds setup, monitoring and a longer validation period. The procedure for moving MySQL data into PostgreSQL must come from the Zammad 7.x documentation. Confirm which MySQL versions the procedure supports, what it migrates automatically, what it leaves for manual handling, and whether it runs against a live instance or only a stopped one. Do not assume that a migration guide for another helpdesk covers this step.
Rehearse the move on a copy of production data and time each stage, including the dump, load, post-load checks and the first application start. Compare row counts for tickets, articles, users and attachments, and confirm that attachment storage paths, ticket numbering, time zones and scheduled jobs behave as they did before. Keep the MySQL source read-only until the rehearsal results are signed off, and keep a verified backup of it. Put these questions to Zammad and your own database team in writing: which PostgreSQL version is validated for 7.2, which MySQL versions the migration supports, and how the procedure is rolled back if the cutover fails. Record the answers in the change plan so the cutover is approved against known facts.
What to prepare before touching the 6.5 installation
Four preparation areas decide whether the upgrade is a controlled change or an outage. Each one produces a record or a working copy that the upgrade team uses later. The backup protects the rollback path, the inventory shows what may break, the integration list assigns an owner to each removed channel, and staging shows how long the heavy steps take.
Full backup with a tested restore
Back up the database, the application data directory and every uploaded file as one consistent set taken at the same point in time. Restore that set to a separate host and confirm that tickets, attachments, scheduled jobs and agent logins work before you rely on it. Keep the MySQL dump and file copies untouched until the PostgreSQL system has passed review, because the move between database engines is the step most likely to need a rollback. A backup that has never been restored is an assumption, not a recovery plan.
Inventory of customizations
Record every change made outside the standard package: custom integrations, scripts, reverse proxy configuration for nginx or Apache, and third-party login settings for SAML, OpenID Connect or other providers. For each item, note the file path, the owner and the reason it exists, then check whether the 7.x release changes the same setting. Content Security Policy headers and proxy rules are common places where an upgrade breaks sign-in or embedded content, so list them explicitly.
Slack and Twitter integration decisions
List every Slack and Twitter integration in use, the teams and automations that depend on each one, and the person who signs off on its replacement. Each item needs a decision before the upgrade: move it to a supported alternative, rebuild it on another channel, or retire it and tell the agents and customers affected. Confirm where inbound messages arrive today and where they will be routed after the removal, so no conversation disappears during the cutover.
Staging that mirrors production
Build a staging environment that matches production in operating system version, PostgreSQL, Elasticsearch 8.15, Redis and the reverse proxy. Load a copy of production data at a volume close enough to the live system that the reindex and the database migration take a time you can plan around. Record those timings and use them to set the cutover window. Confirm that the operating system is on the support list for the 7.x release before you build anything.
The upgrade sequence with checks and rollback points
This sequence moves a Zammad 6.5 instance to a verified 7.2.x target one checked step at a time. Each step ends with evidence that it worked, and each change that touches data or production traffic has a rollback point before it runs. The result is a go or no-go decision backed by staging results rather than assumptions.
Confirm the supported path and target patch
Confirm the supported upgrade path from 6.5 to 7.2 in the Zammad releases page and documentation, then choose the target. The target is 7.2.2 or the latest 7.2.x security release available on the day of work. Zammad published 7.2 on 23 September 2026, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026. Zammad also shipped 6.5.5 on 15 October 2026, so check whether your 6.5 instance needs that patch first. The step closes with a written decision record that names the target version and the 6.5 patch level used as the rollback baseline.
Rehearse the upgrade on staging
Build a staging environment that matches production in operating system, PostgreSQL, Redis, Elasticsearch, web server and single or multi-instance layout. Restore a recent production backup into it and run the full upgrade from 6.5 to the chosen 7.2.x target. Keep a rehearsal log that records every error, manual intervention and configuration change. Your internal team or DeployOpen, under a written fixed scope, can own this log. The step closes when one complete rehearsal finishes without unplanned changes, and the log becomes the production runbook.
Verify operating system and dependency versions
Check the operating system release, PostgreSQL, Redis, Elasticsearch and any runtimes against the 7.2 software requirements in the Zammad documentation. That documentation is the source of truth for this check, so compare it with your environment line by line. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and it supports Nginx or Apache as the reverse proxy. If you run several Zammad instances, confirm that Memcached is in place, because single installations can use the file system cache instead. The output is a dependency sheet signed off by the platform owner before any production change.
Migrate the database from MySQL to PostgreSQL
In staging, move the Zammad database from MySQL to PostgreSQL using the migration guidance for this upgrade path. Confirm that the PostgreSQL version you choose is in its support window. Under the PostgreSQL versioning policy, version 15 is supported until 11 November 2027, and version 14 until 12 November 2026. Compare record counts for tickets, articles, users, groups and organizations between source and target. Open an agreed sample of attachments and confirm that each one matches its stored size and content. The step closes when counts match and the sample opens without errors.
Update the reverse proxy and CSP headers
Update the Nginx or Apache configuration and the Content Security Policy headers for the 7.2 target. Take the header values from the 7.2 documentation and compare them with the 6.5 configuration line by line, so that no legacy directive carries over unnoticed. Then test the login page, a ticket view, file uploads and the realtime websocket connection in a browser. The step closes when the browser console reports no blocked resources, realtime ticket updates arrive without a page reload, and the Redis connection is confirmed.
Reindex Elasticsearch and confirm search
Move the search cluster to Elasticsearch 8.15 as the 7.2 path requires, and confirm the exact version with the documentation before you start. Then rebuild the search index in staging. Elasticsearch is optional, but search, reporting and attachment content search depend on it, so treat this step as a functional test rather than a formality. Run a fixed set of test queries covering ticket numbers, customer names, email addresses and words inside PDF attachments. Compare the hit counts with the 6.5 system. The step closes when every query returns the expected results and the reporting views load.
Replace or disable Slack and Twitter integrations
Inventory every trigger, channel, webhook and API token in the 6.5 system that uses the Slack or Twitter integrations, which are not available in 7.x. For each one, record the owner, the business purpose and the behavior your team expects after cutover. Then either replace it with a supported alternative or disable it. In staging, confirm that disabled channels no longer post, that replacement flows receive test events, and that no orphaned tokens remain active. The step closes with a signed list where every item shows a replacement or a disabled state.
Back up, cut over and keep rollback open
Freeze changes to the 6.5 production system and take a full backup of the database, attachments and configuration. Restore that backup to a separate host to prove it works before you rely on it. Run the upgrade in the change window your team agreed, then repeat the staging checks against production. Keep the 6.5 system and its verified backup intact until the post-cutover review closes. The rollback point is the verified backup plus a restore procedure your team has already rehearsed. The step closes with a signed go or no-go record and a monitored first day of operation.
How to test the Zammad 7.2 upgrade and roll it back safely
The test plan should show that the upgraded Zammad 7.2 instance can carry the work agents do on the first day, with every workflow your team depends on tested end to end. Start with functional tests for each email channel, both inbound and outbound, and confirm that tickets are created and updated from every path your agents use. Test third-party login with the exact identity provider and protocol you run, whether that is SAML, OpenID Connect or another supported provider, and confirm that users are matched to the right accounts. Include attachments, uploaded and received, and check that they open correctly after the move. Finish with reporting and scheduled jobs, comparing report output and job run history against the 6.5 system for the same period.
Search needs its own checks because the index is rebuilt during the upgrade. Run a fixed set of queries on the 6.5 system before testing starts, covering ticket numbers, customer names, common phrases and terms found inside email attachments, then run the same queries on the 7.2 staging copy after reindexing. Any gap in results should be explained before cutover. Confirm that Elasticsearch is reachable from the application nodes at the version your plan specifies, and that search content extraction still works for the attachment types your customers send. Record which queries returned differences and who signed off on each one.
Performance checks should cover two windows: the reindex itself and the first day of live traffic. Measure how long the reindex takes on a staging copy sized like production, and how much CPU, memory and disk it consumes on the database, Elasticsearch and application hosts. Agree the acceptable limits with the business owner before the test, so the result is a decision rather than a debate after cutover. For live traffic, watch background job queues, websocket connections that depend on Redis, response times in the browser and error rates at the reverse proxy. Keep the staging copy's configuration identical to production, including the reverse proxy and content security policy changes described elsewhere on this page.
A rollback after cutover means restoring the verified backup and the 6.5 application. Because the database moves from MySQL to PostgreSQL, the rollback path is a separate restore of the MySQL data, so the team must rehearse it before go-live. Before cutover, decide how long the old system stays available, which conditions trigger a rollback, and who makes the call. Name that person and a deputy, and document who must be told. Decide also how tickets created in 7.2 during the window will be handled, either by reentering them or by a planned export, because the 6.5 backup will not contain them. Put these decisions in the cutover plan and get them approved in writing.
Patch level matters for both paths. Zammad released security release 6.5.5 on 15 October 2026, and security fixes were published for the 6.5 and 7.x lines in parallel. If your team must stay on 6.5 for a period, confirm that the running instance is at 6.5.5 or a later patch in that line, and plan for it to be patched during that period. On the 7.x side, Zammad published 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, so confirm which 7.2 patch level you install and check the release notes for both lines before the test begins.
What makes a Zammad 6.5 to 7.2 upgrade longer or shorter
This table lists the drivers that change how much work a Zammad 6.5 to 7.2 upgrade involves. Read each row as a question to answer about your current installation before you ask for a quote. The main takeaway is that measurements from your own environment shape the scope more than the version numbers alone.
| Driver | Why it matters | How to measure before quoting |
|---|---|---|
| Database size and attachment volume | Moving data from MySQL to PostgreSQL and rebuilding search indexes both scale with ticket history and stored attachments. | Record database size, attachment storage size and total ticket count from the current server. |
| Slack and Twitter integrations | These integrations are being removed, so each live workflow that depends on them needs a replacement path. | Count active channels and list each ticket workflow or alert that relies on them. |
| Custom integrations, scripts and API clients | External callers may depend on endpoints, fields or authentication details that change during the upgrade. | Inventory cron jobs, webhooks, scripts and API tokens, then plan a test of each against a staging copy. |
| Reverse proxy and Content Security Policy customizations | Custom nginx or Apache rules and CSP headers can break the web interface or realtime features after the upgrade. | Export proxy configuration and any header overrides, and note each custom directive still in use. |
| Elasticsearch cluster size and sharing | Reindexing runs against the cluster, and a shared cluster competes with other applications for resources. | Record node count, Elasticsearch version, index sizes and whether other applications use the same cluster. |
| Multi-instance or container deployment | Multiple application nodes need Memcached and Redis configured consistently, which adds components to change and test. | Confirm the number of application nodes or containers and where Memcached and Redis run. |
| Operating system changes on the host | Host OS and runtime support must match the 7.x requirements, so a host change may mean a rebuild instead of an in-place update. | Compare the current host OS against the Zammad software requirements for 7.2 and note any gap. |
| Environments that must be rebuilt | Each rebuilt environment repeats the migration, testing and sign-off work for that environment. | List production, staging, test and recovery instances and whether each can be upgraded in place. |
Questions buyers ask before upgrading Zammad 6.5 to 7.2
What drives the cost of a Zammad 6.5 to 7.2 upgrade?
The scope of the database, search and integration work drives most of the cost, not software licensing, because self-hosted Zammad has no license fee. The main cost components are planning, staging rehearsals, the production cutover window, verification and documentation, all paid as one-time work. Costs rise when the upgrade includes moving the database from MySQL to PostgreSQL, when the data volume and attachments are large enough to lengthen migration and reindexing, when removed Slack or Twitter channels need replacement, when several instances need shared caching, or when proxy and Content Security Policy changes touch many hosts. Ongoing vendor support is a separate, recurring cost. A quote should itemize each phase, name the environments included, state the rollback plan, list what is excluded, and say whether post-upgrade support is included or priced separately.
How long does a Zammad 6.5 to 7.2 upgrade take?
Duration depends on the environment and scope, so ask for a written schedule as part of the fixed scope rather than relying on a general estimate. The main timeline drivers are the number of staging rehearsals, the time needed to migrate and reindex data, the size of the database and attachment store, the number of instances and integrations to test, and how often your change advisory board can approve a production window. Choose the target patch level before you plan. Zammad released 7.2 on 23 September 2026, followed by security releases 7.2.1 and 7.2.2, so confirm which release the schedule assumes. Ask the partner to show the phases, the dependencies between them and the decision points where scope or timing may change.
What must our team provide before an upgrade engagement starts?
Your team needs to provide access, environments and decisions before the work can be scheduled. Provide administrative access to the Zammad hosts, the PostgreSQL and Elasticsearch services, the reverse proxy, DNS and any identity provider used for single sign-on. Provide a staging host that mirrors production in operating system, PostgreSQL 15 or newer, Redis 7 or newer, Elasticsearch and the reverse proxy. Agree a backup window and confirm that a full backup can be restored and tested before cutover. Name one decision maker who can accept scope changes, approve the production window and call a rollback. Also supply an inventory of email channels, integrations, custom code and users who depend on them, so testing covers what the business actually uses.
Can an internal team upgrade Zammad 6.5 to 7.2 without outside help?
An internal team can complete the upgrade without outside help if it already has the required skills and the time to test properly. The work touches several areas. Linux administration covers service management, packages and the operating system support list. PostgreSQL skills are needed for dump, restore and any move from MySQL. Elasticsearch experience is needed to plan indexing, reindexing and cluster health. Reverse proxy skills cover nginx or Apache configuration and Content Security Policy headers. Multi-instance deployments also need Redis and Memcached knowledge. Teams without these skills in-house, or without spare capacity during the change window, often bring in a partner for a fixed scope so that planning, testing, backups and documentation are handled before the production cutover.
What does a Zammad support subscription cover compared with an implementation partner?
A Zammad self-hosted support subscription covers product support from Zammad, and Zammad sets its terms. According to the Zammad pricing page, the Business tier costs 2,999 EUR per year with a 6-hour response time, Enterprise costs 5,999 EUR per year with a 4-hour response time, and Corporation costs 9,999 EUR per year with a 2-hour response time. Confirm current pricing and terms on the Zammad pricing page before budgeting. An implementation partner, by contrast, plans, executes and documents the upgrade in your environment under a written scope. The two can complement each other: the subscription answers product questions, while the partner carries the migration, testing, backup and cutover work. Note that Zammad's Kubernetes support covers only the application, not Kubernetes itself.
Which checks should engineers run before the Zammad 7.2 cutover?
Start by checking the operating system against the Zammad software requirements and the release notes, since support lists change between releases. Confirm PostgreSQL is version 15 or newer and Redis is version 7 or newer, then verify the Elasticsearch version named in the release notes and plan a full reindex after migration. Test the reverse proxy configuration in nginx or Apache, including Content Security Policy headers, websocket traffic through Redis, and attachment uploads. On multi-instance deployments, confirm Memcached is reachable from every node. Test each email channel, phone and form integration, and each single sign-on provider such as SAML or OpenID Connect. Restore a recent backup to the staging host and confirm the application starts and tickets, users and attachments are intact before scheduling the production window.
How DeployOpen works on this
DeployOpen plans the Zammad 6.5 to 7.2 upgrade as a fixed-scope engagement in your own infrastructure, starting from your current database, search, reverse proxy and operating system versions. The work covers the MySQL to PostgreSQL move, replacement of removed Slack and Twitter integrations and the Elasticsearch reindex, with each step tested and documented before handover.
How we scope
- A written scope lists the Zammad 6.5 instance, integrations and hosting model to be upgraded to 7.2.
- We check the operating system, PostgreSQL 15 or newer, Redis 7 and reverse proxy versions before any change.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Plan the MySQL to PostgreSQL data move with a rehearsed cutover, backup point and rollback path.
- Map the Slack and Twitter integrations that Zammad 7.2 removes to replacement channels agreed with your support leads.
- Schedule the Elasticsearch reindex and nginx or CSP header changes in a staging copy first.
How we hand over
- Test login, ticket flow, email channels, search results and attachment indexing against a written checklist.
- Document the final versions, configuration changes, rollback steps and post-upgrade verification results.
- Walk your administrators through the runbook so your team can operate the upgraded system.
How we support
- Confirm security releases for both the 6.5 and 7.x lines, including 7.2.1 and 7.2.2, before scheduling patches.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask whether your Zammad support subscription covers the upgrade window and its response times.
