KIX vs Znuny: CMDB-Plattform oder klassischer OTRS-Nachfolger?

KIX und Znuny teilen eine OTRS-Herkunft, sind im Betrieb 2026 aber keine austauschbaren Drop-in-Nachfolger. KIX 18 ist als eigenständige Service-Management-Plattform mit Perl-Backend und TypeScript-Frontend dokumentiert und legt den Schwerpunkt auf Tickets plus Assets/CMDB. Znuny bleibt ein Perl-Framework mit klassischem LAMP-Pfad, LTS-Zweig und einem öffentlichen .opm-Paketverzeichnis. Für Administratoren entscheidet sich die Wahl an Betriebsmodell, Asset-Tiefe und der Frage, ob bestehende OTRS-Pakete weiter relevant sind.

Herkunft und Produktlinie

Beide Systeme sind im Hub als aktive Forks bzw. Nachfolger der OTRS Community Edition erfasst. Znuny wird von Znuny GmbH als Fortführung der Community Edition geführt, mit öffentlichem GitHub-Repository und dokumentierter Nähe zu OTRS-6-Installationen. KIX entstand historisch als KIX4OTRS; die aktuelle öffentliche Linie ist KIX 18, bereitgestellt von der KIX Service Software GmbH. Gemeinsame Herkunft bedeutet nicht, dass Oberflächen, interne APIs oder Erweiterungen identisch geblieben sind.

Für eine Migration aus OTRS 6 ist Znuny über die dokumentierten Update-Skripte der LTS- und 7.x-Zweige der konservativere Prüfpfad. KIX 18 ist als Rewrite beschrieben; vorhandene OTRS-Anpassungen müssen dort neu bewertet werden, statt als 1:1-Upgrade angenommen zu werden.

Stack und Betrieb

Znuny dokumentiert Linux-Pakete, Quelleninstallation und Docker auf einem LAMP-Stack (Apache/mod_perl, MySQL/MariaDB/PostgreSQL, optional Oracle). Die Suche läuft standardmäßig über die Datenbank; Redis ist als Cache vorgesehen.

KIX 18 wird öffentlich als Docker-On-Premise-Setup ausgeliefert (Repository kix-on-premise). Der Datensatz nennt MySQL/MariaDB und Redis; PostgreSQL 15 ist in den Versionsnotizen zu 18.37 als Wechselziel für eine spätere Version angekündigt, nicht als bereits belegter Standard. Ein nativer Kubernetes-Operator ist für beide Systeme als unbekannt geführt.

Wer eine einzelne Linux-VM ohne Container-Orchestrierung betreiben will, findet bei Znuny den kürzer dokumentierten klassischen Weg. Wer Docker als Standardbetrieb akzeptiert und Asset-Objekte im selben Produkt erwartet, prüft KIX 18 gegen die eigenen Betriebsvorgaben.

Funktionen: CMDB gegen Paketökosystem

Im Hub-Datensatz sind für KIX integriert: Ticketing, CMDB/Assets, FAQ, Berichte sowie Organisationen und Kontakte. Serviceverträge und News sind als KIX-Pro-Funktionen gekennzeichnet, also nicht als Teil der freien Start-Linie belegt.

Znuny führt Ticketing, Prozessmanagement, Generic Interface, Servicekatalog und Zeitabrechnung als integriert; zusätzliche ITSM- und Integrationspakete liegen im Add-on-Ökosystem. Das öffentliche Paketverzeichnis ist addons.znuny.com. Für KIX 18 ist im Datensatz kein vergleichbares öffentliches .opm-Repository hinterlegt.

Wer eine CMDB im Kernprodukt braucht, muss Znuny über Pakete und eigene Modellierung prüfen. Wer .opm-Kompatibilität und Generic Interface (REST/SOAP) braucht, hat bei Znuny die dichtere, nachvollziehbare Paketlage.

Community, Releases und Nachweise

Znuny 7.3.5 (22.07.2026) und der Zweig 6.5 LTS sind im Datensatz belegt, inklusive Security-Advisories unter znuny.org. Das Haupt-Repository weist zum Stichtag 30.07.2026 582 Stars, 62 offene Issues und ein sehr aktives Forum auf.

KIX 18.37 (28.04.2026) ist als Stabilisierungsrelease dokumentiert. Das öffentliche On-Premise-Repository hat 24 Stars; Issue-Aktivität über 90 Tage ist nicht vergleichbar erhoben. Ein Security-Policy-URL fehlt im Datensatz und bleibt unbekannt. Austausch findet vor allem im KIX-Forum statt.

Sternzahlen und Forenlage ersetzen keine Qualitätswertung. Sie zeigen nur, wo Betriebswissen öffentlich nachgeschlagen werden kann.

Für wen passt welches System?

KIX ist prüfenswert, wenn:

• Asset- und CMDB-Objekte im Kernprodukt liegen sollen, nicht nur als optionales Paket.
• Docker-On-Premise zum vorgesehenen Betriebsweg passt.
• REST-API und ein herstellergeführtes Service-Management-Produkt im Vordergrund stehen.

Znuny ist prüfenswert, wenn:

• Eine OTRS-CE-nahe Perl/LAMP-Umgebung und ein dokumentierter LTS-Zweig benötigt werden.
• Generic Interface, .opm-Pakete und Oracle-Unterstützung relevant sind.
• Die öffentliche Issue- und Forenlage für den Eigenbetrieb mitgenutzt werden soll.

Datenstand und Grenzen

Der Vergleich nutzt die strukturierten Systemdaten des Open ITSM Hub (Znuny-Stand 30.07.2026, KIX-Stand 26.08.2026). Unbekannte Felder — etwa ein Kubernetes-Operator oder eine KIX-Security-Policy — werden nicht ergänzt. Eine Staging-Migration mit realen Assets, Berechtigungen und Schnittstellen bleibt der belastbare nächste Schritt.

Die Live-Tabelle auf dieser Seite und die interaktive Übersicht zeigen die Einzelkriterien ohne Gesamtscore.