Migration von OTRS / ((OTRS)) Community Edition Version 6 auf OTOBO 10

Hallo und danke, dass Sie sich für OTOBO entschieden haben!

OTRS, ((OTRS)) Community Edition und OTOBO sind Systeme mit umfassender Funktionalität, die große Flexibilität bieten. Deshalb erfordert jede Migration sorgfältige Vorbereitung und möglicherweise auch Nacharbeiten.

Bitte nehmen Sie sich deshalb Zeit für die Migration und befolgen Sie die Anleitung Schritt für Schritt.

If you have any problem or question, please do not despair. Call our support line, write an email, or post your query in the OTOBO Community forum at https://forum.otobo.org/. We will find a way to help you!

Bemerkung

After the migration the data previously available in OTRS 6 will be available in OTOBO 10. We do not modify any data of the OTRS 6 installation during the migration.

Overview over the Supported Migration Szenarios

With the OTOBO Migration Interface it is possible to employ the following migration strategies:

  1. The general migration strategy.

    This is the regular way to perform a migration. Many different different combinations are supported:

    Change server:

    Migrate and simultaneously move to a new application server.

    Separate application and web servers:

    It’s your choice whether you want to run application and database server on the same host or each on a dedictated host. This choice is regardless of the previous setup in OTRS / ((OTRS)) Community Edition.

    Different databases:

    Migrate from any of the supported databases to any other supported database.

    Different operating system:

    Switch from any supported operating system to any other supported operating system.

    Docker:

    Migrate to a Docker-based installation of OTOBO 10.

  2. A variant of the general strategy where the database migration is streamlined.

    Use the ETL-like migration when the source database mustn’t suffer from increased load or when access to the source database is a bottleneck. In the general strategy, the data is row by row first read from the otrs database and then inserted into the OTOBO database. In this variant, the complete otrs database tables are first exported, then transformed, and then imported into the otobo database.

  3. Migration from an Oracle based OTRS 6 installation to an Oracle based OTOBO installation.

    This is a special case that is not supported by the general migration strategy. This means that a variant of the streamlined strategy must be used.

Warnung

All strategies work for both Docker-based and native installations. But for Docker-based installations some peculiarities have to be considered. These peculiarities are handled in the optional steps.

Bemerkung

It is also feasible to clone the OTRS datase to the OTOBO database server before the actual migration. This can speed up the general migration strategy.

Migrationsvoraussetzungen

  1. Basic requirement for a migration is that you already have an ((OTRS)) Community Edition or OTRS 6.0.* running, and that you want to transfer both configuration and data to OTOBO.

Warnung

Please consider carefully whether you really need the data and configuration. Experience shows that quite often a new start is the better option. This is because in many cases the previously used installation and configuration was rather suboptimal anyways. It might also make sense to only transfer the ticket data and to change the basic configuration to OTOBO Best Practice. We are happy to advise you, please get in touch at hello@otobo.de or ask your question in the OTOBO Community forum at https://forum.otobo.org/.

  1. Sie benötigen eine betriebsbereite OTOBO-Installation als Ausgangpunkt für die Migration!
  2. Auf dieser OTOBO-Instanz müssen alle OPM-Pakete installiert sein, die Sie bisher in Ihrem OTRS nutzen und künftig in OTOBO nutzen möchten.
  3. If you are planning to migrate to another server, then the OTOBO webserver must be able to access the location where your ((OTRS)) Community Edition or OTRS 6.0.* is installed. In most cases, this is the directory /opt/otrs on the server running OTRS. The read access can be effected via SSH or via file system mounts.
  4. The otrs database must be accessible from the server running OTOBO. Readonly access must be granted for external hosts. If access is not possible, or when the speed of the migration should be optimised, then a dump of the database is sufficient.

Bemerkung

Sind SSH-Kommunikation und Datenbankzugriff von einem Server auf den anderen nicht möglich, migrieren Sie zunächst auf dem alten Server von OTRS zu OTOBO und ziehen die neue Instanz erst nachträglich um.

Schritt 1: Neues OTOBO-System installieren

