Zammad vs OTOBO: Moderner Helpdesk oder OTRS-Fork?

Die Entscheidung für ein Open-Source-Ticketsystem im Jahr 2026 ist oft eine Richtungsentscheidung zwischen zwei unterschiedlichen Architekturphilosophien. Auf der einen Seite steht Zammad, eine von Grund auf als moderner Helpdesk konzipierte Anwendung auf Basis von Ruby on Rails. Auf der anderen Seite positioniert sich OTOBO, ein Fork der OTRS Community Edition, der die bewährte Perl-Logik des Vorgängers in einen modernisierten, Docker-zentrierten Betriebskontext überführt. Für IT-Leitungen und Administratoren stellt sich nicht nur die Frage nach dem Funktionsumfang, sondern primär nach der langfristigen Wartbarkeit, der Integration in bestehende Infrastrukturen und der Anpassungsfähigkeit an spezifische ITSM-Prozesse.

Beide Systeme werden von deutschen Unternehmen (Zammad GmbH und Rother OSS GmbH) maßgeblich vorangetrieben und unterliegen Open-Source-Lizenzen (GNU AGPL v3.0 bzw. GNU GPL v3.0). Dennoch unterscheiden sie sich in ihrem technologischen Kern und ihrem Ansatz zur Ticketbearbeitung grundlegend.

Architektur und Technologie-Stack: Ruby vs. Perl

Der markanteste Unterschied liegt in der gewählten Programmiersprache und dem daraus resultierenden Framework. Zammad nutzt Ruby on Rails im Backend und Vue.js für das Frontend. Diese Kombination zielt auf eine reaktive Benutzeroberfläche ab, die Echtzeit-Aktualisierungen ohne manuelles Neuladen der Seite ermöglicht. Für die Datenhaltung setzt Zammad primär auf PostgreSQL. Redis wird zwingend für die Echtzeit-Kommunikation zwischen Server und Client benötigt, während Elasticsearch (optional, aber für produktive Umgebungen dringend empfohlen) die Volltextsuche übernimmt Quelle.

OTOBO hingegen basiert auf Perl und nutzt das über Jahrzehnte gewachsene OTRS-Framework. Die Modernisierung zeigt sich hier vor allem im Deployment und in den unterstützten Diensten. OTOBO unterstützt neben PostgreSQL auch MariaDB und MySQL als Datenbanken. Der Webserver-Stack ist flexibel: Neben Nginx und Apache (mit mod_perl) kommt Gazelle zum Einsatz. Ein zentrales Merkmal von OTOBO ist die „Docker-first“-Strategie, die darauf abzielt, die Komplexität der Perl-Abhängigkeiten durch vorkonfigurierte Container-Umgebungen zu kapseln Quelle.

Während Zammad eine monolithischere Web-App-Struktur verfolgt, die stark auf Web-Sockets für die Interaktion setzt, bleibt OTOBO der klassischen Request-Response-Struktur treu, ergänzt diese jedoch um moderne Komponenten wie Elasticsearch für die Suche und Redis als Cache.

Herkunft und Migrationspfade

Die Entscheidung für eines der Systeme hängt oft an der technologischen Historie einer Organisation. OTOBO ist ein direkter Nachfahre der OTRS Community Edition. Das bedeutet, dass die interne Datenstruktur, die Logik der Ticket-Attribute und die Konfigurationsmechanismen (SysConfig) für Administratoren mit OTRS-Erfahrung unmittelbar verständlich sind. Ein Umstieg von OTRS Community Edition auf OTOBO ist als In-Place-Migration konzipiert, die bestehende Daten und Prozesse weitgehend erhält Quelle.

Zammad wurde 2016 als unabhängiges Projekt gestartet, mit dem Ziel, die Defizite klassischer Ticketsysteme durch eine moderne UX zu überwinden. Zammad bietet zwar dedizierte Migrations-Tools für OTRS, Zendesk und Freshdesk an, ein Wechsel bedeutet hier jedoch immer einen Systembruch. Workflows müssen in der Zammad-Logik neu abgebildet werden, was die Chance zur Prozessbereinigung bietet, aber auch initialen Aufwand erfordert.

Funktionsumfang: Helpdesk-Fokus gegen ITSM-Prozesstiefe

Zammad positioniert sich stark als Multi-Channel-Helpdesk. Die Integration von E-Mail, Telefon (CTI), Chat und sozialen Netzwerken wie Facebook oder Twitter ist tief im Kern verankert. Funktionen wie die „AI ticket summaries“, eingeführt mit Version 7.0, zeigen den Fokus auf die Effizienzsteigerung im Agenten-Alltag Quelle. Die Benutzeroberfläche erlaubt es Agenten, an mehreren Tickets gleichzeitig zu arbeiten (Tab-Konzept), ohne den Kontext zu verlieren.

