Zammad vs Znuny: which to choose

Zammad vs Znuny: when each one is the right helpdesk

If you are replacing OTRS or an older helpdesk, the first question is how much of your current setup must survive the move. Zammad fits when you want a move to a modern stack: a Ruby application backed by PostgreSQL 15 or newer and Redis 7 or newer, with a migrator that covers OTRS alongside Freshdesk, Kayako and Zendesk. It also fits when you want paid support tiers from the vendor, with self-hosted plans listed at 2,999, 5,999 and 9,999 euros per year. Zammad's own pricing page states that self-hosted customers handle updates, backups and availability, so that work stays with your team or your implementer.

Znuny fits when staying close to OTRS is the goal. It is the GPL-3.0 continuation of OTRS Community Edition 6.0.30, so your Perl-based customizations, agent workflows and ITSM habits are more likely to carry over with less rework. It runs on Linux with Perl 5.16.0 or higher, and it offers two release lines, the current feature line (7.3.8 in October 2026) and the LTS line (6.5.26), so you can pick the cadence that matches your change window. Confirm with Znuny GmbH which line and database versions your existing modules support before you commit.

The decision turns on three things. First, how much OTRS customization must survive: list every custom module, template and ACL, then test each one against both platforms, since Zammad is a rebuild rather than a fork. Second, the database and team skills you have, because Zammad needs PostgreSQL and Redis while Znuny supports MySQL, MariaDB, PostgreSQL and Oracle and depends on Perl and Apache with mod_perl2. Third, how you want to buy support: a fixed annual subscription from the Zammad vendor, or professional services from Znuny GmbH on a scope you agree in writing.

Which helpdesk fits which team situation

This table maps common team situations to the better fit between Zammad and Znuny and names the condition that would reverse the choice. Read each row as a starting point, then confirm the points in the last column against your own OTRS instance and team skills.

Situation	Better fit and why	The other option wins when
Planned exit from OTRS with no custom code	Zammad, because it ships a migrator for OTRS and gives agents a modern interface without keeping the Perl codebase in place	Your team needs ITSM-style change and configuration workflows that depend on OTRS features you have not yet mapped to Zammad
OTRS estate with heavy custom Perl modules	Znuny, because it keeps the OTRS codebase and API so existing modules can be ported in place rather than rewritten	You are willing to rebuild custom logic as Zammad configuration or API integrations, and the rebuild effort is accepted up front
Team without Perl skills	Zammad, because day-to-day administration and extension rely on its Ruby on Rails stack and documented API rather than Perl	Your existing staff already maintain Perl and Apache mod_perl2 well, so Znuny's upkeep stays within current skills
Must stay on MySQL or Oracle	Znuny, because its README lists MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later	You can move to PostgreSQL 15 or newer and Redis 7 or newer, which Zammad requires, as part of the project
Team buying support from one vendor for the product	Zammad, because it sells self-hosted support subscriptions (Business, Enterprise, Corporation) from the same vendor that develops the product	Your procurement favors a German-based services provider for OTRS-family software, in which case Znuny's services from Znuny GmbH fit better
Need for a long-term support line with a stable upgrade path	Znuny, because it publishes an LTS line (Znuny LTS 6.5.26 listed in October 2026) alongside the feature line (Znuny 7.3.8)	You prefer one actively developed release line and accept a faster upgrade cadence, which Zammad 7.2 and its security releases reflect
Search and reporting depend on large attachment volumes	Zammad, because it documents Elasticsearch for faster search, reporting and attachment content search, though it is optional	You can run and size Elasticsearch-equivalent search within Znuny's OTRS-based stack and your current reporting already works
Team that also needs a cost-controlled, self-run deployment with no vendor contract	Either option is viable, since Zammad has no license fee when self-hosted and Znuny is GPL-3.0; the deciding factor is the effort to migrate and run each	Confirm with each vendor the support scope, the cost of any retained custom work, and the time to migrate your data before deciding

How Zammad and Znuny are built and deployed

Zammad and Znuny solve the same helpdesk problem with very different stacks, so the choice shapes your database, cache, search and patching routine. The cards below cover what each component means for day-to-day operations and which checks to run before you commit.

Application stack and runtime

Zammad is a Ruby application that stores its content in PostgreSQL 15 or newer, while Znuny is written in Perl and runs on Apache 2 with mod_perl2 recommended. Your team needs to be comfortable patching the runtime that matches the product you pick. Ask Zammad or Znuny for their current runtime versions and confirm they match your OS support window before you size the server.

