Migration from OTRS 6 or OTRS 7 / ((OTRS)) Community Edition to OTOBO version 10.1¶

Warning

Please migrate your OTRS to OTOBO version 10.1 first and then upgrade your OTOBO to version 11.

欢迎并感谢大家选择OTOBO！

OTRS，（（OTRS））Community Edition和OTOBO的应用都非常全面和灵活。因此，每次迁移OTOBO都需要进行充分的准备，甚至还可能需要一些返工。

请预留时间进行迁移，并逐步按照这些说明进行操作。

如果您有任何问题或疑问，请不要绝望。请拨打我们的支持热线，写电子邮件，或在 https://forum.otobo.org/ 的 OTOBO 社区论坛上发表您的疑问。我们会想办法帮助您！

Note

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

支持的迁移方案概览¶

通过 OTOBO 迁移接口，可以采用以下迁移策略：

一般迁移策略。

这是执行迁移的常规方法。支持多种不同的组合：

更换服务器：

迁移并同时迁移到新的应用服务器。

独立的应用服务器和网络服务器

您可以选择是在同一台主机上运行应用程序服务器和数据库服务器，还是分别在专用主机上运行。这一选择与之前在 OTRS / ((OTRS))社区版。

不同的数据库：

从任何支持的数据库迁移到任何其他支持的数据库。

操作系统不同：

从任何支持的操作系统切换到任何其他支持的操作系统。

Docker：

迁移到基于 Docker 的 OTOBO 10 安装。
简化数据库迁移的一般策略变体。

当源数据库不能承受增加的负载或访问源数据库是一个瓶颈时，使用类似 ETL 的迁移。在一般策略中，首先从 otrs 数据库逐行读取数据，然后插入 OTOBO 数据库。在此变体中，首先导出完整的 otrs 数据库表，然后进行转换，最后导入 otobo 数据库。
Migration from an Oracle based OTRS 6 / OTRS 7 installation to an Oracle based OTOBO installation.

这是一般迁移策略不支持的特殊情况。这意味着必须使用简化策略的变体。

Warning

所有策略都适用于基于 Docker 的安装和本地安装。但对于基于 Docker 的安装，必须考虑一些特殊性。这些特殊性将在可选步骤中处理。

Note

在实际迁移之前，将 OTRS 数据库克隆到 OTOBO 数据库服务器上也是可行的。这可以加快一般迁移策略的实施。

迁移的要求¶

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

Warning

请仔细考虑您是否真的需要这些数据和配置。经验表明，重新开始往往是更好的选择。这是因为在许多情况下，以前使用的安装和配置无论如何都不是最佳的。此外，只转移票单数据并将基本配置更改为 OTOBO 最佳做法也是有意义的。我们很乐意为您提供建议，请通过 hello@otobo.de 与我们联系，或在 https://forum.otobo.org/ 的 OTOBO 社区论坛上提问。

您需要一个运行中的OTOBO安装程序，才能从那里开始迁移！
此OTOBO安装必须还包含要在OTOBO中使用的，OTRS中安装的所有OPM软件包。
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.* / OTRS 7.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.
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.

Note

如果无法在服务器之间进行SSH和数据库访问，请在同一台服务器上进行OTRS到OTOBO的迁移，然后再移动新安装。

步骤 1：安装新的OTOBO系统¶

请从安装新的 OTOBO 系统开始。您的旧 OTRS / ((OTRS))社区版安装将迁移到新系统。我们强烈建议您阅读 OTOBO安装一章。对于基于 Docker 的安装，我们参考安装应用 Docker和Docker Compose 一章。

Warning

在 Apache 下，在同一网络服务器上运行两个独立的 mod_perl 应用程序会有隐患。因此，建议在不同的网络服务器上运行 OTRS 和 OTOBO。或者在安装 OTOBO 之前从 Apache 中删除 OTRS 配置。使用命令 a2query -s 并检查 /etc/apache2/sites-available 和 /etc/apache2/sites-enabled 目录，以查看哪些配置当前可用，哪些已启用。