Please start with installing a new OTOBO system. Your old OTRS / ((OTRS)) Community Edition installation will be migrated to that new system. We strongly recommend to read the chapter OTOBO Installation. For Docker-based installations we refer to the chapter Installation mit Docker und Docker Compose.

Warnung

Under Apache, there are pitfalls with running two independent mod_perl applications under on the same webserver. Therefore, it is advised to run OTRS and OTOBO on separate webservers. Alternatively remove the OTRS configuration from Apache before installing OTOBO. Use the command a2query -s and check the directories /etc/apache2/sites-available and /etc/apache2/sites-enabled for inspecting which configurations are currently available and which are enabled.

After finishing the installation please log in as root@localhost. Navigate to the OTOBO Admin Area Admin -> Packages and install all required OTOBO OPM packages.

Folgende OPM-Pakete und OTRS-„Feature Addons“ müssen und sollten NICHT installiert werden, da ihre Funktionalität bereits im OTOBO Standard enthalten ist:
  • OTRSHideShowDynamicField
  • RotherOSSHideShowDynamicField
  • TicketForms
  • RotherOSS-LongEscalationPerformanceBoost
  • Znuny4OTRS-AdvancedDynamicFields
  • Znuny4OTRS-AutoSelect
  • Znuny4OTRS-EscalationSuspend
  • OTRSEscalationSuspend
  • OTRSDynamicFieldDatabase
  • OTRSDynamicFieldWebService
  • OTRSBruteForceAttackProtection
  • Znuny4OTRS-ExternalURLJump
  • Znuny4OTRS-QuickClose
  • Znuny4OTRS-AutoCheckbox
  • OTRSSystemConfigurationHistory
  • Znuny4OTRS-PasswordPolicy

Step 2: Deactivate SecureMode on OTOBO

After installing OTOBO, please log in again to the OTOBO Admin Area Admin -> System Configuration and deactivate the config option SecureMode.

Bemerkung

Do not forget to actually deploy the changed setting.

Step 3: Stop the OTOBO Daemon

This is necessary when the OTOBO Daemon is actually running. Stopping the Daemon is different between Docker-based and non-Docker-based installations.

In the non-Docker case execute the following commands as the user otobo:

# in case you aer logged in as root
root> su - otobo

otobo> /opt/otobo/bin/Cron.sh stop
otobo> /opt/otobo/bin/otobo.Daemon.pl stop --force

When OTOBO is running in Docker, you just need to stop the service daemon:

docker_admin> cd /opt/otobo-docker
docker_admin> docker-compose stop daemon
docker_admin> docker-compose ps     # otobo_daemon_1 should have exited with the code 0

Bemerkung

Wir empfehlen, an dieser Stelle ein Backup des gesamten OTOBO-Systems zu erstellen. Treten dann während der Migration Probleme auf, müssen Sie nicht den gesamten Installationsprozess erneut durchlaufen, sondern können einfach das Backup importieren und eine neue Migration anstoßen.

Siehe auch

Hierzu empfehlen wir die Lektüre des Kapitels OTOBO Backup und Wiederherstellung.

Optional Step: Install sshpass and rsysnc

This step is only necessary when you want to migrate OTRS from another server and when /opt/otrs from the remote server hasn’t been mounted on the server running OTOBO.

Wir verwenden die Tools sshpass und rsync, um Dateien über eine SSH-Verbindung zu kopieren. Bitte melden Sie sich als root-Benutzer am Server an und führen Sie einen der folgenden Befehle aus, um sshpass zu installieren:

$ # Install sshpass under Debian / Ubuntu Linux
$ sudo apt-get install sshpass
$ #Install sshpass under RHEL/CentOS Linux
$ sudo yum install sshpass
$ # Install sshpass under Fedora
$ sudo dnf install sshpass
$ # Install sshpass under OpenSUSE Linux
$ sudo zypper install sshpass

Gehen Sie analog vor, wenn rsync noch nicht verfügbar ist.

Step 4: Preparing the OTRS / ((OTRS)) Community Edition system

Bemerkung

