OTRS-Forks und Nachfolger 2026

Im strukturierten Datenbestand sind OTOBO, Znuny und KIX als aktive Systeme mit dokumentierter Herkunft aus der OTRS Community Edition erfasst. Für jedes System liegen — soweit verfügbar — Angaben zu Lizenz, Architektur, Paketformat, Community-Kennzahlen und Vergleichsartikeln vor.

OTOBO wird von Rother OSS gepflegt und ist im Datensatz unter GPL v3 mit Docker-orientiertem Stack geführt. Znuny wird von Znuny GmbH und Community unter AGPL v3 entwickelt, oft mit LAMP-Architektur. KIX folgt einem eigenen Release- und Lizenzmodell. Weitere Projekte wie oFork werden erst aufgenommen, wenn belastbare Metadaten vorliegen.

Nutzen Sie Systemseiten und Vergleichsartikel im Hub, um Forks sachlich nebeneinander zu stellen — statt sich allein auf Marketingaussagen einzelner Anbieter zu verlassen.

Nein. Der Hub-Datensatz führt die OTRS Community Edition als 2021 eingestelltes Legacy-System. Es gibt keine offiziellen Security- oder Feature-Releases mehr vom ursprünglichen OTRS-CE-Pfad. Bestehende Installationen laufen auf eigenes Risiko weiter — bekannte Schwachstellen werden nicht mehr zentral gepatcht.

Aktive Forks — OTOBO, Znuny, KIX — pflegen eigenständige Codebasen, Release-Zyklen und Sicherheitsprozesse. Sie sind die praktikablen Nachfolger für Teams, die auf OTRS-naher Technologie bleiben wollen, unterscheiden sich aber in Lizenz, Architektur und Ökosystem.

Wer noch OTRS CE betreibt, sollte eine Migrationsstrategie planen: Bestandsaufnahme installierter Pakete, Customizing und Schnittstellen, gefolgt von Testmigrationen zu einem oder mehreren Nachfolgern.

Nicht automatisch. OTOBO, Znuny und teils KIX nutzen das .opm-Paketformat und teilen die OTRS-Herkunft — das erleichtert Migrationen, garantiert aber keine Laufzeitkompatibilität. Entscheidend sind Framework-Version, interne Perl-APIs, Template-Strukturen, Datenbankerweiterungen und Abhängigkeiten zwischen Paketen.

Ein für Znuny 7.x gebautes Modul kann in OTOBO 11.x einwandfrei laufen, eingeschränkt funktionieren oder gar nicht installierbar sein. Gleiches Paketformat ersetzt keine Validierung gegen die Ziel-Framework-Version.

Erstellen Sie vor dem Wechsel ein Inventar aller installierten Pakete und testen Sie jedes geschäftskritische Modul in einer Staging-Umgebung des Zielsystems. Open ITSM Hub zeigt dokumentierte Kompatibilität, ersetzt aber keine eigene Staging-Prüfung.

Arbeiten Sie mit einem dokumentierten Anforderungskatalog und gewichteten Kriterien: Betriebsmodell (Docker vs. LAMP), Lizenz (GPL vs. AGPL), Erweiterungsökosystem, Supportangebote, Migrationsaufwand und Team-Know-how.

Führen Sie Testmigrationen durch, die realistische Datenmengen, Ticket- und Artikelhistorie, Benutzer und Gruppen, Prozesse, Generic-Interface-Webservices, Cronjobs, Anhänge und Berechtigungen abdecken. Vergleichen Sie Backup-, Update- und Monitoring-Prozesse zwischen den Kandidaten.

Open ITSM Hub liefert strukturierte Vergleichsdaten und Verlinkungen zu Paketökosystemen. Die finale Entscheidung sollte auf eigenen Staging-Ergebnissen basieren — nicht auf pauschalen Rankings oder Feature-Matrizen allein.