Migration von OTRS Community Edition zu OFORK

Die Migration von OTRS Community Edition zu OFORK wird wie ein kontrollierter Systemwechsel behandelt: zuerst wird das bestehende System vollständig gesichert, danach wird OFORK sauber installiert, die bestehende Konfiguration und Datenbasis werden übernommen und anschließend mit dem passenden Migrationsskript aktualisiert.

Dieser Leitfaden beschreibt den Ablauf für eine klassische Linux-Installation unter /opt/ofork. Die Befehle müssen an Ihre Serverumgebung, Datenbanknamen, Benutzer und Pfade angepasst werden.

In diesem Guide: Vorbereitung, Sicherung, OFORK-Installation, Konfigurationsübernahme, Dateirechte, Migrationsskript, Neustart und Fehlerprüfung.

Ziel der Migration

Bei der Migration sollen die wichtigen Betriebsdaten aus dem bisherigen Ticketsystem in OFORK weiterverwendet werden. Dazu gehören insbesondere Tickets, Artikel, Kunden, Benutzer, Gruppen, Rollen, Queues, Services, Vorlagen, Systemkonfiguration und E-Mail-Einstellungen.

Der Ablauf folgt technisch demselben Grundprinzip wie ein OFORK-Update: Das alte System wird nicht direkt überschrieben, sondern zuerst gesichert und separat abgelegt. Erst danach wird die neue OFORK-Version installiert und mit den übernommenen Daten verbunden.

Voraussetzungen

Vor Beginn sollte geprüft werden, ob das bestehende System sauber läuft und ob ein vollständiger Zugriff auf Server, Dateien und Datenbank vorhanden ist.

Wichtig sind:

SSH-Zugriff auf den Server
Root-Rechte oder ein Benutzer mit sudo
Zugriff auf die bestehende Datenbank
Zugriff auf das bisherige Installationsverzeichnis
genug freier Speicherplatz für Dateisicherung und Datenbankdump
Wartungsfenster ohne aktive Benutzer im System
funktionierende Rücksicherung aus Backup

Die Migration sollte nicht während des laufenden Tagesbetriebs durchgeführt werden. Während der Migration dürfen keine neuen Tickets, E-Mails oder Agentenaktionen mehr im alten System entstehen.

Schritt 1: Wartungsfenster festlegen

Informieren Sie Agenten und Administratoren vorab über das Wartungsfenster. Das alte System sollte während der Migration nicht mehr produktiv genutzt werden.

Schritt 2: Dienste stoppen

Stoppen Sie zuerst alle Dienste, die auf das Ticketsystem zugreifen können. Die konkreten Dienstnamen können je nach Distribution abweichen.

root> /etc/init.d/cron stop
root> /etc/init.d/postfix stop
root> /etc/init.d/apache stop

Falls Ihr Server systemctl verwendet, können die Befehle entsprechend so aussehen:

root> systemctl stop cron
root> systemctl stop postfix
root> systemctl stop apache2

Stoppen Sie danach die jobspezifischen Prozesse des bestehenden Systems.

ofork> cd /opt/ofork/
ofork> bin/Cron.sh stop
ofork> bin/ofork.Daemon.pl stop

Falls die Altinstallation noch unter einem anderen Pfad liegt, verwenden Sie den tatsächlichen Installationspfad.

Schritt 3: Datenbank sichern

Erstellen Sie vor jeder Änderung einen vollständigen Datenbankdump.

root> mkdir -p /opt/ofork-migration-backup
root> mysqldump -u root -p --single-transaction --routines --triggers --events otrs > /opt/ofork-migration-backup/otrs-before-ofork.sql

Wenn Ihre Datenbank bereits ofork heißt, passen Sie den Datenbanknamen entsprechend an:

root> mysqldump -u root -p --single-transaction --routines --triggers --events ofork > /opt/ofork-migration-backup/ofork-before-migration.sql

Prüfen Sie anschließend, ob die Sicherungsdatei erzeugt wurde und nicht leer ist.

root> ls -lh /opt/ofork-migration-backup/

Schritt 4: Bestehende Dateien sichern

Benennen Sie die bestehende Installation um oder kopieren Sie sie in ein Backup-Verzeichnis. Dadurch bleibt der alte Stand erhalten.

root> cd /opt
root> mv ofork ofork-old

Wenn die bisherige Installation noch unter einem anderen Namen liegt, sichern Sie dieses Verzeichnis entsprechend:

root> cd /opt
root> cp -a otrs ofork-old

Wichtig ist, dass die alte Installation vollständig erhalten bleibt. Dazu gehören Konfiguration, Artikeldateien, eigene Erweiterungen, Themes, lokale Anpassungen und Logdateien.

Schritt 5: OFORK installieren

Laden Sie das aktuelle OFORK-Archiv herunter und entpacken Sie es unter /opt.

root> cd /opt
root> wget https://ftp.o-fork.de/ofork-12.0.3.tar.gz
root> tar xzf ofork-12.0.3.tar.gz
root> mv ofork-12.0.3 ofork

Danach sollte die neue Installation unter /opt/ofork liegen.

root> ls -la /opt/ofork

Schritt 6: Konfiguration übernehmen

Kopieren Sie die bestehende Konfigurationsdatei in die neue OFORK-Installation.

root> cp /opt/ofork-old/Kernel/Config.pm /opt/ofork/Kernel/Config.pm

Prüfen Sie danach die Pfade und Datenbankdaten in Kernel/Config.pm.

Besonders wichtig sind:

Datenbankname
Datenbankbenutzer
Datenbankpasswort
Systempfad
Hostname
E-Mail-Konfiguration
Dateispeicherpfade

Wenn das alte System nicht unter /opt/ofork installiert war, müssen die Pfade in der Konfiguration angepasst werden.

Schritt 7: Artikeldaten übernehmen

Wenn Artikeldaten im Dateisystem gespeichert wurden, muss der entsprechende Ordner aus der alten Installation übernommen werden.

Typischer Standardpfad:

root> cp -a /opt/ofork-old/var/article /opt/ofork/var/

Je nach Systemkonfiguration kann der Pfad abweichen. Prüfen Sie deshalb in der alten Konfiguration, ob ein eigener Artikelpfad gesetzt wurde.

Zusätzlich sollten eigene Dateien, Anhänge, Logos oder lokale Anpassungen kontrolliert werden.

Schritt 8: Eigene Anpassungen prüfen

Übernehmen Sie eigene Anpassungen nicht blind. Prüfen Sie jede Änderung darauf, ob sie mit der neuen OFORK-Version noch kompatibel ist.

Typische Bereiche sind:

eigene Skins und Logos
angepasste Templates
eigene Perl-Module
zusätzliche Pakete
lokale Konfigurationsdateien
kundenspezifische Erweiterungen

Wenn Erweiterungen nicht mehr kompatibel sind, sollten sie vor dem ersten produktiven Start deaktiviert oder aktualisiert werden.

Schritt 9: Dateiberechtigungen setzen

Setzen Sie die Datei- und Verzeichnisrechte für die neue OFORK-Installation.

root> cd /opt/ofork/
root> bin/ofork.SetPermissions.pl

Falls Perl-Module fehlen, müssen diese vor der Migration nachinstalliert werden.

Beispiele:

root> cpan install Moo
root> cpan install Types::Standard

Unter Debian oder Ubuntu können benötigte Pakete auch über die Paketverwaltung installiert werden:

root> apt-get install -y libmoo-perl
root> apt-get install -y libtypes-path-tiny-perl

Schritt 10: Datenbank für OFORK vorbereiten

Wenn aus einer bestehenden OTRS-Datenbank migriert wird, sollte die Datenbank vorab separat gesichert und anschließend für OFORK bereitgestellt werden.

Eine typische Variante ist:

root> mysql -u root -p -e "CREATE DATABASE ofork CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
root> mysql -u root -p ofork < /opt/ofork-migration-backup/otrs-before-ofork.sql

Wenn die bestehende Datenbank direkt weiterverwendet wird, muss das vorher bewusst entschieden und zusätzlich gesichert werden.

Empfohlen ist eine Kopie der Datenbank, damit das Ursprungssystem im Fehlerfall unverändert bleibt.

Schritt 11: Migrationsskript ausführen

Führen Sie das Migrationsskript als Benutzer ofork aus, nicht als root.

ofork> cd /opt/ofork/
ofork> scripts/DBUpdate-to-12.pl

Während der Migration können Rückfragen erscheinen, zum Beispiel zur Zeitzone. Die Zeitzone muss bewusst gewählt werden, weil sie Einfluss auf gespeicherte Datumswerte in Tickets, Artikeln und Folgeprozessen hat.

Wichtig:

Migration nicht abbrechen
Fehlermeldungen vollständig lesen
keine Dienste parallel starten
Logausgaben sichern
bei Fehlern nicht mehrfach unkontrolliert erneut starten

Schritt 12: Cache und automatisch erzeugte Konfiguration prüfen

Nach der Migration kann es notwendig sein, automatisch erzeugte Konfigurationsdateien neu aufzubauen.

Falls beim Browseraufruf ein Fehler 500 erscheint, kann die Datei ZZZAAuto.pm entfernt werden.

root> cd /opt/ofork/Kernel/Config/Files
root> rm ZZZAAuto.pm

Danach wird die Datei durch OFORK neu erzeugt.

Schritt 13: Dienste wieder starten

Starten Sie die Systemdienste wieder.

root> /etc/init.d/apache start
root> /etc/init.d/postfix start
root> /etc/init.d/cron start

Oder mit systemctl:

root> systemctl start apache2
root> systemctl start postfix
root> systemctl start cron

Starten Sie danach den OFORK-Daemon.

ofork> /opt/ofork/bin/ofork.Daemon.pl start

Schritt 14: Funktionstest nach der Migration

Nach dem Neustart sollte OFORK nicht sofort wieder vollständig freigegeben werden. Prüfen Sie zuerst die wichtigsten Funktionen.

Kontrollieren Sie:

Login im Agentenbereich
vorhandene Tickets
Ticketartikel und Anhänge
Kunden und Kundenbenutzer
Queues, Services und Prioritäten
E-Mail-Empfang
E-Mail-Versand
Cron-Jobs
Daemon-Status
Systemprotokolle

Ein schneller Daemon-Test:

ofork> cd /opt/ofork/
ofork> bin/ofork.Daemon.pl status

Schritt 15: Nacharbeiten

Nach der technischen Migration sollten die Inhalte und Prozesse fachlich geprüft werden.

Häufige Probleme

Fehler 500 nach der Migration

Ein Fehler 500 deutet häufig auf Konfigurations-, Berechtigungs- oder Perl-Modulprobleme hin. Prüfen Sie zuerst die Webserver-Logs und die OFORK-Logs.

Mögliche Maßnahmen:

root> cd /opt/ofork/Kernel/Config/Files
root> rm ZZZAAuto.pm
root> cd /opt/ofork
root> bin/ofork.SetPermissions.pl

Tickets sind vorhanden, aber Anhänge fehlen

Dann wurden die Artikeldaten wahrscheinlich im Dateisystem gespeichert und nicht vollständig übernommen. Prüfen Sie den Artikelpfad der alten Installation und kopieren Sie den passenden Ordner in das neue System.

E-Mails werden nicht abgeholt

Prüfen Sie Mailkonten, Cron-Jobs, Daemon und Netzwerkzugriff.

ofork> cd /opt/ofork/
ofork> bin/ofork.Daemon.pl status

Anmeldung funktioniert nicht

Prüfen Sie Datenbankverbindung, Benutzerbestand, Authentifizierungsmodule und eventuell angebundene Verzeichnisdienste.

Rückfallplan

Eine Migration darf nur gestartet werden, wenn ein Rückfallplan vorhanden ist.

Der Rückfall besteht aus:

altem Installationsverzeichnis
Datenbankdump vor Migration
dokumentierten Dienstzuständen
gesicherten Konfigurationsdateien
bekanntem Zeitpunkt der Abschaltung

Wenn die Migration fehlschlägt, wird das neue System gestoppt, die alte Installation zurückgelegt und die Datenbank aus dem Backup wiederhergestellt.

Professionelle Unterstützung

Wenn die Migration produktive Supportprozesse betrifft, sollte sie geplant und getestet werden. Besonders bei großen Datenbanken, vielen Anhängen, eigenen Erweiterungen oder externer Authentifizierung ist ein Testlauf auf einem separaten Server sinnvoll.

Bei Problemen mit der Migration können Sie eine Nachricht an support@o-fork.de senden.

Fazit

Die Migration zu OFORK ist am zuverlässigsten, wenn sie wie ein kontrolliertes Update durchgeführt wird: altes System stoppen, vollständig sichern, neue OFORK-Version installieren, Konfiguration und Daten übernehmen, Migrationsskript ausführen und danach gründlich testen.

Der wichtigste Punkt ist, das Ursprungssystem nicht ungesichert zu überschreiben. Mit einer sauberen Sicherung und einem klaren Ablauf bleibt die Migration nachvollziehbar und im Fehlerfall rückgängig machbar.