Stellen Sie sicher, dass für Ihr OTRS / ((OTRS)) Community Edition ein aktuelles und vollständiges Backup vorliegt. Selbst wenn die Daten im Quellsystem während der Migration nicht angetastet werden, kann unter Umständen schon ein einziger falscher Eintrag Probleme bereiten.

Damit sind die grundlegenden Voraussetzungen für die Migration geschaffen. Stellen Sie nun sicher, dass keine Tickets mehr bearbeitet werden und sich Benutzer nicht mehr in OTRS anmelden können:

Rufen Sie im OTRS-Admin-Bereich Administration ->  Systemwartung auf und fügen Sie ein neues Systemwartungs-Zeitfenster über einige Stunden hinzu. Löschen Sie anschließend alle Agenten- und User-Sitzungen (Administration ->  Sitzungsverwaltung) und melden Sie sich ab.

Alle relevanten Services und den OTRS Daemon stoppen

Versichern Sie sich, dass keine Dienste oder Crons Jobs mehr ausgeführt werden.

root> su - otrs
otrs>
otrs> /opt/otrs/bin/Cron.sh stop
otrs> /opt/otrs/bin/otrs.Daemon.pl stop --force
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheCleanup
otrs> /opt/otrs/bin/otrs.Console.pl Maint::WebUploadCache::Cleanup

Optional Step for Docker: make required data available inside container

Bei der Nutzung von Docker zur OTOBO-Installation sind einige Besonderheiten zu beachten. Die wichtigste: In einem Docker-Container ausgeführte Prozesse können grundsätzlich nicht auf Verzeichnisse außerhalb dieses Containers zugreifen. Einzige Ausnahme: Auf Verzeichnisse, die als Volumes in den Container gemounted werden, kann zugegriffen werden. Auch die in ``otobo_db_1``laufende MariaDB-Datenbank ist von außerhalb des Container-Netzwerks nicht direkt erreichbar.

Bemerkung

Wir gehen im Folgenden davon aus, dass zur Interaktion mit Docker der Benutzer docker_admin verwendet wird. Der Docker-Admin kann entweder der root-Benutzer des Docker-Host oder ein spezieller Benutzer mit den erforderlichen Berechtigungen sein.

/opt/otrs in das Volume otobo_opt_otobo kopieren

Wir gehen in diesem Abschnitt davon aus, dass das OTRS Home-Verzeichnis /opt/otrs auf dem Docker-Host verfügbar ist.

Sie haben mindestens zwei Möglichkeiten:

  1. /opt/otrs in das bestehende Volume otobo_opt_otobo kopieren
  2. /opt/otrs als zusätzliches Volume mounten

Konzentrieren wir uns hier auf Option a..

Als erstes müssen wir herausfinden, wo das Volume otobo_opt_otobo auf dem Docker-Host bereitsteht.

docker_admin> otobo_opt_otobo_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_opt_otobo)
docker_admin> echo $otobo_opt_otobo_mp  # just a sanity check

Wir nutzen rsync für einen sicheren Kopiervorgang. Je nach Dockerumgebung muss rsync möglicherweise mit sudo-Rechten ausgeführt werden.

docker_admin> # when docker_admin is root
docker_admin> rsync --recursive --safe-links --owner --group --chown 1000:1000 --perms --chmod "a-wx,Fu+r,Du+rx" /opt/otrs/ $otobo_opt_otobo_mp/var/tmp/copied_otrs
docker_admin> ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # just a sanity check

docker_admin> # when docker_admin is not root
docker_admin> sudo rsync --recursive --safe-links --owner --group --chown 1000:1000 --perms --chmod "a-wx,Fu+r,Du+rx" /opt/otrs/ $otobo_opt_otobo_mp/var/tmp/copied_otrs
docker_admin> sudo ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # just a sanity check

Das kopierte Verzeichnis wird im Container als /opt/otobo/var/tmp/copied_otrs verfügbar sein.

Optional Step: Streamlined migration of the database

In the general migration strategy, all data in the database tables is copied row by row from the OTRS database into the OTOBO database. Exporting the data from the OTRS database and importing it into the OTOBO database might save time and is more stable in some circumstances.

Bemerkung

This variant works for both Docker-based and native installations.