完成安装后，请以*root@localhost*登录。导航至 OTOBO 管理区 Admin -> Packages 并安装所有需要的 OTOBO OPM 软件包。

以下OPM软件包和OTRS“功能附加组件”不需要，也不应该安装，因为这些功能已在标准的OTOBO版本中提供了：

OTRSHideShowDynamicField
RotherOSSHideShowDynamicField
TicketForms
RotherOSS-LongEscalationPerformanceBoost
Znuny4OTRS - AdvancedDynamicFields
Znuny4OTRS-AutoSelect
Znuny4OTRS-EscalationSuspend
OTRSEscalationSuspend
OTRSDynamicFieldDatabase
OTRSDynamicFieldWebService
OTRSBruteForceAttackProtection
Znuny4OTRS-ExternalURLJump
Znuny4OTRS-QuickClose
Znuny4OTRS-AutoCheckbox
OTRSSystemConfigurationHistory
Znuny4OTRS-PasswordPolicy

The following OTOBO packages have been integrated into OTOBO 11.0. This means that they should not be installed in the target system when the target system is OTOBO 11.

ImportExport

步骤 2：停用 OTOBO 上的 "安全模式¶

安装 OTOBO 后，请重新登录 OTOBO 管理区 Admin -> System Configuration 并停用配置选项 SecureMode。

Note

不要忘记实际部署更改后的设置。

步骤 3：停止 OTOBO 守护进程¶

这在 OTOBO 守护进程实际运行时是必要的。在基于 Docker 和非基于 Docker 的安装中，停止守护进程是不同的。

在非 Docker 的情况下，以用户 otobo 的身份执行以下命令：

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

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

当 OTOBO 在 Docker 中运行时，只需停止服务 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

Note

建议此时运行整个OTOBO系统的备份。如果在迁移过程中出现问题，则不必重复整个安装过程，而可以导入备份以进行新的迁移。

可选步骤：安装 /opt/otrs 以方便访问¶

通常情况下，OTOBO 应在新服务器上运行，而 /opt/otrs 目录最初并不可用。在这种情况下，可以将 OTRS 服务器上的 /opt/otrs 目录挂载到 OTOBO 服务器的文件系统中。如果无法进行常规的网络挂载，则可以选择使用 sshfs。

可选步骤：安装 `sshpass` 和 `rsync` 时 /opt/otrs 应通过 ssh 复制¶

只有从其他服务器迁移 OTRS，且远程服务器上的 /opt/otrs 尚未挂载到运行 OTOBO 的服务器上时，才需要执行此步骤。

