# 从 Request Tracker（RT）迁移到 Specivo，历史一条不丢 Request Tracker（RT）是一款让人长期舍不得换的工单系统，这是有道理的：它灵活、免费，很多实例几乎不用怎么照看就能稳定运行多年。但绝大多数 RT 管理员迟早都要面对同一件事——升级。如果你正在权衡要不要升级，不妨趁这个机会想一想：这些年积累的工单历史，下一站该放在哪里？ Specivo 现在提供了 RT 迁移工具，它以只读方式读取 RT 数据库，把工单及其完整历史搬到 Specivo 中。本文介绍团队为什么迁移、哪些内容会跟着过来、哪些不会，以及如何零风险地试一试。 ## RT 团队为什么开始另寻出路 我们梳理了 RT 用户在公开论坛和讨论中的发言，发现一个很明显的规律：很少有人抱怨 RT 不好用，但很多人抱怨 RT 不好运维。 - **安装与升级**。RT 基于 Perl 和 CPAN。RT 官方升级指南推荐全新安装再导入数据库，而不是原地升级。论坛里有人说升级花了好几周，也有站点在 4.x 上停留了多年。 - **定制离不开 Perl**。Scrips、Mason overlay 和本地扩展确实能解决问题，但得持续维护，升到 RT 6.0 时还常常要重写。 - **邮件链路**。如何通过 OAuth 从 Microsoft 365 收取邮件，是 RT 论坛上持续时间最长的帖子之一。 - **单点登录（SSO）、报表和工时记录**。这些需求经常被提出，通常得靠扩展，或者直接在数据库里动手。 这些都不说明 RT 是个差工具。它仍在维护，用户也称赞它可靠、专注。我们想说的只有一点：既然升级本来就意味着重做一遍定制，那在动手前先比较一下其他去处，成本并不高。 ## 让多数迁移望而却步的顾虑：丢失历史 过去离开 RT 的团队，往往把历史留在了原地。比如 OpenSSL [迁到了 GitHub](https://mirror.openssl-library.org/post/2016-10-12-f2f-rt-github/)，但没有带走已关闭的旧工单。还有的团队把 RT 保留为只读存档，或者只转换未关闭的工单。在我们考察过的服务台和项目追踪产品里，没有一款提供官方支持的 RT 导入器。可选的路通常只有三条：调 API、自己写代码，或者从零开始。 这正是这款工具要填补的空白。多年积累的已关闭工单，记录着“为什么事情会变成今天这样”。丢掉它们，是实实在在的损失。 ## Specivo 能提供什么 Specivo 是一个可私有化部署的项目追踪与知识库平台，由你自己掌控。 - **部署在你指定的地方**。用 [Docker](https://specivo.io/zh-cn/self-host-specivo-docker/) 安装到你自己掌控的服务器上，[物理隔离的内网](https://specivo.io/docs/specivo/zh-cn/install/air-gapped/)也可以。不用维护 Perl 和 CPAN：升级就是换一个新的容器镜像。 - **工作项、维基和工时记录合为一体**。你的工单、RT Articles 里的文章，以及花在它们上面的工时，都在同一个地方。 - **AI 由你选择**。云端大模型、本地模型，或者干脆不用，都可以。AI 智能体和人遵循同一套权限。 - **没有付费墙**。所有功能都在自托管版本里。 ## 工具会迁移哪些内容 工具支持读取运行在 PostgreSQL、MySQL 或 MariaDB 上的 RT 4.4、5.0 和 6.0，不会对 RT 做任何改动。 - **队列**变成项目。已停用的队列会归档。 - **工单**变成工作项，保留状态、优先级、所有者和日期，第一条消息作为描述。 - **往来回复和评论**按原有顺序迁移，并带上字段变更的完整历史。回复和私密评论仍然区分开。 - **附件**，包括内嵌图片，以及 RT 转存到磁盘存储的文件。 - **已耗工时**变成工时记录。 - **链接关系**：父子、依赖、引用。正文里像“ticket 123”这样的提法会变成指向新工作项的链接。 - **已合并的工单**并入被合并到的目标工单，消息保持在一起，旧编号也仍能找到去处。 - 工单上的**自定义字段**，连同其变更历史。 - **人员、组和权限**变成用户、用户组和项目角色。 - **Articles**（文章）变成维基页面，保留每一个修订版本。 详情见文档中的[迁移内容](https://specivo.io/docs/rt-migration-tool/zh-cn/carried-over/)页面。 ## 有意不迁移的内容 如果一款工具号称能搬走一切，RT 管理员有理由不信。这款工具会明确列出它不处理的内容，每一处遗漏都会计入导入报告，不会有东西悄无声息地消失。 - **自动化**：scrips 和模板。 - **Specivo 没有对应模型的内容**：资产、审批、提醒、服务级别、保存的搜索和仪表盘。 - **密码**。所有人都需要重新设置。 - **私密评论上的文件**。Specivo 的附件没有私密标记，所以这些文件默认不迁移，除非你明确要求。 - **Everyone 权限**。授予 RT 的 Everyone 组的权限不会让任何项目变成公开项目。报告会按队列逐一列出这些权限，由你来决定。 完整列表见[不迁移的内容](https://specivo.io/docs/rt-migration-tool/zh-cn/not-carried-over/)。 ## 关于邮件，说句实话 很多人称赞 RT 以邮件驱动的工作流：队列绑定邮箱地址、通过邮件回复、请求者从不打开 Web 界面。Specivo 没有复制这套模式：它没有邮件进件的服务台，没有客户门户，没有服务级别，也没有 scrips。 所以，Specivo 最适合这样的场景：RT 是 IT、运维、研发或科研团队的内部追踪系统，而你希望把工单、知识和工时记录放在一起。如果某个队列本质上是面向客户的邮箱，那就暂时留在 RT 里。其余的队列可以先迁，剩下的原样不动。 ## 先演练，再切换 你不必在一个周末之内完成切换： 1. **导出**一次试验性的数据，每个队列取几条工单即可。工具只需要一个有读取权限的数据库账户。 2. 在 Specivo 测试实例中**校验并试运行**导入包。试运行不会做任何改动。 3. 和团队一起**到处看看**，读一读报告，想重复多少次都可以。队列可以一个一个地迁，彼此之间的链接依然能正确解析。 4. 准备好之后再**切换**：停止在 RT 里新建工单，做最后一次导出，然后加载到生产环境的 Specivo。 具体步骤见文档：[安装](https://specivo.io/docs/rt-migration-tool/zh-cn/install/)、[从 RT 导出](https://specivo.io/docs/rt-migration-tool/zh-cn/exporting/)和[加载导入包](https://specivo.io/docs/rt-migration-tool/zh-cn/loading/)。 ## 前提条件 - Specivo 0.11.0 或更高版本，使用 [Docker](https://specivo.io/zh-cn/self-host-specivo-docker/) 安装。 - 运行在 PostgreSQL、MySQL 或 MariaDB 上的 RT 4.4、5.0 或 6.0。 - 一个只读数据库账户，以及一台装有 Python 3.12 或更高版本、能访问该数据库的机器。 该工具已开源，v0.1.0 版本发布在 [GitHub](https://github.com/specivo/rt-migration-tool) 上。 ## 先拿一个队列试试 在一台闲置服务器上装好 Specivo，导出一个真实队列，看看你自己的历史数据在另一边是什么样子。如果你还要从其他系统迁移，[Jira](https://specivo.io/zh-cn/migrate-from-jira/) 和 [Redmine](https://specivo.io/zh-cn/migrate-from-redmine/) 也有对应的迁移路径。 - [RT 迁移工具文档](https://specivo.io/docs/rt-migration-tool/zh-cn/) - [用 Docker 安装 Specivo](https://specivo.io/zh-cn/self-host-specivo-docker/) - [Specivo 用户指南](https://specivo.io/docs/specivo/zh-cn/) “Request Tracker”和“RT”是 Best Practical Solutions, LLC 的商标。Specivo 与 Best Practical Solutions 没有关联，也未获得其认可。