Database support

Zammad requires PostgreSQL 15 or newer. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. If your database standard is MySQL or Oracle, Znuny fits existing skills more easily, while Zammad needs a PostgreSQL platform that meets its minimum version.

Redis and realtime

Zammad requires Redis 7 or newer for realtime websocket communication. Znuny does not depend on Redis in the same way, so a Zammad deployment adds a second stateful service to back up, monitor and patch. Check whether your platform team already runs Redis under support before choosing Zammad.

Search with Elasticsearch

Zammad uses Elasticsearch for faster search, reporting and searching email attachment content. It is optional but strongly recommended, and without it search is very limited. Budget for an extra cluster to run, size and upgrade if you need full ticket and attachment search, and confirm search needs with your agents before you decide.

Reverse proxy and web tier

Zammad supports Nginx or Apache as the reverse proxy. Znuny is normally served by Apache 2 with mod_perl2, which keeps the web tier on one server family. Decide which web server your security team already hardens and monitors, because TLS, header and access-log standards will apply to whichever one you pick.

Install methods and Kubernetes scope

Zammad documents package installation, Docker Compose and a Helm chart. Its Kubernetes support covers only the Zammad application, not Kubernetes-specific issues, so your platform team owns the cluster, ingress and storage. Znuny is installed on Linux, preferably Debian or Red Hat. Confirm the support boundary in writing before you standardize on a container platform.

Multi-instance caching

Zammad needs Memcached for multi-instance deployments such as containers or cluster nodes, while single installations can use the file system cache. Adding Memcached is a further component to run, secure and monitor. If you plan several Zammad nodes behind a load balancer, include Memcached in the architecture review and the operations runbook from the start.

Capabilities that decide the shortlist, and what to confirm

This table sets the requirements that usually narrow a Zammad and Znuny shortlist, with the supplied facts for Zammad and the items to confirm for Znuny. Read the rows where the Znuny cell says to confirm as open questions for the vendor, not as gaps in the product.

Capability	Zammad	Znuny
License	AGPL-3.0, with self-hosted use carrying no license fee	GPL-3.0, a continuation of OTRS Community Edition 6.0.30
Database requirement	PostgreSQL 15 or newer as the content store	MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later, or Oracle 19c or later
Cache and realtime	Redis 7 or newer for websockets; Memcached needed for multi-instance deployments	Confirm cache and realtime components for your chosen deployment with Znuny
Search	Elasticsearch is optional but strongly recommended for faster search, reporting and attachment content	Confirm the search and attachment indexing options and their limits with Znuny
Identity options	SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab among other providers	Confirm supported SSO and directory options, including SAML and OIDC, with Znuny
Migration from OTRS	Includes an OTRS migrator alongside Freshdesk, Kayako and Zendesk migrators	Confirm the migration path and tooling for your OTRS version with Znuny or a partner
Release cadence	Zammad 7.2 released September 23, 2026, with security releases 7.2.1 and 7.2.2, plus a 6.5.5 security release on October 15, 2026	Znuny 7.3.8 and LTS 6.5.26 are the latest listed releases in October 2026; confirm the support window for each line
ITSM positioning	Positioned as an omnichannel helpdesk and ticketing system; confirm ITSM process coverage for your use case	The README describes it as a ticketing system for customer service, help desk and ITSM; confirm which ITIL processes it covers for you

What is free and what is paid in each

Zammad is licensed under the GNU Affero General Public License version 3, and self-hosted Zammad carries no license fee. The money you spend comes from your own infrastructure, your staff time and any paid support you choose to buy. Zammad sells three self-hosted support subscriptions, and its pricing page states that self-hosted customers handle updates, backups and availability themselves.

AGPL-3.0 license: The software is free to self-host. The AGPL has network-use obligations for modified versions, so have counsel confirm how they apply to any customizations you build.
Business support at 2,999 EUR per year: The entry self-hosted support subscription on the Zammad pricing page.
Enterprise support at 5,999 EUR per year: The middle self-hosted tier. Confirm in writing which response times and channels this tier includes.
Corporation support at 9,999 EUR per year: The highest listed self-hosted tier, aimed at teams that need the most support scope.
Hosted plans from 7 EUR per agent per month: The alternative where Zammad runs the service. Hosted cost scales with the number of agents, while self-hosted support is priced per year.

Before budgeting, check the current pricing page and the scope of each support tier in your written quote.

How identity integration and custom code differ between the two