Bemerkung

These instructions assume that OTRS is using MySQL as its backend.

First of all, we need a dump of the needed OTRS database tables. Then we need to perform a couple of transformations:

  • convert the character set to utf8mb4
  • rename a couple of tables
  • shorten some table columns

After the transfomation we can overwrite the tables in the OTOBO schema with the transformed data from OTRS. Effectively we need not a single dump file, but several SQL scripts.

Ist ``mysqldump``installiert und kann eine Verbindung zur OTRS-Datenbank hergestellt werden, können Sie den Datenbankdump direkt auf dem Docker-Host erstellen. Hierzu können Sie das Skript bin/backup.pl verwenden.

Warnung

Dies setzt voraus, dass eine OTRS-Installation auf dem Docker-Host verfügbar ist.

otobo> cd /opt/otobo
otobo> scripts/backup.pl -t migratefromotrs --db-name otrs --db-host=127.0.0.1 --db-user otrs --db-password "secret_otrs_password"

Bemerkung

Alternatively, the database can be dumped on another server and then be transferred to the Docker host afterwards. An easy way to do this is to copy /opt/otobo to the server running OTRS and perform the same command as above.

The script bin/backup.pl generates four SQL scripts in a dump directory, e.g. in 2021-04-13_12-13-04 In order to execute the SQL scripts, we need to run the command mysql.

Native installation:

otobo> cd <dump_dir>
otobo> mysql -u root -p<root_secret> otobo < otrs_pre.sql
otobo> mysql -u root -p<root_secret> otobo < otrs_schema_for_otobo.sql
otobo> mysql -u root -p<root_secret> otobo < otrs_data.sql
otobo> mysql -u root -p<root_secret> otobo < otrs_post.sql

Docker-based installation:

Run mysql within the MariaDB container. Note that the password for the database root is now the password that has been set up in .env.

docker_admin> cd <dump_dir>
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otobo < otrs_pre.sql
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otobo < otrs_schema_for_otobo.sql
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otobo < otrs_post.sql
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otobo < otrs_data.sql

Nutzen Sie die folgenden Befehlen, um zu überprüfen, ob der Import erfolgreich war.

otobo> mysql -u root -p<root_secret> -e 'SHOW DATABASES'
otobo> mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'
otobo> mysql -u root -p<root_secret> otobo -e 'SHOW CREATE TABLE ticket'

or

docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> -e 'SHOW DATABASES'
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otobo -e 'SHOW CREATE TABLE ticket'

The database is now migrated. This means that during the next step we can skip the database migration. Watch out for the relevant checkbox.

Step 5: Perform the Migration!

Please use the web migration tool at http://localhost/otobo/migration.pl. Be aware that you might have to replace „localhost“ with your OTOBO hostname and you might have to add your non-standard port. The application then guides you through the migration process.

Warnung

Gelegentlich wird eine Warnung angezeigt, dass die Deaktivierung des SecureMode nicht erkannt wurde. Bitte starten Sie in diesem Fall den Webserver neu. So wird die aktuelle Konfiguration eingelesen.

# native installation
root> service apache2 restart

# Docker-based installation
docker_admin> cd /opt/otobo-docker
docker_admin> docker-compose restart web
docker_admin> docker-compose ps     # otobo_web_1 should be running again

Bemerkung

If OTOBO runs inside a Docker container, keep the default settings localhost for the OTRS server and /opt/otobo/var/tmp/copied_otrs for the OTRS home directory. This is the path of the data that was copied in the optional step.

Bemerkung

Die Standardwerte für den OTRS-Datenbankbenutzer und dessen Passwort werden der Kernel/Config.pm im OTRS-Homeverzeichnis entnommen. Ändern Sie die vorgeschlagenen Einstellungen, wenn Sie einen speziellen Datenbankbenutzer für die Migration verwenden möchten. Passen Sie die Einstellungen auch dann an, wenn Sie mit einer Datenbank arbeiten, die in den otobo_db_1 Docker Container kopiert wurde.

Bemerkung