需要使用``sshpass``和``rsync``这两个工具，以便*migration.pl*能够通过ssh复制文件。安装`sshpass``时，请以用户`root`的身份登录服务器，并执行下列命令之一：

$ # 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

如果* rsysnc *不可用，则必须执行相同的操作。

步骤 4：准备 OTRS / ((OTRS))社区版系统¶

Note

另外，你还要确保你的OTRS /（（OTRS））Community Edition系统具备有效的备份。是的，在迁移过程中我们不会修改任何OTRS数据，但有时各种错误会造成一些麻烦。

现在我们已准备好进行迁移。首先，我们需要确保不再处理任何工单并且没有用户登录到OTRS：

请登录到OTOBO管理员区域 Admin -> System Maintenance，并插入几个小时的新系统维护。之后，删除所有话务员和用户的会话（“ Admin-> Sessions”），而后退出登陆。

停止所有相关服务和OTRS守护程序¶

请确保没有正在运行的服务或cron作业。

root> su - otrs
otrs> /opt/otrs/bin/Cron.sh stop
otrs> /opt/otrs/bin/otrs.Daemon.pl stop --force

清除缓存和运行数据¶

缓存数据和运行数据无需迁移。此时，邮件队列应该已经清空。

root> su - otrs
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
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Email::MailQueue --delete-all

Docker 可选步骤：在容器内提供所需数据¶

在 Docker 下运行 OTOBO 安装时，需要考虑一些特殊情况。最相关的是：在 Docker 容器中运行的进程通常无法访问容器外的目录。但有一个例外：可以访问作为卷挂载到容器中的目录。此外，请注意在 otobo_db_1 中运行的 MariaDB 数据库无法从容器网络外部直接访问。

Note

下面的介绍是在假设所有需要的系统都已经安装，并且你已经有了一个工作的Docker环境。我们假设用户**root**被用来和Docker互动，请注意针对一个生产环境，需要有一个专用用户作为Docker管理员。

Docker：将* / opt / otrs 复制到卷 otobo_opt_otobo *¶

在本节中，我们假设Docker主机上有* / opt / otrs *。

最少有两种可能性：

Docker：将* / opt / otrs 复制到卷 otobo_opt_otobo *

挂载* / opt / otrs *作为附加卷

在这里我们集中讨论选项** a.**。

在本节中，我们假设Docker主机上有* / opt / otrs *。

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

我们用``rsync``进行安全复制，根据你的Docker设置，这个命令有可能需要和``sudo``一起运行。

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

该复制的目录应该是容器中的* / opt / otobo / tmp / otrs *。

步骤 5：执行迁移！¶

请使用 http://localhost/otobo/migration.pl 上的网络迁移工具。请注意，您可能需要用 OTOBO 主机名替换 "localhost"，还可能需要添加非标准端口。然后，应用程序会引导您完成迁移过程。

Warning

有时会出现未检测到停用**安全模式**的警告。在这种情况下，请重新启动网络服务器。这将强制网络服务器读取当前配置。

# 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

Note

如果 OTOBO 在 Docker 容器内运行，请保留默认设置：localhost 作为 OTRS 服务器，/opt/otobo/var/tmp/copied_otrs 作为 OTRS 主目录。这是在可选步骤中复制的数据路径。

Note

OTRS 数据库用户和密码的默认值取自 OTRS 主目录中的 Kernel/Config.pm。如果使用专用数据库用户进行迁移，请更改建议的设置。在使用复制到 otobo_db_1 Docker 容器中的数据库时，也要更改设置。

Note

在 Docker 情况下，在 Docker 主机上运行的数据库无法通过 Docker 容器内的 127.0.0.1` 访问。这意味着`127.0.0.1``设置对输入字段`OTRS 服务器`无效。在这种情况下，请为 OTRS Server` 输入命令 ``hostname --all-ip-addresses` 所报告的备选 IP 地址之一。

Note

在迁移到新的应用服务器或基于 Docker 的安装时，往往无法从目标安装访问数据库。这通常是由于 otobo 数据库用户只能从数据库运行的主机进行连接。为了允许访问，建议为迁移创建一个专用的数据库用户。例如，CREATE USER 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration';``和``GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';。迁移后可以再次删除该用户：DROP USER 'otrs_migration'@'%'.

Kernel/Config.pm 中的自定义设置会从旧的 OTRS 安装转移到新的 OTOBO 安装。如果您有自定义设置，请查看迁移后的文件 /opt/otobo/Kernel/Config.pm。您可能需要调整自定义路径或 LDAP 设置。在最好的情况下，您可能会发现不再需要某些自定义设置。

迁移完成后，请花点时间测试整个系统。一旦确定迁移成功并且要从现在开始使用OTOBO，请启动OTOBO守护程序：

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

在Docker情况下：

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

步骤 6：成功迁移后！¶

如果不再需要，卸载 sshpass。
如果创建了专用于迁移的数据库和数据库用户，请将其删除。
享受OTOBO带来的快乐吧！

已知的迁移问题¶

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

当ScriptAlias的配置不是标准值时，可能会发生这种情况。迁移简单地用otrs代替otobo可能会导致无法在OTOBO中检索CSS和JavaScript。发生这种情况时，请检查Kernel / Config.pm中的设置并将其恢复为合理的值。

3.迁移因 MySQL 错误而停止¶

在过去升级时遇到过问题的系统上，迁移过程可能会因 ticket 和 ticket_history 表中的 MySQL 错误而停止。这些错误通常是源表中的 NULL 值在目标表中不再允许存在。在继续迁移之前，必须手动解决这些冲突。

从 OTOBO 10.0.12 起，migration.pl 中有一项检查功能，可在数据传输之前检查是否存在 NULL 值。需要注意的是，仍然需要手动进行解析。

4.迁移到 PostgreSQL 时步骤 5 中的错误¶

在这种情况下，migration.pl*会显示 "System was unable to complete data transfer."（系统无法完成数据传输）这条不太有用的信息。而 Apache 日志文件和 OTOBO 日志文件则显示了一条更有意义的信息："Message：ERROR: permission denied to set parameter "session_replication_role", SQL: 'set session_replication_role to replica;'"。为了给数据库用户 **otobo* 所需的超级用户权限，请以 PostgreSQL 管理员身份运行以下语句：ALTER USER otobo WITH SUPERUSER;`。然后重新运行 http://localhost/otobo/migration.pl。迁移后，运行 ALTER USER otobo WITH NOSUPERUSER 返回正常状态。

