OTRS-Forks und Zammad im Vergleich: Fünf Systeme für 2026

Die Entscheidung für ein IT-Service-Management-System (ITSM) oder einen Helpdesk ist für technische Entscheider heute komplexer als vor dem Ende der ursprünglichen OTRS Community Edition im Jahr 2021. Organisationen stehen vor der Wahl, die gewohnte Perl-basierte Architektur durch einen der aktiven Forks wie Znuny oder OTOBO fortzuführen, auf neuere Projekte wie O-Fork zu setzen oder mit Zammad einen technologischen Paradigmenwechsel zu vollziehen. Dieser Vergleich analysiert die fünf Systeme anhand ihrer Architektur, ihrer Sicherheitsstrategien und ihrer betrieblichen Anforderungen für das Jahr 2026.

Technologische Fundamente: Perl-Kontinuität gegen Ruby-Moderne

Die technologische Basis bildet den deutlichsten Unterschied in diesem Vergleichsfeld. Vier der fünf betrachteten Systeme (Znuny, OTOBO, O-Fork und OTRS Community Edition) basieren auf Perl und führen die Tradition des klassischen OTRS-Frameworks fort. Diese Systeme nutzen in der Regel den LAMP-Stack (Linux, Apache, MySQL/MariaDB/PostgreSQL, Perl).

Znuny setzt in der Version 7.3 auf das bewährte Znuny-Framework und erfordert mindestens Perl 5.24. Es unterstützt eine breite Palette an Datenbanken, darunter MariaDB, PostgreSQL und Oracle. OTOBO nutzt ebenfalls Perl, weicht jedoch in der Infrastruktur ab, indem es eine Docker-first-Strategie verfolgt und Komponenten wie den Webserver Gazelle sowie Redis für das Caching integriert. O-Fork (Version 12.0.3) bleibt der klassischen Struktur treu, weist jedoch eine Besonderheit bei der Datenbankunterstützung auf: Es listet explizit MySQL in Versionen kleiner als 8.0 sowie Oracle ab 10g als kompatibel auf.

Dem gegenüber steht Zammad, das auf Ruby on Rails und Vue.js basiert. Offiziell unterstützt Zammad PostgreSQL; Redis 6 oder neuer wird für die Echtzeitkommunikation eingesetzt. Elasticsearch ist laut Dokumentation optional, aber für Suche und Reporting ausdrücklich empfohlen. OTOBO integriert Elasticsearch und Redis in seinen dokumentierten Docker-Stack, während Znuny und die OTRS Community Edition in den erfassten Standardkonfigurationen Datenbank-Volltextsuche verwenden.

Sicherheitsmanagement und Release-Zyklen

Für Administratoren ist die Verlässlichkeit von Sicherheitsupdates ein primäres Kriterium. Zum Datenstand vom 30.07.2026 zeigen sich unterschiedliche Reifegrade in der Governance:

• Zammad: Verfolgt eine strikte Politik mit nummerierten Security Advisories. Die Versionen 7.1.1 und 7.0.3 wurden zeitgleich am 25.06.2026 veröffentlicht, um Sicherheitslücken zu schließen (Quelle: Zammad Advisories).
• Znuny: Veröffentlicht regelmäßig Patches für die aktuelle Feature-Line (7.3.5 am 22.07.2026) sowie für den Long-Term-Support-Zweig (LTS 6.5). Die Sicherheitsankündigungen werden zentral koordiniert (Quelle: Znuny Security Advisories).
• OTOBO: Stellt die GitHub-Security-Infrastruktur für Meldungen und Advisories bereit. Die Version 11.1 erschien am 24.06.2026 und enthält unter anderem OAuth-Token-Management und OpenID Connect.
• O-Fork: Das öffentliche Repository besteht seit Oktober 2025; Version 12.0.3 erschien im Juni 2026. Eine eigene veröffentlichte Security Policy oder ein Security-Kontakt ist im erfassten Datenstand nicht dokumentiert.
• OTRS Community Edition (Centuran): Dieses System befindet sich in einem Wartungsmodus. Das letzte dokumentierte Release 6.0.41 stammt vom 09.12.2024. Es dient primär dem Erhalt bestehender Installationen auf Basis der OTRS-6-Codebasis.

