Von OTRS zu Zammad – 50.000 Tickets finden ein neues Zuhause

Der Wechsel von OTRS zu Zammad ist für viele Organisationen mehr als nur ein technisches Upgrade – es ist ein Schritt hin zu einer souveränen, modernen und hochverfügbaren Ticketing-Infrastruktur. In diesem Blogpost beschreiben wir detailliert, wie wir eine Migration von 50.000 Tickets von einer nicht-hochverfügbaren OTRS 6 Instanz auf eine in Kubernetes betriebene self-hosted Zammad-Instanz erfolgreich umgesetzt haben.

Wir gehen dabei sowohl auf die technischen Vorbereitungen ein, als auch auf Herausforderungen, Best Practices und konkrete Handlungsempfehlungen für alle, die eine ähnliche Reise planen.

Warum von OTRS zu Zammad?

OTRS ist seit vielen Jahren ein Standard im Helpdesk-Umfeld, aber viele Unternehmen stoßen mit OTRS 6 an Grenzen: fehlende moderne UI, eingeschränkte Skalierungsoptionen und oftmals eine mangelnde Hochverfügbarkeit. Zammad hingegen bietet:

• Moderne Architektur: Rails, Websockets, Elasticsearch
• Skalierbarkeit: Sehr gut für containerisierte Umgebungen geeignet
• Community und Open Source: Lebendige Entwicklung, transparente Weiterentwicklung
• Nahtlose Migration: Mit offiziellen Migrator-Plugins

Gerade im Kontext von Cloud-native Umgebungen und Kubernetes spielt Zammad seine Stärken aus. Mit dem offiziellen Helm Chart für Zammad lässt sich eine Instanz nicht nur schnell bereitstellen, sondern auch resilient, hochverfügbar und skalierbar betreiben.

Ausgangssituation

• Altsystem: OTRS 6, single-node, keine Hochverfügbarkeit
• Zielsystem: Zammad in Kubernetes mit Helm Chart, hochverfügbar
• Datenvolumen: ca. 50.000 Tickets

Die Herausforderung: Eine Migration dieser Größe lässt sich nicht über die Zammad-Weboberfläche durchführen. Die UI-Import-Funktion ist für kleinere Umfänge geeignet, bei fünfstelligen Ticketzahlen stößt man jedoch an Grenzen.

Die Lösung: Migration über das OTRS-Migrator-Plugin und die Zammad Rails-Konsole.

Import vorbereiten

1. OTRS vorbereiten

Damit OTRS die nötigen Daten für Zammad bereitstellen kann, müssen zwei Plugins installiert werden:

• Znuny4OTRS-Repo: Download
• OTRS Migration Plugin (ZammadMigrator): Download

Wie die Installation von Packages in OTRS funktioniert, ist hier beschrieben: OTRS Package Manager.

Nach der Installation stellt OTRS eine API-Schnittstelle für den Migrator bereit, die Zammad später abruft.

2. Zammad vorbereiten

Unsere Zammad-Instanz wird in Kubernetes mit dem Zammad Helm Chart betrieben. Um den Import zu starten, benötigen wir Zugriff auf den zammad-railsserver Pod:

kubectl exec -it <zammad-railsserver-pod> -- /bin/bash rails c

In der sich öffnenden Rails-Konsole konfigurieren wir die Import-Parameter:

Setting.set('import_otrs_endpoint', 'https://otrs.example.com/otrs/public.pl?Action=ZammadMigrator') Setting.set('import_otrs_endpoint_key', 'API_KEY') Setting.set('import_mode', true) Setting.set('system_init_done', false)

Damit signalisiert Zammad: „Die Instanz ist frisch, noch nicht initialisiert, und wir wollen Daten aus OTRS importieren."

Import durchführen

Der eigentliche Import wird ebenfalls in der Rails-Konsole gestartet:

Import::OTRS.start

Zammad verbindet sich nun mit der OTRS-API und importiert schrittweise:

• Benutzer
• Kunden
• Tickets (inkl. Artikel, Attachments, History)

Bei 50.000 Tickets bedeutet das: Die Datenbank und Elasticsearch müssen ausreichend dimensioniert sein.

Ressourcenanforderungen

• Elasticsearch
  • 8 Cores
  • 32 GB RAM
  • Mindestens 50 % des RAM für den Java Heap
• PostgreSQL
  • 4 Cores
  • 16 GB RAM
  • shared_memory: mindestens 4 GB

Diese Ressourcen sind kein Luxus, sondern Grundvoraussetzung für eine performante Migration und einen stabilen Betrieb danach.

Nach dem Import

Wenn der Import abgeschlossen ist, muss Zammad aus dem Importmodus zurückversetzt werden:

Setting.set('import_mode', false) Setting.set('system_init_done', true) Rails.cache.clear

Anschließend empfiehlt es sich, den zammad-init Pod neu zu starten:

helm upgrade <release-name> zammad/zammad

Der zammad-init Pod übernimmt die Reindexierung in Elasticsearch, was bei größeren Ticketmengen einige Zeit in Anspruch nehmen kann. Erst danach steht die volle Suchfunktionalität in Zammad bereit.

Lessons Learned

1. Planung ist alles: Vor allem die Dimensionierung der Ressourcen entscheidet über Erfolg oder Frust bei der Migration.
2. Clean Start statt Dirty Import: Eine frische Zammad-Instanz ist die sauberste Basis für einen Import. Versuche, in eine bereits produktive Instanz zu importieren, führen meist zu Inkonsistenzen.
3. Monitoring im Blick behalten: Während des Imports laufen Elasticsearch und PostgreSQL unter Volllast. Ohne Monitoring (CPU, RAM, Disk IO) ist man blind.
4. Zeit einplanen: Der Import von 50.000 Tickets dauert – je nach Hardware und Datenstruktur – mehrere Stunden. Das muss in die Migrationsplanung eingehen.

Ausblick

Für viele Organisationen ist der Umstieg auf Zammad der erste Schritt in Richtung einer vollständig cloud-native IT-Service-Landschaft. Die nächsten logischen Schritte können sein:

• Automatisierte Backups & Disaster Recovery für PostgreSQL und Elasticsearch
• Skalierung von Zammad in Kubernetes über horizontales Pod-Autoscaling
• Integration mit externen Systemen (z. B. LDAP, SSO, Monitoring)
• Souveräne Cloud-Strategien: Betrieb in europäischen Infrastrukturen, kombiniert mit Open-Source-Technologien