After OTRS: how teams choose an open-source ticket system

For a long time, “open-source ticket system” in the DACH region meant one codebase. Organisations ran the OTRS community edition, bought support if they needed it, and trained agents on a Perl application with queues, roles, and a customer portal. That single line ended when the vendor stopped shipping the community edition and continued the product as commercial OTRS.

What followed was not one successor. It was a split, plus a set of unrelated projects that only look similar on a procurement slide.

The family that still shares a past

Znuny and OTOBO both continue the community-edition line. Agents who learned OTRS still recognise the agent interface, the queue model, dynamic fields, and the generic interface. Migrations from an old community installation are a project, not a fantasy. The data model is familiar on purpose.

They are not the same project.

• Znuny is the fork carried by the team that had maintained the community edition. Operators who want continuity of that line, and a vendor that publishes the open-source product under the Znuny name, start here.
• OTOBO is the line maintained with Rother OSS. Teams that want that release train, its packaging, and its ITSM add-ons start here. OTOBO 11 is the current generation people mean when they talk about the redesigned CMDB, dynamic forms, and container-friendly installs.

Commercial OTRS, the product from OTRS AG, is a different contract. It is not the community edition with a new logo. A team that still says “we run OTRS” may be on a paid current version, on a frozen community version, or on a fork they have not renamed in conversation. The first job in any selection is to name the thing that is actually installed.

The systems that are not forks

Zammad is a frequent name in the same shortlists, and it is not an OTRS fork. It is a separate open-source help desk, with its own interface and its own way of modelling customers and channels. It belongs in a comparison when the requirement is “a modern open-source desk,” and it does not belong in a comparison whose requirement is “keep our OTRS processes, ACLs, and generic-interface integrations.”

Hosted suites — ServiceNow, Jira Service Management, Freshdesk, and the rest — solve a different problem: a vendor operates the platform. They are the right answer when the organisation wants that operating model. They are a category error when the requirement is an on-prem process engine the internal team already knows how to patch.

The questions that sort a shortlist

Feature matrices hide the decision. Five questions sort it faster.

1. Is there a live community-edition database to move? If yes, Znuny and OTOBO are the relevant pair. If no, Zammad and the hosted suites re-enter the list.
2. Who is allowed to operate it? A two-person IT team that will not run Perl, Elasticsearch, and a mail gateway should not pretend otherwise. The software can be open-source and still need an operator.
3. Which integrations are load-bearing? A generic-interface webservice that creates tickets from a monitoring system is a migration constraint. A logo on the customer portal is not.
4. What must stay on the network? If ticket text, attachments, or CMDB records cannot be processed in a vendor cloud, say so before anyone demonstrates an AI add-on.
5. Who answers when a security release ships? Community code without a named maintainer path is a different risk from a fork with a company behind the release.

None of these is a ranking. A municipality, a hospital group, and a software vendor can answer them in opposite directions and all be right.

What changed in the work, not the logo

The daily work on these systems is still queues, roles, SLAs, and the edge where mail becomes a ticket. The new work, where it exists, sits beside that: a CMDB that people will actually maintain, forms that match a process, and — in some desks — a local classifier that suggests a queue without exporting the ticket.

That last piece is optional. A clean queue model and a working mail path still matter more than a model. The desks that get value from classification are the ones that already know which queues are real.

Where to read the comparison

A structured comparison of the OTRS forks and Zammad is maintained on Open ITSM Hub, separate from this article. Softoft’s own work is implementation on OTOBO and Znuny — installation, integration, and on-prem automation — not a claim that one fork wins for every reader.

If you are choosing, start by writing down the system you run today, the integrations you cannot drop, and whether the ticket body is allowed to leave the building. The shortlist gets short after that.