Wenn Sie Docker nutzen, kann die Datenbank auf dem Docker-Host nicht über 127.0.0.1 erreicht werden. Die Einstellung 127.0.0.1``ist deshalb kein gültiger Wert für das Eingabefeld ``OTRS Server. Geben Sie stattdessen eine der alternativen IP-Adressen an, die Sie mit hostname --all-ip-addresses für OTRS Server ermittelt haben.

Bemerkung

Häufig kann das System nach der Migration auf einen neuen Anwendungsserver oder nach einer Docker-basierten Installation nicht auf die Datenbank zugreifen. Das liegt meist daran, dass der OTOBO-Datenbanknutzer sich nur von dem Host aus verbinden kann, auf dem auch die Datenbank läuft. Um dennoch Zugriff auf die Datenbank zu gewährleisten, empfehlen wir die Anlage eines speziellen Datenbankbenutzers für die Migration – z. B. CREATE USER 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; und GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Dieser Benutzer kann nach der Migration wieder gelöscht werden: DROP USER 'otrs_migration'@'%'.

Ist die Migration abgeschlossen, nehmen Sie sich bitte Zeit, um das System ausgiebig zu testen. Erst wenn Sie sicher sind, dass die Migration erfolgreich durchgeführt wurde und dass Sie von nun an mit OTOBO arbeiten möchten, starten Sie den OTOBO Daemon:

root> su - otobo
otobo>
otobo> /opt/otobo/bin/Cron.sh start
otobo> /opt/otobo/bin/otobo.Daemon.pl start

In der Docker-Umgebung:

docker_admin> cd ~/otobo-docker
docker_admin> docker-compose start daemon

Step 6: After Successful Migration!

  1. Deinstallieren Sie sshpass, wenn Sie es nicht mehr benötigen.
  2. Drop the databases and database users dedicated to the migration if you created any.
  3. Viel Vergnügen mit OTOBO!

Known Migration Problems

1. Login after migration not possible

Während unserer Migrationstests kam es gelegentlich zu Problemen mit dem für die Migration verwendeten Browser. Diese waren in der Regel nach einem Browser-Neustart gelöst. In Safari kann es erforderlich sein, die alte OTRS-Sitzung manuell zu löschen.

2. Final page of the migration has a strange layout due to missing CSS files

Kann vorkommen, wenn die Einstellung ScriptAlias keinen Standardwert enthält. Bei der Migration wird lediglich otrs durch otobo ersetzt. Das kann dazu führen, dass OTOBO nicht mehr korrekt auf CSS und JavaScript zugreifen kann. Bitte überprüfen Sie in diesem Fall die Einstellungen in Kernel/Config.pm und korrigieren Sie diese auf geeignete Werte.

3. Migration stops due to MySQL errors

On systems that experienced problems with an upgrade in the past, the migration process may stop due to MySQL errors in the tables ticket and ticket_history. Usually these errors are NULL values in the source table that are no longer allowed in the target table. These conflicts have to be manually resolved before you can resume the migration.

As of OTOBO 10.0.12 there is a check in migration.pl that checks for NULL values before the data transfer is done. Note, that the resolution still needs to be performed manually.

4. Errors in Step 5 when migrating to PostgreSQL

In these cases the not so helpful message „System was unable to complete data transfer.“ is shown by migration.pl. The Apache logfile, and the OTOBO logfile, show a more meaningful message: „Message: ERROR: permission denied to set parameter „session_replication_role“, SQL: ‚set session_replication_role to replica;‘“. In order to give the database user otobo the needed superuser privileges, run the following statement as the PostgreSQL admin: ALTER USER otobo WITH SUPERUSER;. Then retry running http://localhost/otobo/migration.pl. After the migration, return to the normal state by running ALTER USER otobo WITH NOSUPERUSER.

It is not clear yet, whether the extended privileges have to be granted in every setup.

5. Problems with the Deployment the Merged System Configuration

The system configuration is migrated after the migration of the database tables. In this context, migration means the merging the default settings of OTOBO 10 with the system configuration of the source system. Inconsistencies can arise in this step. An real life example is the setting Ticket::Frontend::AgentTicketQuickClose###State. This setting is new in OTOBO 10 and the default value is the state closed successful. But this setting is invalid when the state closed successful has been dropped or renamed in the source system. This inconsistency is detected as an error in the migration step Migrate configuration settings. Actually, the merged system configuration is stored in the database, but additional validity checks are performed during deployment.

