Jira 迁移工具选型，核心是确认它能否把你现有的项目、问题、字段、工作流、附件、评论和历史记录完整还原到目标系统，并且迁移过程可试跑、可核对、可回退。建议先定迁移范围与验收口径，再按数据覆盖、映射、可重复性、校验追溯、权限合规五类能力逐项核查，用真实样本试迁移验证，而不是只比对功能清单。
要点总览（TL;DR）
- 选型前先把迁移范围写成对象清单并标注保真等级，同时定义可计算的验收口径，如问题数量一致、抽样比对差异为零、失败率上限。
- 核心检查五类能力：数据覆盖与字段映射、工作流与权限方案对应、迁移方式与可重复性、校验日志与失败处理、账号体系与数据位置。
- 用同一份脱敏样本对候选工具试迁移，逐字段比对内容、附件和历史记录，并索取迁移日志与失败明细样例作为证据。
- 功能清单齐全不代表真实数据可迁移，自定义字段、插件数据和工作流特例需要书面确认支持程度。
- 切换前设定通过条件并安排回退演练，由业务负责人和管理员共同验收后再正式上线。
先定迁移范围与验收口径
选型的第一步是把“能不能迁”变成一份可勾选的范围清单。不同团队对“迁移完成”的理解差异很大：有人只要求问题标题和描述到位，有人要求历史评论、附件版本和状态流转记录全部保真。口径不统一，后续任何工具的演示结果都无法横向比较。
范围清单建议按对象逐项列出，并标注保真等级。保真指迁移后内容、结构、关联关系与源系统一致；可重建指允许在目标系统重新配置或补录；可舍弃指明确不迁移。这份清单同时是向候选工具提问的底稿。
| 对象 | 需要确认的内容 | 保真等级建议 |
|---|---|---|
| 项目与问题 | 项目数量、问题类型、问题键值、创建与更新时间 | 必须保真 |
| 字段与自定义字段 | 字段类型、选项值、必填规则、字段与问题类型的绑定关系 | 字段值必须保真，配置可重建 |
| 状态与工作流 | 状态名称、流转路径、流转条件、触发器 | 状态与历史流转保真，复杂条件可重建 |
| 附件与评论 | 附件数量与大小、评论作者与时间、内嵌图片 | 必须保真 |
| 历史记录 | 变更历史、状态变更人、字段修改记录 | 按合规要求确定，通常需保真 |
| 用户与权限 | 账号映射、用户组、项目角色、权限方案 | 账号映射必须核对，权限方案可重建 |
验收口径要写成可计算的指标：问题总数与迁移后数量是否一致、附件数量与总容量是否一致、抽样比对多少条问题、失败率上限是多少、哪些差异属于可接受范围。例如“随机抽取 30 条含附件和多次状态变更的问题，逐字段比对，差异为 0”就是一条可执行的验收条件。把这份清单和口径固定下来，再进入能力核查。
Jira 迁移工具要检查的核心能力
能力核查建议按五个能力域组织，每个能力域对应一组具体检查项。这样做的目的是让不同候选工具在同一张表上回答，避免被演示中挑选过的顺利场景带偏。
数据覆盖与字段映射
先确认工具声明支持哪些对象：项目、问题、字段与自定义字段、状态与工作流、附件、评论、历史记录、用户与用户组。以 ONES 的 Jira 迁移方案为例，官方资料描述迁移范围可覆盖项目、工作项、状态、字段、流程、附件和历史记录，并可迁移问题类型、工作流、字段配置、权限配置等系统配置，以及问题属性、属性值、附件、评论和用户、用户组。这些描述可以作为提问的参照，但具体到你的自定义字段类型和插件数据，仍需在试迁移中确认映射规则。
字段映射要重点核查三类情况：文本、单选、多选、日期、数值等基础类型能否直接对应；用户选择器、级联选择、公式类字段在目标系统中如何落地；插件生成的字段和面板数据是否在迁移范围内。映射规则不清晰的字段，往往在迁移后表现为空值或文本化，需要提前列出处理方案。
工作流、状态与权限方案的对应能力
工作流迁移的难点在特例：同一状态在不同项目中有不同流转条件，部分流转依赖插件校验或脚本。核查时要问清楚工具是迁移工作流定义、迁移历史状态记录，还是两者都迁移；目标系统中状态名称冲突时如何处理；权限方案是按原样继承还是需要重新配置。权限尤其要单独验证，因为迁移后项目角色与用户组的对应关系一旦错位，会出现成员看不到项目或权限过大的问题。
迁移方式与可重复性
需要确认工具支持全量迁移、增量迁移、试迁移、多次重跑和回滚中的哪些方式。试迁移用于在正式切换前暴露问题；重跑能力决定迁移失败后能否修正配置再执行，而不必从头开始；回滚安排决定切换失败时业务能否快速恢复。ONES 资料中提到批量迁移与数据包导入的迁移方式，但该表述出现在 Confluence 迁移段落，Jira 迁移是否同样支持增量、重跑与回滚，需要在选型沟通中单独确认。
校验、日志与失败处理
迁移不是一次性动作，结果需要可核对。检查项包括：迁移前后数量统计是否自动生成、失败记录是否精确到单条问题或单个附件、日志是否保留时间戳与操作人、失败项能否单独重试。缺少失败明细的工具，会把排查成本转嫁给你的团队。
账号体系、数据位置与运维成本
账号方面要确认用户映射规则：按邮箱、用户名还是人工对照表匹配；源系统中已停用的账号如何处理；迁移后通知和订阅行为是否变化。数据位置方面要确认数据在迁移过程中经过哪些环境、是否支持私有化部署、留存策略如何。运维成本则包括迁移窗口长度、迁移期间源系统是否需冻结写入、后续版本升级对迁移脚本的影响。
| 能力域 | 检查项 | 核查方式 |
|---|---|---|
| 数据覆盖与字段映射 | 对象清单、自定义字段类型、插件数据 | 对照范围清单逐项确认，用样本数据试迁移 |
| 工作流与权限 | 状态流转、流转条件、项目角色与权限方案 | 迁移后登录不同角色账号验证可见范围 |
| 迁移方式 | 全量、增量、试迁移、重跑、回滚 | 要求书面说明并安排一次试迁移 |
| 校验与日志 | 数量核对、失败明细、日志留存 | 索取样例迁移报告，检查字段完整度 |
| 账号与合规 | 用户映射、数据位置、迁移窗口 | 与 IT 和安全团队共同确认 |
各能力项的核查方法与证据
功能清单只能说明工具声称支持什么，证据要来自真实数据。建议从生产环境导出一份脱敏样本，覆盖典型项目和边界情况，作为所有候选工具的统一测试集。
样本应包含：一个使用自定义字段较多的项目、一个工作流分支较多的项目、含多次状态变更和评论的问题、带多个版本或较大体积的附件、已归档项目和已停用用户。用同一份样本分别试迁移，逐项记录还原结果，比口头演示更有说服力。
- 字段与内容还原：迁移后逐字段比对样本问题，记录空值、类型变化和截断情况；附件核对数量、文件名和可下载性；评论核对作者、时间和正文格式。
- 历史记录：抽查状态变更历史是否保留变更人和时间，字段修改记录是否完整。
- 迁移日志与失败明细：要求提供一次试迁移的完整日志样例，确认失败项能否定位到具体问题或附件，以及重跑时是否只处理失败项。
- 用户映射与权限继承：迁移后用不同角色账号登录，验证项目可见性、编辑权限和评论权限是否与源系统一致。
- 数据位置与迁移窗口：确认迁移期间源系统是否需要停止写入、预计停机时长、数据在迁移环境中的留存与销毁方式。
每项核查都应留下书面证据：试迁移结果记录、厂商提供的机制说明、双方确认的问题清单。证据类型比结论措辞更重要，因为切换后出现问题时要靠这些记录界定责任和补救方案。
常见误判与需要提前确认的边界
选型中最常见的误判是把功能清单的完整度等同于真实数据的可迁移性。清单通常按标准场景编写，而实际项目里的自定义字段、插件数据和工作流特例才是迁移难点。以下几类边界需要提前书面确认。
- 自定义字段与插件数据：插件生成的字段、面板、时间跟踪或自动化规则产生的数据，是否在迁移范围内；不在范围内时，目标系统中用什么方式承接。
- 历史记录、附件与评论的保真程度：这三类数据常被笼统描述为“支持迁移”，实际可能是部分保留，例如只保留最近若干条评论或附件仅迁移当前版本。需要逐项确认保留范围和例外。
- 迁移后的权限与通知变化：权限方案重建后，成员的项目可见范围和操作权限可能变化；通知规则、订阅和邮件提醒的行为也可能与源系统不同，需要在切换前评估对日常协作的影响。
- 迁移窗口与业务中断：正式迁移期间源系统是否冻结、冻结多久、期间新产生的问题如何处理，这些安排直接影响切换日期的选择。
建议把上述问题整理成书面确认清单，要求候选工具逐条回复“支持、部分支持、不支持、需定制”，并注明依据。口头承诺在切换出问题时难以追溯。
选型结论与试迁移验证建议
完成能力核查后，按迁移范围与验收口径给候选工具打分。打分维度可以直接沿用五个能力域，权重按团队实际情况设定：数据保真要求高的团队提高数据覆盖与校验的权重，合规要求高的团队提高权限与数据位置的权重。排序结果用于缩小范围，最终结论仍要经过试迁移验证。
试迁移建议按以下步骤推进：
- 选定一个真实项目作为试点，规模适中且包含自定义字段、附件和历史记录。
- 在目标系统搭建对应项目结构，执行一次全量试迁移，记录耗时和资源占用。
- 按验收口径核对数量、抽样比对内容、检查失败明细，形成问题清单。
- 修正配置后执行重跑，验证工具能否只处理差异部分，以及重跑结果是否稳定。
- 由业务负责人和管理员共同验收，确认权限、通知和日常操作流程可用。
切换前设定明确的通过条件，例如：样本问题字段差异为零、附件数量一致、失败项全部有处理记录、关键角色权限验证通过、回退方案经演练可用。任一条件不满足，应推迟切换而不是带着已知问题上线。迁移完成后，业务团队负责确认内容可用，管理员负责确认配置与权限正确，双方共同签署验收结论，为后续运维留下依据。
常见问题
Jira 迁移工具演示时表现很好，试迁移却出现大量空字段，问题可能出在哪？
常见原因是演示使用了标准字段和简单工作流，而你的项目中存在自定义字段类型、插件生成字段或级联选择等复杂结构，映射规则没有覆盖到。建议在试迁移前把字段按类型分组，逐类确认目标系统中的落点，并检查迁移日志中是否有字段被跳过或转为文本的记录。发现空值时先定位是映射缺失还是源数据本身为空，再判断是否需要调整配置重跑。
迁移工具声称支持历史记录和附件迁移，验收时应该核对到什么程度？
“支持迁移”通常需要进一步确认保留范围。验收时至少核对附件数量、文件名、大小和可下载性，评论的作者、时间与正文格式，以及状态变更历史中的变更人和时间是否保留。对合规要求高的团队，还应抽查字段修改记录的完整性。如果工具只保留最近若干条评论或仅迁移附件当前版本，应提前写入验收口径，明确这类差异是否可接受。
正式迁移期间源系统还能继续使用吗？迁移窗口怎么安排比较稳妥？
这取决于工具是否支持增量迁移。若只能全量迁移，通常需要在迁移窗口内冻结源系统写入，并提前通知团队暂停操作；窗口长度与数据量、附件体积和网络条件有关，应在试迁移中实测耗时后估算。若支持增量，可以先做一次全量基线，再在切换前同步增量变更，缩短停机时间。无论哪种方式，都应准备回退安排，并确认窗口内新产生的问题如何处理。
迁移后成员看不到原来的项目，是权限迁移失败了吗？
更可能是用户映射或权限方案重建时出现了错位。Jira 中的项目角色、用户组和权限方案在目标系统中往往需要重新对应，账号按邮箱或用户名匹配时也可能因重名、停用账号而产生遗漏。建议迁移后先用不同角色的账号登录，逐一验证项目可见性、编辑和评论权限，再对照源系统的权限方案检查差异。把用户映射结果和权限验证记录留档，便于后续排查。
候选工具都通过了能力核查，最终怎么决定选哪一个？
按迁移范围与验收口径给各工具打分，权重根据团队实际情况设定：数据保真要求高的团队提高数据覆盖与校验的权重，合规要求高的团队提高权限与数据位置的权重。打分用于缩小范围，最终结论仍要经过一次真实项目的试迁移，核对数量、抽样比对内容、检查失败明细，并验证重跑结果是否稳定。通过条件全部满足后再安排切换，任一条件不满足应推迟而不是带着已知问题上线。
