Zammad upgrades and support

Customizations are the most likely cause of a failed Zammad upgrade. The core application is the same for every customer, but each helpdesk carries its own triggers, macros, custom object attributes, ticket workflows, API scripts and integrations. Any of these can break, or quietly change behavior, after a version change. A trigger that fires on a field value, a macro that sets a state the new release renames, or an API client that parses a response differently will not show up in a standard install test. It shows up when agents or customers hit it in production. Treat the customization list as the primary upgrade risk and test it first.

Start by building a regression list from the live configuration, not from memory. Export or record every active trigger, scheduler job, macro, overview, custom object attribute, ticket state and priority rule, group and role-based permission that affects ticket handling, and every external system that calls the Zammad API or receives webhooks from it. For each item, note the owner, the business purpose and the expected result of a typical test case. Include the email and chat channels, because inbound routing and auto-replies are easy to overlook. The list should be short enough that someone can run it in a working session, and complete enough that an agent who uses a macro daily would recognize it on the list.

Run the regression list against a staging copy of the production instance. The staging copy needs the same Zammad version as production, a recent copy of the database and the same integration endpoints or reasonable test doubles for them. Upgrade the copy to the target release first, then execute each test case and record the actual result against the expected one. Keep the test data realistic in shape but free of live customer content, and confirm with your privacy lead how the copy is handled. Pay particular attention to items that depend on Elasticsearch search, scheduled jobs and external API responses, since these behave differently when the environment changes.

For every failing or changed item, make one of three decisions. Fix means the behavior is still needed and a small correction restores it. Rework means the business need stays, but the approach must change, for example by replacing a deprecated field or moving logic into a supported setting. Retire means the item is no longer needed or the new release provides the same result natively. Record the decision, the owner and the retest result in the same document. Do not let decisions stay informal, because the next upgrade will need the same history.

Read the Zammad releases page and the release notes for every version between your current release and the target against your customization list before agreeing a change window. Look for changed field names, removed or renamed settings, altered API behavior and security fixes that touch areas you have customized. The security releases matter here too: fixes are published on both the current minor line and older supported lines, so confirm which line your instance is on and what the target release addresses. Schedule the change window only after the staging results and the decisions for every item are complete, and confirm the rollback plan, including the database backup, before that window opens.

The recurring cost of a self-hosted Zammad helpdesk after go-live has four components, and only one of them is a vendor invoice. Self-hosted Zammad has no license fee, because the software is licensed under the GNU Affero General Public License version 3. What you pay for instead is infrastructure for the application, PostgreSQL and Redis, plus Elasticsearch and Memcached where your deployment uses them; staff time to watch releases and apply minor and security updates; upgrade work when you move between major versions; and any vendor support subscription you choose to buy. Infrastructure and staff time recur every month. Major upgrade projects recur at intervals tied to Zammad's release cycle and the size of your customization, so budget them as a planned line.

Zammad sells self-hosted support subscriptions, which are a separate purchase from any DeployOpen service. According to the Zammad pricing page, the Business subscription costs 2,999 EUR per year with a response time of 6 hours, Enterprise costs 5,999 EUR per year with a response time of 4 hours, and Corporation costs 9,999 EUR per year with a response time of 2 hours. These are vendor list figures, so confirm the current amounts, billing terms and tax treatment on the pricing page or with Zammad before you carry them into a budget. A subscription buys vendor product support. It does not replace the work of deciding when to upgrade, testing your triggers and integrations, or running backups, and your team or a partner still carries that effort.

Decide early which kind of support you need, because vendor product support and implementation support answer different questions. Vendor support helps when Zammad itself behaves unexpectedly, a defect appears in a release, or a security fix needs explanation. Implementation support covers your environment: the reverse proxy and TLS setup, the Elasticsearch index after an upgrade, custom object attributes and triggers that might break on a new version, and the SSO connection. Zammad's Kubernetes documentation states that its support covers only the Zammad application, and Kubernetes-specific issues stay with your platform team or a partner. Check the scope of any subscription in writing before you rely on it during an incident.

For the DeployOpen side, the cost of planned upgrades, release watch and retainers follows from a written scope, and DeployOpen does not publish prices. A retainer is a separate agreement from any Zammad subscription, so the two can run together or one can run without the other. When you request a quote, ask for each recurring item to be listed separately: release monitoring and the staff hours it assumes, the test environment used to rehearse each upgrade, customization regression checks, upgrade windows, the route for vendor subscription tickets, and what triggers a change order. Ask which items are one-time and which recur, so the annual figure matches what you will actually pay.

Before any Zammad upgrade or support work starts, the client must provide access, decisions and sign-offs that DeployOpen cannot make on the client's behalf. The first item is read and change access to the Zammad host or cluster, whether that is a single package installation, a Docker Compose stack or a Kubernetes deployment using the official Helm chart. Ask your platform or infrastructure team to name who holds that access, and confirm in writing which accounts can change the application, the reverse proxy and the underlying nodes. Without this, a plan cannot be checked against the running system.

The second item is database and Redis access for the upgrade plan. Zammad stores its content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime websocket communication, so the upgrade plan needs the versions actually running in your environment, not the versions you remember. Confirm the database owner, who can grant a read-only review account, and whether Elasticsearch and Memcached are in use, since both affect how a release is tested. The database owner should also confirm the current backup schedule before any change is planned.

The third item is a current backup with a tested restore, which is the client's responsibility to produce and verify. Ask the database or platform owner to show a restore from the most recent backup into a separate environment, and record how long it took and which data was checked. Backups must cover the database and the attachment storage, and the Elasticsearch index can be rebuilt if needed but should still be documented. The fourth item is a staging environment, or a budget to create one. Staging should match production in Zammad version, PostgreSQL and Redis versions, reverse proxy and integrations, because regression results from a different setup do not predict production behavior.

The fifth and sixth items are a written list of customizations and integrations with a named owner for each, and a business owner who signs off on regression results. Triggers, macros, custom object attributes, API automations, SSO settings and any mail or phone connectors each need someone who knows what they do and can confirm the expected behavior after the upgrade. The business owner, typically the head of support operations, decides whether a failed test blocks the release. The seventh item is a change window agreed with the helpdesk team, because agents must know when tickets may be delayed.

The client must make three decisions, each with a named owner. The target version, including whether to apply a 7.x minor or security release or move from another major line, is usually owned by the platform engineering lead with the support operations lead consulted. The support tier, chosen from the self-hosted subscriptions Business, Enterprise or Corporation as described on Zammad's pricing page, or a DeployOpen retainer, is a budget and risk decision owned by the CIO or head of IT. The change window is owned by the helpdesk manager. Record each decision in the statement of work so that scope, effort and quotes match what was actually agreed.