The problem must be alleviated manually using OTOBO console commands.

  • List the inconsistencies with the command bin/otobo.Console.pl Admin::Config::ListInvalid
  • Interactively fix the invalid values with bin/otobo.Console.pl Admin::Config::FixInvalid

After these manual steps you should be able to run migration.pl again. The migration will continue with the step where the error occurred.

Schritt 7: Manuelle Aufgaben und Anpassungen

1. Password policy rules

Mit OTOBO 10 wurde standardmäßig eine neue Passwortrichtlinie für Agenten und Kundenbenutzer eingeführt, wenn diese sich lokal authentifizieren. Die Regeln der Passwortrichtlinie können Sie in der Systemkonfiguration anpassen (PreferencesGroups###Password und CustomerPersonalPreference###Password).

Regel Passwortrichtlinie Standard
PasswordMinSize 8
PasswordMin2Lower2UpperCharacters Ja
PasswordNeedDigit Ja
PasswordHistory 10
PasswordTTL 30 Tage
PasswordWarnBeforeExpiry 5 Tage
PasswordChangeAfterFirstLogin Ja

2. Under Docker: Manually migrate cron jobs

Wird OTOBO nicht unter Docker installiert, gibt es mindestens einen Cron-Job, der den Zustand des Daemon überprüft. Unter Docker gibt es diesen Cron-Job nicht mehr. Darüber hinaus läuft in keinem der Docker-Container ein Cron-Daemon. Für OTRS-Systeme mit kundenspezifischen Cron-Jobs (z. B. Datenbank-Backups) müssen deshalb individuelle Lösungen gefunden werden.

Special topics

Migration from Oracle to Oracle

For migration to Oracle the ETL-like strategy must be employed. This is because Oracle provides no easy way to temporarily turn off foreign key checks.

On the OTOBO host a Oracle client and the Perl module DBD::Oracle must be installed.

Bemerkung

When using the Oracle instant client, then the optional SDK is also needed for installing DBD::Oracle.

There are many ways of cloning a schema. In the sample commands we use expdb and impdb which use Data Pump under the hood.

Bemerkung

The connect strings shown in this documentation refer to the case when both source and target database run in a Docker container. See also https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md .

  1. Clear out otobo

Stop the webserver for otobo, so that the DB connection for otobo is closed.

-- in the OTOBO database
DROP USER otobo CASCADE
  1. Export the complete OTRS schema.
mkdir /tmp/otrs_dump_dir
-- in the OTRS database
CREATE DIRECTORY OTRS_DUMP_DIR AS '/tmp/otrs_dump_dir';
GRANT READ, WRITE ON DIRECTORY OTRS_DUMP_DIR TO sys;
expdp \"sys/Oradoc_db1@//127.0.0.1/orclpdb1.localdomain as sysdba\" schemas=otrs directory=OTRS_DUMP_DIR dumpfile=otrs.dmp logfile=expdpotrs.log
  1. Import the OTRS schema, renaming the schema to ‚otobo‘.
impdp \"sys/Oradoc_db1@//127.0.0.1/orclpdb1.localdomain as sysdba\" directory=OTRS_DUMP_DIR dumpfile=otrs.dmp logfile=impdpotobo.log remap_schema=otrs:otobo
-- in the OTOBO database
-- double check
select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

-- optionally, set the password for the user otobo
    ALTER USER otobo IDENTIFIED BY XXXXXX;
  1. Adapt the cloned schema otobo
cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # it's OK that the command knows only about the otobo database, only last line is relevant
sqlplus otobo/otobo@//127.0.0.1/orclpdb1.localdomain < /home/bernhard/devel/OTOBO/otobo/2021-03-31_13-36-55/orclpdb1.localdomain_post.sql >sqlplus.out 2>&1
double check with `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';
  1. Start the web server for otobo again
  2. Proceed with step 5, that is with running migration.pl.