目前还不清楚是否每次设置都必须授予扩展权限。

5.合并系统配置的部署问题¶

系统配置是在数据库表迁移后迁移的。在这种情况下，迁移意味着将 OTOBO 的默认设置与源 OTRS 系统的系统配置合并。在这一步骤中可能会出现不一致的情况。一个真实的例子是 "Ticket::Frontend::AgentTicketQuickClose###State "设置。该设置是OTOBO 10中的新设置，默认值为``关闭成功``状态。但如果源系统中的状态 "关闭成功 "已被删除或重命名，则该设置无效。在迁移步骤**迁移配置设置**中，这种不一致会被检测为错误。实际上，合并后的系统配置存储在数据库中，但在部署过程中会执行额外的有效性检查。

必须使用 OTOBO 控制台命令手动解决这个问题。

使用``bin/otobo.Console.pl Admin::Config::ListInvalid`` 命令列出不一致之处。
使用 bin/otobo.Console.pl Admin::Config::FixInvalid 交互式修复无效值
使用 bin/otobo.Console.pl Maint::Config::Rebuild 部署从 migration.pl 中收集的更改，包括停用的 SecureMode

完成这些手动步骤后，你就可以再次运行 migration.pl。迁移将从发生错误的步骤继续进行。

步骤 7：手工迁移的任务和修改¶

1. Password policy rules¶

如果使用本地身份验证，对于OTOBO 10，代理和客户用户的新的默认密码策略将生效。可以在系统配置（“ PreferencesGroups ### Password”和“ CustomerPersonalPreference #### Password”）中更改密码策略规则。

密码策略规则	默认
`` PasswordMinSize ``	8
`` PasswordMin2Lower2UpperCharacters ``	是
`` PasswordNeedDigit ``	是
`` PasswordHistory ``	10
`` PasswordTTL ``	30天
`` PasswordWarnBeforeExpiry ``	5天
`` PasswordChangeAfterFirstLogin ``	是

2.在 Docker 下：手动迁移 cron 作业¶

在 OTOBO 的非 Docker 安装中，至少有一个 cron 作业会检查守护进程的健康状况。在 Docker 环境下，这个 cron 作业已不复存在。此外，任何 Docker 容器中都没有运行 cron 守护进程。这就意味着，您必须为 OTRS 系统的客户特定 cron 作业（如备份数据库）寻找一个单独的解决方案。

专题¶

从 Oracle 迁移到 Oracle¶

要迁移到 Oracle，必须采用类似 ETL 的策略。这是因为 Oracle 没有提供暂时关闭外键检查的简单方法。

在 OTOBO 主机上必须安装 Oracle 客户端和 Perl 模块 DBD::Oracle。

Note

使用 Oracle 即时客户端时，还需要安装可选的 SDK DBD::Oracle。

克隆模式的方法有很多种。在示例命令中，我们使用了 expdb 和 impdb，它们在引擎盖下使用 Data Pump。

Note

本文档中显示的连接字符串指的是源数据库和目标数据库都在 Docker 容器中运行的情况。另请参见 https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md 。

清空奥托博

停止 otobo 的网络服务器，关闭 otobo 的数据库连接。

-- in the OTOBO database
DROP USER otobo CASCADE

导出完整的 OTRS 模式。

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