Identity integration and custom code often decide an OTRS replacement more than feature lists do. An OTRS estate usually has single sign-on or directory sync wired to agents and customers, plus business logic built by the team that ran it. Both have to survive the move, so confirm them before choosing a platform. Zammad's documented third-party login covers SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers, which gives a clear starting point for agent sign-in. Confirm that your identity provider and attribute mapping match what Zammad's admin documentation describes, and test role and group assignment with a pilot account before cutover.

Data that does not fit a migrator needs another route. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and it documents importing other systems through its API or through custom development from Zammad. If your OTRS data includes custom dynamic fields, queues or article types that the migrator does not carry across, ask Zammad or a migration partner how each one maps and what the API import effort looks like. Get that answer in writing as part of the scope, since it drives most of the one-time migration cost.

For Znuny, the main risk runs the other way. OTRS installations often carry custom Perl modules, template overrides, and ticket logic that sits inside the application code. Znuny continues the OTRS Community Edition 6.0.30 codebase, so those modules will usually need review rather than a direct copy. Inventory every custom module, config override and scheduled job, and record which ones depend on the Perl API. The Znuny documentation portal at doc.znuny.org covers the current feature version, the latest LTS version, agent material, developer documentation and the Perl API, so use it to check each custom item against the release line you plan to run. Confirm the identity options for Znuny with its maintainers or your own environment before you decide, because identity support is not something this comparison can state from the supplied facts alone.

Moving an OTRS estate to Zammad: what transfers and what is rebuilt

This sequence separates what Zammad's OTRS migrator carries across from what your team must rebuild, so cutover happens on a tested copy and not on hope. The output is a Zammad instance that agents have validated against real tickets, with a documented rollback position for the old system.

Inventory queues, roles, SLAs and integrations
The OTRS administrator and a team lead list every queue, group, role, customer company, SLA, custom dynamic field, ticket state, priority, and automation such as GenericAgent jobs, postmaster filters and notification rules. Each item is tagged as migrate, rebuild or retire, and every external integration (email intake, LDAP, monitoring, asset tools) gets an owner. The check is a signed inventory that maps each OTRS object to a Zammad equivalent or to a named rebuild task. Confirm with Zammad and your own admins how each OTRS feature maps before you commit to a design.
Build the Zammad stack on PostgreSQL 15 and Redis 7
The platform engineer deploys Zammad in your environment using the install method your standards allow, with PostgreSQL 15 or newer for content and Redis 7 or newer for realtime websocket traffic. Choose Nginx or Apache as the reverse proxy and decide whether Elasticsearch is in scope, since the prerequisites page treats it as optional but strongly recommended for search and attachment indexing. If you run more than one instance, plan Memcached as well. The check is a working test instance that loads, sends and receives email, and passes the health checks your team defines.
Run the OTRS migrator on a copy
Restore a recent backup of the OTRS database and file storage into a separate environment, then run Zammad's OTRS migrator against that copy. The migration team records the run log, counts of tickets, articles, customers and attachments, and any records the migrator skipped or altered. Repeat the run until the output is stable and the counts reconcile with OTRS. Production OTRS stays untouched throughout. The check is a reconciliation report that a second person has reviewed.
Rebuild workflows, roles and identity
Recreate groups, roles, escalation and SLA rules, triggers, macros and overviews in Zammad, using the inventory as the specification. Configure authentication through the identity provider you use, such as SAML or OpenID Connect, and align agent and customer accounts with your directory. Anything the migrator did not carry across, including custom integrations, is either rebuilt through the Zammad API or scoped as custom development. The check is a configuration review in which each inventory row has a completed Zammad object and a test case.
Test with real agents on migrated tickets
Ask a representative group of agents to work real migrated tickets in the copy, covering inbound email, replies, merges, reassignments, SLA timers and reports they rely on each day. Log defects with the inventory row they affect, fix them, and re-run the migration when the source data needs correction. Agents also confirm that search results and attachments behave as expected in their daily work. The check is a signed acceptance list with no open high-severity defects.
Cut over and plan the rollback path
Schedule a freeze window for OTRS, run the final migration delta, switch mail routing and integrations to Zammad, and confirm that new tickets arrive in the right queues. Keep the OTRS server and its backups read-only for a period your governance team sets. The check is a live queue with mail flowing correctly and a documented decision point for reverting. Note that moving back from Zammad to OTRS or Znuny is a second migration with its own mapping work, so the rollback plan should be tested as carefully as the forward path.
Retire OTRS and document the new estate
After the agreed read-only period and a clean audit of ticket access, decommission the OTRS application, its scheduled jobs and its database, keeping only the archives your retention policy requires. Document the Zammad configuration, the integration owners, the backup and update procedure, and the admin runbook for the team that will operate it. The check is a retirement record and a runbook that the operations team has walked through once.

