OTRS Community Edition ist seit dem 1. Januar 2021 End-of-Life. Wer noch auf OTRS 6 oder einer der älteren Community-Versionen läuft, muss migrieren. Die zwei realistischen Zielsysteme im DACH-Open-Source-Markt sind Znuny (direkter OTRS-Community-Fork) und Zammad (modernere Alternative). Dieser Artikel fokussiert auf den Zammad-Pfad, weil er den grösseren Sprung darstellt und das FAQ- oder Wissensdatenbank-Modul am stärksten umkrempelt.
Wir decken FAQ-Modul-Export aus OTRS oder Znuny, Datenformat-Konvertierung in Zammads KB, was beim Wechsel verloren geht, und den Punkt, den die meisten Migrationen überspringen: die Migration ist die Chance, die Wissensdatenbank-Struktur grundsätzlich neu zu denken, statt das alte Mess-Up nur ins neue Tool zu verlagern.
OTRS, Znuny, Zammad: die DACH-Open-Source-Landschaft
OTRS Community Edition war über Jahre das Default-Open-Source-Ticketsystem im DACH-Raum. Mit dem End-of-Life Ende 2020 wurde die OTRS AG geschlossen, kommerzielles OTRS 7/8 ist seitdem nur per Subscription verfügbar. Wer auf der Community Edition geblieben ist, läuft auf einer ungepflegten Codebase ohne Sicherheits-Updates.
Znuny ist der direkte Fork der OTRS Community Edition, gegründet 2020 von der Znuny GmbH. Codebase und Modulstruktur sind weitestgehend identisch, eine Migration von OTRS 6 zu Znuny ist Drop-in. Wer nur die Pflege-Lücke schliessen will, ohne grössere Änderungen, wechselt zu Znuny.
Zammad wurde 2016 von Martin Edenhofer gegründet, der vorher OTRS-Co-Founder war. Tech-Stack ist komplett anders: Ruby on Rails, Vue.js, PostgreSQL oder MySQL, Elasticsearch, Redis. Zammad hat ein modernes Web-UI, eine aktive internationale Community und eine Cloud-Option. Wer die Migration nutzen will, um auf einen modernen Stack zu wechseln, geht zu Zammad.
Vor dem Export: das KB-Audit
OTRS und Znuny haben ein FAQ-Modul (in OTRS-Welt oft "FAQ Add-on" oder "Knowledge Base Module" genannt). Es ist primitive im Vergleich zu modernen KB-Tools: einfache Article-Liste, Kategorien, Sichtbarkeitsregeln. Versionshistorie ist eingeschränkt, oft wird nur die letzte Version in der Datenbank gespeichert.
Vor dem Export ist ein Audit der bestehenden FAQ-Artikel sinnvoll. Welche Artikel sind in den letzten zwölf Monaten aufgerufen worden. Welche referenzieren Features oder Workflows, die nicht mehr existieren. Welche sind interne Notes, die nicht ins kundenfacing Help Center gehören. Faustregel: 30 bis 50 Prozent der OTRS-FAQ-Artikel sind nicht migrationswürdig.
Schritt 1: Export aus OTRS oder Znuny
OTRS und Znuny speichern FAQ-Artikel in der zugrunde liegenden Datenbank. Drei Export-Optionen.
Erstens: direkter SQL-Export aus den FAQ-Tabellen. Die Tabellennamen variieren je nach Version, typischerweise faq_item, faq_category, faq_attachment. Wer SQL kann, exportiert die Daten als CSV oder als JSON-Dump. Vorteil: alle Metadaten sind drin, Nachteil: Format ist OTRS-spezifisch, Konvertierung nötig.
Zweitens: die OTRS- oder Znuny-Generic-Interface-API. Web-Services-basiert, ermöglicht REST oder SOAP. Praxis ist umständlicher als nötig, weil die FAQ-Endpoints nicht prominent dokumentiert sind. Funktioniert, aber nur sinnvoll, wenn ein Drittsystem ohnehin angebunden werden muss.
Drittens: Drittanbieter-Migrationstools wie Help Desk Migration, die OTRS oder Znuny direkt mit Zammad verbinden. Preisrahmen für eine Standard-Migration: typischerweise 500 bis 2000 USD je nach Datenvolumen. Sinnvoll, wenn das interne Team keine SQL- oder Skript-Erfahrung hat.
Schritt 2: Format-Konvertierung in Zammads KB
Zammads KB ist seit Version 3.0 (2019) integriert. Sie unterstützt interne und öffentliche Sichtbarkeit, kategoriebasierte Permissions seit Version 5.1, mehrsprachige Artikel und einen Rich-Text-Editor identisch mit dem Ticket-Composer.
Die Konvertierung von OTRS-FAQ in Zammad-KB-Artikel umfasst typischerweise: Mapping von OTRS-Kategorien auf Zammad-Kategorien, Übernahme der Article-Texte (HTML-zu-Rich-Text), Anhänge separat hochladen und neu verlinken, Übersetzungs-Status setzen (bei mehrsprachigen FAQs), Sichtbarkeitsregeln auf Zammad-Permissions abbilden.
Praktisches Problem: OTRS-FAQ-Artikel haben oft Inline-Bilder als HTML-img-Tags mit relativen URLs zu OTRS-Anhängen. Die müssen nach Zammad rehostet und die URLs umgeschrieben werden.
Schritt 3: Tickets, Kunden, Konfiguration
Die FAQ-Migration ist nur ein Teil. Die meisten Teams migrieren parallel auch Tickets, Kunden-Datenbank und Workflow-Konfigurationen. Zammad bietet ein offizielles OTRS-Import-Skript, das Tickets, Kunden, Queues und Agents überträgt. Es funktioniert für OTRS 6, eingeschränkt für ältere Versionen.
Workflow-Konfigurationen (Automated Responses, Notification-Templates, Escalation-Rules) lassen sich nicht direkt übertragen, weil Zammad eine andere Konfigurationsstruktur hat. Sie müssen neu aufgesetzt werden. Das ist oft der zeitintensivste Teil, drei bis fünf Tage für ein mittelgrosses Setup.
Schritt 4: URL- und Search-Engine-Strategie
Wer OTRS oder Znuny als kundenfacing Help Center betrieben hat (FAQ-Modul war öffentlich erreichbar), muss die URL-Strategie planen. OTRS-FAQ-URLs haben das Format support.company.com/otrs/public.pl?Action=PublicFAQZoom;ItemID=42. Zammad-URLs sehen anders aus.
Ohne 301-Redirect-Mapping verschwinden Google-Rankings über Nacht. Bei kleineren Setups mit nur wenigen FAQ-Artikeln in den Top-10 für relevante Keywords ist das oft kein hartes Problem. Bei grösseren Setups mit hunderten indexierten Artikeln ist eine Redirect-Map Pflicht. Mehr Hintergrund zu URL-Migrationen in unserem Artikel zur Help-Center-Aktualität.
Schritt 5: Cutover und Stabilisierung
Cutover-Checkliste: DNS- oder Reverse-Proxy-Wechsel vorbereitet, 301-Redirects scharf, Zammad-Search-Index aufgebaut und getestet, Agent-Onboarding und neue UI-Workflows trainiert, OTRS- oder Znuny-Daten als Read-Only-Backup mindestens 90 Tage aufbewahrt, Status-Communication an Kunden bei externer FAQ-Sichtbarkeit.
Wer im Quartalsende migriert, läuft Gefahr, dass Eskalationen aus dem alten System nicht sauber im neuen ankommen. Migrations-Termin idealerweise zwei bis vier Wochen vor Quartalsende setzen, damit Restprobleme noch in derselben Berichtsperiode aufgefangen werden.
Die strategische Frage: Re-Strukturierung der KB
Hier ist der Punkt, den die meisten Migrationen überspringen. Die OTRS- oder Znuny-FAQ-Struktur ist meist über Jahre gewachsen, oft ohne klare Taxonomie. Kategorien sind unklar, Artikel-Titel folgen keinem Schema, Suche liefert mittelmässige Treffer. Wer einfach 1:1 nach Zammad migriert, übernimmt diese Probleme.
Die Migration ist die Chance, das KB-Struktur grundsätzlich neu zu denken. Sinnvolle Schritte: Top-10-Suchanfragen aus den letzten zwölf Monaten ziehen, Artikel-Cluster bilden, Lücken im Content identifizieren, Kategorien auf nicht mehr als zwei Ebenen reduzieren, Title-Konvention für neue Artikel etablieren.
Für DACH-Teams, die nach der Migration eine moderne KB-Struktur und automatische Pflege brauchen, ist HappySupport eine Alternative neben Zammad. Mehr zur Architektur in selbst-aktualisierende Wissensdatenbank und in der Anleitung zum Wissensdatenbank-Aufbau.
Häufige Fehler bei der OTRS- oder Znuny-Migration
Erster Fehler: das KB-Audit überspringen und alles migrieren. 30 bis 50 Prozent der FAQ-Artikel gehören nicht ins neue System.
Zweiter Fehler: Anhänge nicht rehosten. OTRS-Anhangs-URLs funktionieren nach dem Cutover nicht mehr, Inline-Bilder werden zu Broken Links.
Dritter Fehler: Workflow-Konfigurationen für die letzte Woche aufsparen. Drei bis fünf Tage Arbeit, die schiefgeht, wenn man unter Zeitdruck arbeitet.
Vierter Fehler: keine 301-Redirect-Map für öffentliche FAQ-Artikel. SEO-Verluste, kaputte externe Links, Kundenfrust.
Fünfter Fehler: die alte KB-Struktur 1:1 übernehmen. Die Migration ist die seltene Chance, die Taxonomie aufzuräumen.
HappySupport im Kontext
HappySupport ist kein Ticketing-System und ersetzt Zammad nicht. HappySupport sitzt neben Zammad als dedizierte Help-Center-Schicht für Kunden, während Zammad das Ticketing, Inbox und Eskalationen übernimmt. Das Modell ist sinnvoll für DACH-SaaS-Teams, die nach der Migration eine moderne Customer-KB brauchen, die mit jedem Produkt-Release aktuell bleibt, statt manuell gepflegt zu werden.
Mehr zur Architektur und zum HappySupport-Ansatz findest du in der DSGVO-konformen Wissensdatenbank, zur Help-Center-Aktualität und zur Vergleichs-Aufstellung in Beste Wissensdatenbank-Software.