Erweiterbarkeit und das Ökosystem der Pakete

Ein wesentlicher Faktor für die Flexibilität ist die Verfügbarkeit von Zusatzmodulen. Die OTRS-Forks nutzen das .opm-Format (OTRS Package Manager). Im aktuellen Hub-Datensatz sind Znuny 115 Pakete und der OTRS Community Edition 111 Pakete zugeordnet. Die Zahlen beschreiben den Katalogbestand, nicht automatisch die Kompatibilität mit jeder aktuellen Version.

OTOBO sind 53 Pakete zugeordnet; Elasticsearch ist dort Bestandteil des erfassten Stacks. Zammad nutzt das eigene Paketformat .szpm und verzeichnet 54 Pakete. Zusätzlich dokumentiert Zammad REST, GraphQL und Webhooks als Integrationsschnittstellen.

Für die Zukunftsplanung ist auch die Integration von Künstlicher Intelligenz relevant. Zammad hat mit Version 7.0 KI-gestützte Ticket-Zusammenfassungen eingeführt. OTOBO führt in Version 11.1 die KI-Unterstützung „Rotobo“ im Beta-Stadium.

Betriebliche Konsequenzen: Deployment und Migration

Der Aufwand für den Betrieb unterscheidet sich je nach gewählter Infrastruktur-Strategie.

OTOBO und Zammad dokumentieren Docker-Compose als Betriebsweg. Zammad bietet zudem Pakete für gängige Linux-Distributionen an. Znuny lässt sich über Linux-Pakete, Source-Installation oder Docker betreiben; die klassische Apache-/Perl-Architektur bleibt dabei erhalten.

Bei Migrationen innerhalb der OTRS-Familie bleiben Code-Historie und .opm-Paketformat als Gemeinsamkeiten erhalten; die tatsächliche Kompatibilität eigener Pakete, Templates und Datenbankanpassungen muss trotzdem getestet werden. Der Wechsel zu Zammad ist kein In-Place-Upgrade: Prozesse, Integrationen und Datenübernahme benötigen einen eigenen Migrationsplan.

Für wen passt welches System?

Die Wahl des passenden Systems hängt von der vorhandenen Expertise und den funktionalen Schwerpunkten ab:

• Znuny gehört in die Auswahl, wenn LTS 6.5, Oracle-Unterstützung, Generic Interface und ein großer Bestand zugeordneter .opm-Pakete relevant sind.
• OTOBO gehört in die Auswahl, wenn die OTRS-Logik mit einem dokumentierten Docker-Compose-Stack, Elasticsearch, Redis und OpenID Connect kombiniert werden soll.
• Zammad gehört in die Auswahl, wenn Multi-Channel-Ticketing, Ruby on Rails, Vue.js, PostgreSQL sowie REST- und GraphQL-Schnittstellen zum Zielbild passen.
• OTRS Community Edition (Centuran) ist vor allem für Teams relevant, die eine bestehende OTRS-6-nahe Installation weiter pflegen und den Maintenance-Status bewusst akzeptieren.
• O-Fork sollte geprüft werden, wenn dessen AGPL-Lizenz, klassische Apache-/Perl-Architektur und Datenbankunterstützung zum Bestand passen; der noch kleine öffentliche Projekt- und Community-Footprint ist dabei ein eigenes Prüfkriterium.

Datenstand und Grenzen des Vergleichs

Dieser Vergleich basiert auf den Spezifikationen und Veröffentlichungen der Projekte mit Stand vom 30.07.2026. Da sich Open-Source-Projekte dynamisch entwickeln, sollten aktuelle Release-Notes und Security-Advisories vor einer finalen Entscheidung direkt in den Repositories geprüft werden. Insbesondere die Kompatibilität von Drittanbieter-Paketen im .opm-Format kann zwischen den verschiedenen Forks variieren.

Für eine detaillierte Gegenüberstellung einzelner Funktionen nutzen Sie bitte die interaktive Vergleichstabelle, in der Sie die Systeme direkt nebeneinanderstellen können.