What drives the running cost of each helpdesk

Running Zammad or Znuny costs are mostly people and platform work, not license fees, since both are open source. The cards below separate what you pay a vendor, what you pay your own staff or a partner for, and what recurs every year, so you can request comparable quotes.

Infrastructure and database hosting

Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for search. Znuny supports PostgreSQL 12.0 or later, MySQL 8.0 or later, MariaDB 10.3 or later and Oracle 19c or later. Ask each bidder to price the database, cache and search nodes, backups and the load balancer or reverse proxy separately, since these recur monthly and grow with ticket volume and attachments.

Staff skills for each stack

Zammad is a Ruby on Rails application, so operators need Rails, Redis and PostgreSQL skills, while Znuny runs on Perl with Apache 2 and mod_perl2 recommended. Ask who on your team or your partner's team already runs these stacks, because a skills gap is often the largest recurring cost. Price training or a handover as a one-time item and on-call coverage as a recurring one.

Support subscription or services contract

Self-hosted Zammad has no license fee, but Zammad sells self-hosted support subscriptions at 2,999, 5,999 and 9,999 euros per year, and its pricing page states that self-hosted customers handle updates, backups and availability. Znuny offers professional services from Znuny GmbH in Berlin. Ask whether a Znuny quote includes any vendor support, which tier is priced, and whether the cost recurs annually.

Upgrade and security patch effort

Znuny maintains a feature line (7.3.8) and an LTS line (6.5.26), while Zammad shipped security fixes in parallel on 6.5 and 7.x. Each line you run needs its own test window and change record. Ask each partner how many release lines they will patch, how often they will apply security releases, and whether that work is a fixed-scope project or a retainer.

Custom development

Both platforms can be extended, but the scope of extension drives cost. Zammad documents an API for importing other systems and allows custom development from Zammad, while Znuny exposes a Perl API and developer documentation. Ask for custom work as a separate line item with acceptance criteria, and note that every custom change adds a patch-compatibility test on each upgrade.

Rebuilding integrations and migration

Moving from OTRS or another helpdesk means rebuilding mail channels, LDAP or SSO, asset links and reporting. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, which can shorten one-time migration work for OTRS sources. Ask bidders to list each integration, the cutover plan, and whether any data mapping is excluded from the quote.

Where OTRS-to-Zammad and OTRS-to-Znuny projects usually run long

The effort in an OTRS migration usually sits in the work around the platform, not in the platform itself. Whether the target is Zammad or Znuny, the projects that run long tend to stall in the same places: custom dynamic fields that have no clean equivalent, ticket states and queues that were built up over years and need a deliberate mapping, and email channels that must be reconnected, tested and cut over without losing inbound mail. Before any data moves, list every custom field, state, priority, queue and salutation in the OTRS system and decide for each whether it maps, merges, or is retired. Confirm with the vendor how the chosen migrator handles your specific objects, since the Zammad migrators cover OTRS as a source but your customizations will still need a mapping decision.

Three other items consistently add weeks. Identity rollout is one: if agents sign in through LDAP or SSO today, confirm how group membership and role assignments will carry over before the cutover, not after. Historical attachments are another, because migrating years of ticket attachments can change storage sizing, search indexing and retention rules, so decide up front which history must be searchable and which can be archived. Agent retraining and parallel running complete the picture. Running both systems for a period doubles the places a ticket can be answered, so define which system owns new tickets on which date and who checks the overlap.

The overlap of old and new systems and the number of integrations drive effort more than the choice between Zammad and Znuny. Each connected tool, such as monitoring alerts, a CMDB feed, or a billing system that reads ticket data, needs its own test and its own cutover step. Before work starts, agree a written scope that lists every integration, field mapping and channel, and define acceptance tests for each one, such as a set number of sample tickets migrated with matching attributes, inbound mail verified end to end, and a named sign-off from the service desk lead. Ask any implementation partner to price the work against that scope in writing so that changes are visible as change requests rather than hidden overruns.

What buyers ask before hiring help with a helpdesk move

What drives the cost of migrating from OTRS to Zammad or Znuny?

