国产项目管理工具上线清单：迁移前要确认的 5 项准备

很多团队更换项目管理工具时，会把它当成一次简单的数据导入导出：把旧系统里的数据导出，再导入新工具，就算完成。等真正上线才发现，需求和Bug的关联断了，附件少了一部分，权限和角色对不上，看板上的进度与交付结果也不一致。

迁移的成败，更多取决于导入之前的准备，而不是导入功能本身。把研发数据和管理流程从旧系统迁移到国产项目管理工具，数据要完整带走，旧系统的对象要能对应到新系统，权限要重新划定，这些都需要提前确认。

下面按执行顺序，把迁移前的准备拆成5项，每项说明要确认的问题、容易遗漏的地方和具体动作。涉及具体操作的部分以从Jira迁移到禅道为例，换成其他国产项目管理工具时，确认思路相同。

一、先定迁移范围，明确这次要迁移哪些内容

1. 先回答要迁什么、不迁什么

这项准备经常被跳过。团队常常直接问数据怎么导，却没先确定要导什么、不要导什么。范围不定，几年前的废弃项目、停用字段和离职账号会被一起导入新系统，后续清理的成本往往比迁移本身更高。

动手前建议先回答三个问题：

• 哪些产品、项目和迭代需要迁移，哪些只留在旧系统做只读归档？
• 哪些历史数据要完整保留（含评论、变更记录和附件），哪些只需保留结论？
• 账号范围是什么，离职与停用账号是否先清理？

2. 账号与项目状态要提前处理

禅道官方在《Jira数据导入》文档中给出的建议是，迁移前先在源系统删除不再使用的账号，并清理未使用过的问题类型和属性，这样可以减少后续映射配置的工作量和导入时间。

项目状态也要先评估。已完成的项目建议归档，确定不导入的放入回收站。这里有一个容易被忽略的细节：归档项目导入后会变为已关闭，回收站中的项目不会被导入，其余项目导入后为进行中。

这一步的产出是一份迁移范围清单：迁哪些项目、迁哪些对象、保留到什么程度、哪些账号作废。范围越清楚，后面的返工越少。

二、核对版本、部署方式、信创环境与管理模型

范围确定后，要确认能不能迁、迁到哪里。这一步出问题的地方通常不在数据，而在环境。

1. 版本是否满足导入要求

源系统的版本会影响可用的导入方式。以从Jira迁移为例，禅道支持Jira Software Server/Data Center与Cloud的数据迁移，覆盖Jira 7.x、8.x、9.x、10.x（Server）版本。由于Jira 8.8对数据库做过较大改动，数据库方式导入要求Jira 8.8及以上；8.8以下版本可以改用文件或接口方式导入，或者先升级再走数据库方式。

目标侧同样有版本门槛。禅道开源版从21.6起支持Jira数据导入；企业版从11.6起，还支持迁移Jira中新增的Issue类型、自定义字段和workflow。版本不满足时，先升级再迁移，比迁到一半再补更省事。

还有一个前提容易被忽略：数据导入功能只有超级管理员可以操作，迁移前要先确认管理员账号可用。

2. 部署形态怎么选

国产项目管理工具通常同时提供私有化部署和SaaS两种形态，禅道官网的部署说明对此有明确区分。私有化部署把数据和运行环境放在企业自有网络中，便于按自身安全策略实施加密、权限和审计；SaaS免安装维护、开箱即用，可以随业务按需扩容。选择时要按合规等级和数据敏感度判断，而不是默认沿用旧系统的形态。

3. 信创环境要逐层确认

如果这次替换同时承担国产化要求，还要确认信创环境。信创环境指的是操作系统、数据库、中间件、CPU等国产化底座。需要把这几层分别用哪一套确认清楚，确认时不能只看单个产品是否拿到适配认证，还要看这些组件组合起来能否通过联调测试。建议把各层的版本号和适配证明列成一张表，作为上线前的核对依据。

4. 管理模型与流程能否承载

目标工具要能承载团队现在的管理方法。禅道支持IPD、SAFe、CMMI、Scrum、Kanban（看板）、Waterfall（瀑布）、ASPICE、国军标（GJB）及DevOps等九大项目管理模型框架和方法。迁移前要确认目标工具支持哪些模型、工作流能否按现有流程配置，避免导入后才发现流程跑不通。

版本、部署形态、信创底座和模型支持要一起确认，其中任何一项不满足，都会影响导入能否顺利进行。

三、打通数据通道，校验数据完整性

前两项确认完，才轮到怎么把数据拿过来。这一步的关键不是能不能导，而是导得全不全。

1. 三种导入方式怎么选

禅道的Jira数据导入提供三种方式，下表对比它们的适用条件，便于按源系统形态选择：

选择导入方式时先看源系统形态：本地部署优先用数据库导入，云版本选文件或接口导入。数据量较大时，尽量避开受接口限速的方式，把接口方式留给无法获取数据库的场景。

2. 导入前后要确认的四件事

