Zammad vs Znuny

Which helpdesk fits which scenario

This table maps common Zammad and Znuny scenarios to the better fit and the condition that drives the choice. Read each row against your own OTRS customizations, support model and upgrade capacity, since the facts supplied for Znuny's ITSM depth and migration path are limited and should be confirmed directly with each vendor.

How Zammad and Znuny are built and what that means for operations

Zammad and Znuny both put a helpdesk on infrastructure your team runs, but they come from different code bases and carry different service dependencies. The cards below cover the components, the optional search layer, the OTRS lineage, and where vendor support stops and your team's responsibility starts.

Capabilities, licensing and support compared

This table compares license, release currency, prerequisites, search, paid support and identity options for Zammad and Znuny. Where a supplied fact is missing, the cell tells you what to confirm with the vendor, so treat those rows as a checklist for your evaluation rather than a finding.

What each license and paid option covers

What drives the running cost of each platform

Running Zammad or Znuny costs more than the software line item. The cards below separate what you pay once from what recurs, and show which decisions move each cost up or down. Ask every vendor and partner to price against the same written scope so the comparison stays fair.

Moving from OTRS to Zammad or Znuny in order

This sequence moves an OTRS helpdesk to Zammad or Znuny in a controlled order, so each stage ends with evidence that the new system matches the old one before production traffic moves. It also shows which parts of the setup carry over and which must be rebuilt.

1. Inventory OTRS data and configuration

   The OTRS administrator and the service desk lead list what the current system holds: tickets and attachments, queues, states, priorities, roles, groups, SLAs, customer and agent accounts, email and channel settings, scheduled jobs, customizations, and every integration that reads from or writes to OTRS. Record the database version, the file storage location and the size of the ticket archive. The output is a signed inventory that names an owner for each item. Done when every queue and integration has a line in the inventory and nothing is marked unknown.

2. Choose the target platform

   Using the inventory, the team tests Zammad and Znuny against its own scenarios. Znuny keeps the OTRS data model and its customizations most closely, which matters when many custom modules or ITSM processes depend on OTRS behavior. Zammad involves a larger change in the data model and interface, which matters when the team wants a modern Ruby stack and the paid support plans. Confirm each candidate's current release and license terms before deciding. The output is a recorded decision with the reasons and the custom features that were judged against each option.

3. Build a test environment with target prerequisites

   The platform team installs the chosen target in an isolated environment inside the client's own infrastructure. For Zammad, confirm the PostgreSQL and Redis versions in the software prerequisites documentation and decide whether Elasticsearch is needed for acceptable search. For Znuny, confirm the database and web stack against its release documentation. Set up email connectors and identity settings in the test environment as well. The output is a working test instance with a documented build, which can be rebuilt from scripts if the design changes.

4. Map queues, states, users and identity sources

   The migration lead writes a mapping table from each OTRS queue, state, priority, group and role to its equivalent in the target, and notes where no equivalent exists. The team also maps customer and agent accounts to the identity source the target will use, such as LDAP or SSO, and checks which accounts must be created locally. Each unmapped item is assigned a decision: keep, merge, rebuild or retire. The output is a reviewed mapping document approved by the service desk lead and the identity owner.

5. Migrate and validate a copy of production data

   The team takes a copy of the OTRS database and file store, runs the migration tooling or data import for the chosen target, and checks the results. Confirm the migration tooling and data mapping for each target before relying on them, because the supported path depends on the OTRS version and the target release. Validation compares ticket counts by queue and state, samples attachments and article histories, checks timestamps and SLA clocks, and confirms that agents can find known tickets. The output is a validation report listing each discrepancy and its fix.

6. Run parallel intake for a defined period

   The team runs OTRS and the target side by side on a copied intake, with new tickets routed to both systems for an agreed trial window that the client sets. Agents compare routing, notifications and SLA behavior between the two. Differences are logged, fixed and retested. The period and exit criteria are written into the cutover plan before the trial begins. The output is a signed parallel-run record showing that the target handles the agreed workload without unexplained differences.

7. Cut over email and channels

   On the agreed date, the team changes the mail routing, inbound connectors and any web forms or API clients so that new messages reach the target. It confirms that outbound notifications come from the target and that reply threading works for customers who answer old tickets. Integrations that were rebuilt are switched over in the same window. Rollback steps are written and tested before the change. The output is a completed cutover checklist with a test ticket created through every channel.

8. Retire OTRS and its backups

   After a stable period agreed with the client, the team makes OTRS read-only, archives the data the organization must keep under its retention policy, and then decommissions the servers. Backups of the old system are reviewed with the compliance owner, because they may hold personal data that retention rules require to be deleted or kept under controls. The output is a decommission record listing what was archived, where it is stored, who approved the deletion and when the backups were destroyed.

Where implementation projects usually run long

Questions buyers ask before choosing Zammad or Znuny