The biggest driver is how much of your OTRS setup has to carry over: queues, dynamic fields, state and priority mappings, SLAs, automation rules, customer and agent accounts, and the volume and age of ticket history. Zammad includes migrators for OTRS, so the question is how much of your customization maps cleanly and how much needs custom work. Znuny keeps the OTRS data model, so the migration is usually an upgrade path rather than a data move, but custom Perl modules still need review. Ask any provider for a written scope that lists each object type, the data volume, and who tests the result. Costs recur only for ongoing support, and the one-time portion covers analysis, migration, testing and cutover.

How long does a helpdesk migration take, and what sets the duration?

No supplied figure gives a typical duration, so treat any number you see with caution and ask for your own estimate. The main variables are the number of custom fields and workflows, how many integrations (email, phone, chat, LDAP or SAML, and reporting) must be rebuilt, the size of the ticket archive, and how many test cycles your staff can give. Teams that run a parallel period before cutover usually need more time than teams that switch in one window. Ask for a plan with milestones, a test exit criteria list and a rollback step, and confirm that the timeline is written into the agreed scope before work starts.

Can our team migrate from OTRS without outside help?

Yes, a team with Linux, database and Perl or Ruby experience can often run the migration internally, provided it has time, a test environment and clear ownership. The skills gap usually sits in custom OTRS code, database migrations and email routing, not in the ticket data itself. Check whether your OTRS version and add-ons have documented upgrade or migration steps, and confirm the target platform's migration tooling against your current version before committing. A fixed-scope engagement from DeployOpen can cover planning, migration, testing, documentation and handover, which suits teams that lack spare engineering capacity during the cutover window.

What does the work need from our own staff?

Expect your staff to provide process knowledge that no vendor can supply: which queues matter, which SLAs are contractual, who approves changes to routing, and which reports leadership relies on. Your database and system administrators need access to staging and production, and your security team should review authentication, email and network changes. Agents need time for user acceptance testing, and someone must own the cutover decision. Ask the provider to name the roles it expects from your side in the written scope, so you can plan the time before the project starts.

Do Zammad's paid support plans cover self-hosted upgrades?

Zammad's pricing page lists self-hosted support plans at 2,999, 5,999 and 9,999 euros per year, and it states that self-hosted customers handle updates, backups and availability themselves. That means the support plan does not replace your upgrade process. Upgrades still need a staging test, a backup, and a window for your team or a service provider to carry them out. Ask Zammad exactly what each plan includes in response times, upgrade help and escalation before you rely on it. The plan fee is recurring, and the upgrade, backup and monitoring work is an ongoing internal or contracted cost.

How should a small team choose between Zammad and Znuny?

Choose Zammad if you want to leave the OTRS data model and interface behind, your team is comfortable with Ruby, PostgreSQL 15 or newer and Redis 7 or newer, and you can take on a more modern stack. Choose Znuny if your team knows OTRS well, relies on OTRS-specific customizations, and wants to keep the same administration model while using the Znuny LTS line for long-term stability. Small teams should weigh the number of engineers who can maintain each stack, because a platform nobody on staff can patch becomes a risk. Run a short proof of concept with your own top ten workflows before deciding.

How would switching platforms later work?

Switching later is possible but not free. Your ticket data, attachments, customer records and automation rules will have to be exported and mapped again, and integrations (email, LDAP or SAML, reporting, and any APIs) will need rebuilding. Keeping a clean export of ticket history, a documented list of custom fields and workflows, and a tested restore procedure makes a future move much cheaper. Ask any provider how it would export your data, in which formats, and whether it has tested that export in your environment, and record those answers in the handover documentation.

How DeployOpen helps choose, implement and migrate

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Zammad vs Znuny, that means turning the choice between a modern Ruby helpdesk and an OTRS-based ITSM line into a written, fixed-scope plan your team can check.

How we scope

Written scope lists the ticket channels, ITSM processes and integrations your team needs before any build starts.
The scope records which OTRS or older helpdesk data is in migration, and which history stays archived.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.

How we build

Install and configure the chosen platform in your cloud account, data center or air-gapped network.
Map identity, LDAP or SSO, mail channels and PostgreSQL hosting to your existing standards during build.
Test migrated tickets, queues, roles and automations in a staging copy before any cutover is approved.

How we hand over

Deliver runbooks for installation, backups, upgrades and rollback, written for your own operations staff.
Document the migration mapping, known gaps and the decisions made, so auditors and future admins can follow them.
Walk your administrators through daily tasks and the upgrade path for whichever platform you run.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover tracking of Zammad or Znuny release lines and planned upgrade windows in your environment.
Confirm with each vendor which support tier, LTS line or subscription your organization needs before signing.

Zammad vs Znuny