完整性校验建议按四个方面逐项确认。源系统侧，数据库备份要连同附件一起导出，只备份库不带附件，迁移后历史Bug和需求中的截图、文档会缺失。目标系统侧，导入前先备份目标库；如果目标工具已经在使用，导入过程中建议停止使用，避免新产生的数据与导入数据冲突。数据一致性上，导入完成后抽查几条链路，确认需求到任务再到Bug、用例的关联是否还在。账号层面，同一用户在源系统和目标系统都有账号时，要保证账号和邮箱一致，否则可能被识别成两个人。

迁移完成后值得优先检查的，是关联和附件是否完整，而不只是数据是否导入完整。

四、建立对象、字段、状态与权限映射

这是5项准备里信息量较大的一步，也是决定迁移后好不好用的一步。所谓映射，就是把源系统的对象类型、字段、状态和解决方案分别对应到目标工具的同类项。旧系统这些内容通常都做过自定义，直接导入会出现对不上的情况，所以要提前建立对应关系。

1. 对象映射：Issue 类型对应到哪些对象

第一步是把源系统的Issue类型对应到目标工具的对象：需求、任务、Bug、用例、反馈、工单，以及工作流对象。选择映射时，如果选新增成工作流，导入后系统会自动在工作流中创建一个新对象，字段、状态和解决方案的映射由系统自动处理，省去逐项配置。既没有默认值、也找不到可对应对象的Issue类型，才需要人工逐个指定。

2. 字段、状态与解决方案映射

字段层面，源系统的自定义字段可以选择新增，或映射到目标工具的已有字段，没有选择的字段不会被导入。状态层面，要设置源系统状态与目标工具状态、阶段的对应关系，例如需求状态、任务状态、Bug状态分别落到哪里；不选择映射时，系统会给出默认状态，例如需求为激活、阶段为未开始。解决方案层面，要把源系统的解决方案对应到目标工具的Bug解决方案和关闭原因。

3. 用户与权限映射

用户导入时可以选择使用源系统账号或邮箱，推荐使用账号。需要注意的是，导入后的用户名如果与目标系统已有用户名一致，会被合并为同一个用户，所以导入前要检查重名，避免不同用户被并成一人。另外，两套系统的密码加密算法不同，导入用户需要统一设置默认密码和权限分组。

映射方案最好在导入前确认清楚，导入后再调整，返工成本会明显上升。

五、制定试用验证与上线切换方案

最后一项准备要回答两个问题：怎么判断迁移成功，以及出问题怎么退回去。

1. 先小范围试用

选一个真实项目先在目标工具里跑通一轮完整流程，从需求录入、任务拆分、Bug提交到用例执行，确认数据能关联、报表能出数、权限符合预期。小范围试用能提前暴露映射层面的问题，同时不影响其他团队。

2. 准备切换窗口和回退路径

数据导入会占用服务器资源，导入过程尽量安排在非工作时段，并避开与发版、结项等关键节点重叠。正式切换前要准备好回退路径：源系统的数据和配置保持只读保留，目标系统切到正式使用后如果发现问题，可以退回原环境并行处理。

3. 上线后确认迁移是否成功

上线后可以从三个可观察的点确认结果。一是数据核对：随机抽取若干需求和Bug，检查标题、状态、负责人和上下游关联是否与源系统一致。二是附件核对：抽查含附件的条目，确认截图和文档可以正常打开。三是权限核对：按角色抽样登录，确认各角色能看到和操作的范围符合预期。三点都通过，再进入正式使用。

此外还要针对关键角色做一次简短培训，把新工具里需求、任务、Bug、用例的流转方式讲清楚。工具换了，工作习惯也要跟着调整。

六、常见问题

1. 迁移大概要停业务多久？

停机时间主要取决于数据量、附件大小和导入方式。数据库和文件导入通常比接口导入快，接口方式还会受源系统请求频率限制。稳妥的做法是先拿一个项目子集试导一次，用实测耗时估算全量窗口，再把正式导入安排在非工作时段。

2. 数据量很大，能分批迁移吗？

可以。建议按产品线或项目群拆分批次，每批导入后单独做一次完整性校验，确认没有问题再导入下一批。分批的好处是单次影响面小，出问题时容易定位到具体批次。需要注意的是，跨项目的关联数据要在拆分时记录清楚，避免关联断裂。

3. 源系统可以马上停用吗？

不建议马上停用。切换后先保留一段只读观察期，给关键账号保留查看权限，确认历史查询、统计报表和审计追溯都不再依赖源系统后，再走停用流程。观察期长度可以按团队交付节奏来确定。

七、结语

迁移前要确认的5项准备，可以压缩成一张核对清单，逐项确认后再开始导入：

这张清单覆盖了迁移前的关键决策点。范围和映射决定迁移后是否好用，环境和验证决定上线是否平稳。

如果是从Jira这类国外工具迁移到禅道，官方已经提供了从数据库、文件到接口的多种导入方式，以及对象、字段、状态、解决方案和用户的映射配置项，大部分迁移工作可以通过导入流程完成，也可以参考国产替代与Jira迁移一站式方案了解适配范围。