OTOBO hingegen spielt seine Stärken dort aus, wo komplexe IT-Service-Management-Prozesse abgebildet werden müssen. Das integrierte Prozessmanagement erlaubt die Definition detaillierter Workflows, die über einfache Statusänderungen hinausgehen. Mit der Version 11.1 wurden zudem die OAuth-Token-Verwaltung und die OpenID Connect-Anbindung weiter gestärkt. Auch OTOBO integriert mit „Rotobo“ erste KI-Funktionen (derzeit im Beta-Status), bleibt aber in der Grundausrichtung stärker an klassischen ITSM-Strukturen orientiert Quelle.

Betrieb und Deployment im Vergleich

Beide Systeme unterstützen moderne Deployment-Methoden über Docker Compose, bieten aber unterschiedliche Alternativen an:

• Zammad: Ermöglicht die Installation über native Linux-Pakete (.deb, .rpm) oder direkt aus den Quellen. Die Paketverwaltung für Erweiterungen nutzt das .szpm-Format.
• OTOBO: Legt den Fokus sehr stark auf Docker, bietet aber auch eine klassische Linux-Installation an. Erweiterungen werden im .opm-Format (bekannt aus dem OTRS-Ökosystem) verwaltet.

In Bezug auf die Suche nutzen beide Systeme Elasticsearch, um auch bei großen Datenmengen performante Ergebnisse zu liefern. Bei Zammad ist Elasticsearch für Funktionen wie die globale Suche essenziell, während OTOBO Elasticsearch nutzt, um die historisch langsamere SQL-basierte Suche von OTRS zu ersetzen.

Ein wichtiger Aspekt für Admins ist die Überwachung. Zammad bietet eine Health-check API, während OTOBO auf Container-Health-Checks und Daemon-Status-Prüfungen setzt. Die Backup-Strategien sind bei beiden gut dokumentiert, wobei Zammad spezifische Skripte für den Dump von Datenbank und Dateisystem bereitstellt Quelle.

Community und Governance

Beide Projekte folgen einem herstellergeführten Open-Source-Modell. Die Zammad GmbH steuert die Entwicklung von Zammad, während die Rother OSS GmbH hinter OTOBO steht. Ein Blick auf die GitHub-Statistiken (Stand 30.07.2026) zeigt eine höhere Anzahl an Sternen (5800) und Forks (1000) für Zammad im Vergleich zu OTOBO (331 Sterne, 89 Forks). Dies deutet auf eine breitere Entwicklerbasis bei Zammad hin, während OTOBO eine spezialisierte Community aus dem ehemaligen OTRS-Umfeld bedient.

Für wen passt welches System?

Die Wahl zwischen Zammad und OTOBO sollte anhand der folgenden Kriterien getroffen werden:

Zammad ist tendenziell die passendere Wahl, wenn:

• Eine moderne, reaktive Benutzeroberfläche für maximale Agenten-Produktivität priorisiert wird.
• Die Kommunikation über viele verschiedene Kanäle (Chat, Social Media, E-Mail) zentralisiert werden soll.
• Keine Altlasten aus einer OTRS-Installation übernommen werden müssen.
• Ein Stack auf Ruby-Basis in die interne Know-how-Struktur passt.

OTOBO ist tendenziell die passendere Wahl, wenn:

• Eine bestehende OTRS Community Edition Installation migriert werden soll, ohne die gewohnten Logiken aufzugeben.
• Komplexe, mehrstufige ITIL- oder Geschäftsprozesse abgebildet werden müssen, die das OTRS-Prozessmanagement erfordern.
• Eine Docker-zentrierte Infrastruktur bevorzugt wird und Perl-Expertise vorhanden ist.
• Ein klassisches ITSM-System mit CMDB-Optionen (über Add-ons) gesucht wird.

Datenstand und Grenzen des Vergleichs

Dieser Vergleich basiert auf den Spezifikationen und Veröffentlichungen der Projekte bis zum 30.07.2026. Es ist zu beachten, dass sich insbesondere Funktionen im Bereich der Künstlichen Intelligenz (KI) in beiden Systemen in einer schnellen Entwicklungsphase befinden. Während Zammad mit Version 7.0 bereits integrierte Features bietet, sind diese bei OTOBO 11.1 teilweise noch im Beta-Status. Die Performance beider Systeme hängt stark von der korrekten Konfiguration von Elasticsearch und der zugrunde liegenden Hardware ab; pauschale Aussagen zur Skalierbarkeit lassen sich aus den Versionsnummern nicht ableiten.

Fazit

Zammad und OTOBO repräsentieren unterschiedliche Generationen von Ticketsystemen. Zammad bricht mit alten Konventionen und bietet eine hochmoderne Web-Erfahrung, während OTOBO die bewährte und mächtige Funktionswelt von OTRS in die Container-Ära rettet. Beide Systeme sind stabil, aktiv gepflegt und für den Unternehmenseinsatz geeignet.

Um eine endgültige Entscheidung zu treffen, empfiehlt sich ein detaillierter Blick auf die Feature-Matrix in unserem interaktiven Vergleichstool, um spezifische Anforderungen wie LDAP-Anbindung, SSO-Verfahren oder API-Kapazitäten im Detail gegenüberzustellen.