导入 OTRS 模式，将模式重命名为 "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;

调整克隆模式 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';

再次启动 otobo 的网络服务器
继续第 5 步，即运行 migration.pl。

Note

如果迁移到大于或等于 10.1 的 OTOBO 版本，必须执行脚本 /opt/otobo/scripts/DBUpdate-to-10.1.pl 以创建在 10.1 版本中新增的表 stats_report 和 data_storage。

可选步骤：简化数据库迁移（仅适用于专家和特殊情况）¶

在一般迁移策略中，数据库表中的所有数据都将从 OTRS 数据库逐行复制到 OTOBO 数据库中。将数据从 OTRS 数据库导出并导入 OTOBO 数据库可能会节省时间，而且在某些情况下更为稳定。

Note

该变体既适用于基于 Docker 的安装，也适用于本机安装。

Note

这些说明假定 OTRS 使用 MySQL 作为后台。

首先，我们需要转储所需的 OTRS 数据库表。然后，我们需要进行一些转换：

将字符集转换为 utf8mb4

重命名几个表格

缩短某些表格列

转换后，我们可以用 OTRS 转换后的数据覆盖 OTOBO 模式中的表。实际上，我们需要的不是一个转储文件，而是几个 SQL 脚本。

当安装了mysqldump并且可以连接到OTRS数据库时，您可以直接在Docker主机上创建数据库转储。脚本* bin / backup.pl *支持这种情况。

Warning

在本节中，我们假设Docker主机上有* / opt / otrs *。

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"

Note

或者，也可以将数据库转储到另一台服务器上，然后再传输到 Docker 主机上。一种简单的方法是将 /opt/otobo 复制到运行 OTRS 的服务器上，然后执行与上述相同的命令。

脚本 bin/backup.pl 会在转储目录中生成四个 SQL 脚本，例如 2021-04-13_12-13-04 为了执行 SQL 脚本，我们需要运行 mysql 命令。

本地安装：

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 的安装：

在 Docker 容器 db 中运行 mysql 命令，以导入数据库转储文件。请注意，数据库 root 的密码现在是在 Docker 主机上的 .env 文件中设置的密码。

docker_admin> cd /opt/otobo-docker
docker_admin> docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_pre.sql
docker_admin> docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_schema_for_otobo.sql
docker_admin> docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_data.sql
docker_admin> docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_post.sql

要快速检查导入是否成功，可以运行以下命令。

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'

或在 Docker 下运行时

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

数据库现已迁移。这意味着下一步我们可以跳过数据库迁移。注意相关复选框。

Migration from OTRS 6 or OTRS 7 / ((OTRS)) Community Edition to OTOBO version 10.1¶

支持的迁移方案概览¶

迁移的要求¶

步骤 1：安装新的OTOBO系统¶

步骤 2：停用 OTOBO 上的 "安全模式¶

步骤 3：停止 OTOBO 守护进程¶

可选步骤：安装 /opt/otrs 以方便访问¶

可选步骤：安装 sshpass 和 rsync 时 /opt/otrs 应通过 ssh 复制¶

步骤 4：准备 OTRS / ((OTRS))社区版系统¶

停止所有相关服务和OTRS守护程序¶

清除缓存和运行数据¶

Docker 可选步骤：在容器内提供所需数据¶

Docker：将* / opt / otrs 复制到卷 otobo_opt_otobo *¶

步骤 5：执行迁移！¶

步骤 6：成功迁移后！¶

已知的迁移问题¶

1. Login after migration not possible¶

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

3.迁移因 MySQL 错误而停止¶

4.迁移到 PostgreSQL 时步骤 5 中的错误¶

5.合并系统配置的部署问题¶

步骤 7：手工迁移的任务和修改¶

1. Password policy rules¶

2.在 Docker 下：手动迁移 cron 作业¶

专题¶

从 Oracle 迁移到 Oracle¶

可选步骤：简化数据库迁移（仅适用于专家和特殊情况）¶

可选步骤：安装 `sshpass` 和 `rsync` 时 /opt/otrs 应通过 ssh 复制¶