从 Jira 迁出前，风险应围绕五类问题逐项评估：迁移范围是否盘点清楚（项目、问题、附件、历史与权限）；字段与状态语义能否一一映射；历史数据与附件在目标端是否完整可读；用户、权限与自动化规则在切换后能否继续运行；以及切换窗口内如何冻结写入、校验结果并保留回退路径。评估的产出应是一份带责任人和通过标准的风险清单，而不是一份工具功能对比。本文聚焦迁移准备阶段，给出可执行的盘点、映射、校验与回退方法。
要点总览（TL;DR）
- 迁出范围先盘点清楚：按项目、问题类型、附件、评论历史、用户与权限组登记迁移对象，分成必须迁移、可归档、可丢弃三类并指定责任人。
- 字段与状态映射要落到转换规则：同名字段选项集合不同、同名状态流转条件不同，需逐项写明映射规则，无法映射的项登记处置方式并留痕。
- 用试迁移的可核对证据判断可用性：对比记录数、字段值、状态历史、附件可打开、评论顺序，差异分可接受与必须修复两类，后者二次验证。
- 切换前冻结写入并保留 Jira 只读快照与时间点，预设数据缺失超阈值、关键流程不可用、权限错乱等回退触发条件，明确判断人与执行人。
- 把盘点表、映射表、校验报告和回退方案组织成带责任人与通过标准的工作项，按阶段评审流转，文档与决策留痕便于复盘。
先界定迁出范围：哪些项目、数据与用户要动
迁出范围失控是首要风险。Jira 中往往沉淀了多年项目，其中一部分已经停止使用，一部分只作为历史档案保留，还有一部分仍在高频协作。如果不在动手前把“迁什么、留什么、丢什么”定下来，迁移工作量、校验成本和切换风险都会随范围膨胀而放大。
范围盘点建议按对象类别逐项登记，形成一张可核对的迁移范围盘点表：
| 对象类别 | 需要记录的信息 | 处置方式 | 责任人 |
|---|---|---|---|
| 项目 | 项目键、名称、负责人、活跃状态、问题数量 | 必须迁移 / 归档 / 丢弃 | 项目管理员 |
| 问题类型 | 类型名称、使用项目、字段配置 | 必须迁移 / 合并 / 丢弃 | Jira 管理员 |
| 附件 | 总容量、单文件上限、存储方式 | 必须迁移 / 仅保留链接 | 运维 |
| 评论与历史 | 评论数量、变更历史是否保留 | 必须迁移 / 仅保留摘要 | 项目管理员 |
| 用户与权限组 | 账号数量、用户组、项目角色 | 必须迁移 / 重新配置 | 系统管理员 |
处置方式要落到三类：必须迁移、可归档、可丢弃。可归档的数据可以导出为只读文件留存，不必进入目标系统；可丢弃的数据要写明判断依据和确认人，避免事后争议。Jira 的部署形态会影响导出方式——云版与数据中心版在管理员权限、导出入口和数据范围上存在差异，需要由 Jira 管理员确认当前版本可用的导出路径，再决定盘点表的口径。
同时要确定迁移窗口与业务冻结时段。冻结时段应覆盖正式切换前后的关键操作，并提前通知所有使用团队。窗口长度取决于数据量和校验方式，建议在试迁移后根据实际耗时再确认，而不是在盘点阶段拍定。
字段与状态映射：同名字段含义不同怎么处理
字段和状态是迁移中最容易“看起来迁过去了、实际不能用”的部分。两个系统里都叫“优先级”的字段，选项集合可能不同；都叫“处理中”的状态，在各自工作流中的前后流转条件可能完全不一样。映射工作的目标不是让名称对齐，而是让迁移后的数据在业务流程中仍然可读、可流转。
字段映射表建议包含以下列：源字段名、源字段类型、目标字段名、目标字段类型、是否必填、转换规则、未映射处置。转换规则要写具体，例如“Jira 的五级优先级映射为目标系统的三级，P0/P1 对应高，P2 对应中，P3/P4 对应低”，而不是只写“按优先级映射”。
状态与工作流的映射需要单独处理。先画出源系统的状态机，再对照目标系统的状态与流转条件，逐条确认：状态名称如何对应、流转由谁触发、审批节点放在哪里、哪些状态在目标系统中没有对应项。状态机差异较大的项目，可以考虑在目标系统中重建工作流，把历史状态作为记录保留，而不是强行套用。
自定义字段是风险集中区。级联选择、多值字段、公式字段在目标系统中可能没有等价类型，需要提前定好降级或拆分策略：
- 级联选择可拆为多个单值字段，或把完整路径写入文本字段保留原文；
- 多值字段可保留为标签或多选，若目标端只支持单值，则需明确保留哪一个值、其余值记录在哪里；
- 公式字段通常迁移计算结果而非公式本身，需确认历史值是否需要保留。
无法映射的项不能静默丢弃。每一项都要在未映射项清单中登记：字段名、影响的问题数量、处置方式（保留原文、合并、丢弃）、确认人和确认时间。这份清单既是迁移执行的输入，也是切换后排查问题的依据。
迁移前的输入与依赖：导出、权限和工具准备
迁移执行卡住，多数时候不是映射规则没想清楚，而是前置条件没到位。建议在正式迁移前整理一份前置条件清单，逐项标注“已满足、待确认、阻断”，阻断项未清零不进入试迁移。
Jira 侧需要确认的事项包括：执行导出所需的系统管理员权限、导出范围是否覆盖附件与历史、导出期间是否允许只读或需要短暂冻结写入、以及 Jira 管理员能否在迁移窗口内配合。这些事项依赖 Jira 侧人员，提前约定时间和联系人比事后催办更有效。
目标系统侧需要预建的内容包括：项目结构、字段与选项、用户账号与用户组、权限配置。预建顺序应与映射表一致，避免导入时因字段不存在而失败。附件迁移还要评估存储容量与网络传输条件，附件总量较大时，传输耗时和失败重试机制需要提前规划。
迁移脚本或导入工具应先在验证环境中跑通，验证环境的数据可以来自试迁移样本。验证环境的作用是暴露配置错误和脚本问题，把这类问题挡在正式切换之前。前置条件清单的完成标志是：所有阻断项已关闭，待确认项有明确结论和责任人，验证环境已具备可重复执行的迁移流程。
试迁移与校验：用什么证据判断迁移可用
判断迁移是否可用，靠的是可核对的证据，而不是“看起来差不多”。试迁移应选取代表性项目，覆盖多种问题类型、包含附件和评论、有一定历史记录，最好还包含使用了自定义字段和复杂工作流的项目。
试迁移完成后，按以下校验项逐条核对，并记录结果：
| 校验项 | 核对方法 | 通过标准 |
|---|---|---|
| 记录数 | 对比源与目标的问题总数、各问题类型数量 | 数量一致，差异有清单说明 |
| 字段值 | 抽样比对关键字段的取值与选项 | 抽样范围内取值一致或符合映射规则 |
| 状态历史 | 抽查问题的状态变更记录与时间 | 历史状态可读，顺序正确 |
| 附件 | 逐个打开抽样附件 | 可下载、可预览、文件名与大小一致 |
| 评论 | 核对评论内容、作者与时间顺序 | 内容完整，顺序正确 |
抽样人工核对要覆盖不同项目、不同问题类型和不同时间段的记录，避免只抽最新数据。核对中发现的每一处差异都进入差异清单，写明问题描述、影响范围、原因判断和处理结论。差异分为可接受差异（如格式微调）和必须修复差异（如附件缺失、状态错乱），后者修复后需要二次验证，二次验证的范围应覆盖原差异点及其相邻数据。
试迁移校验报告是进入正式切换的准入材料。报告结论应明确：哪些差异已关闭、哪些差异带条件接受、哪些问题需要在切换后跟踪。没有这份报告，正式切换就缺少判断依据。
切换、回退与停止条件
正式切换的核心是控制写入和保留退路。切换窗口内应冻结 Jira 侧的写入，冻结开始前通知所有使用团队，并明确冻结期间的新增需求记录在哪里、由谁在切换后补录。冻结时点同时是数据快照的时间点，回退时以这个时间点为准。
回退路径需要在切换前就准备好，包括保留 Jira 的只读快照、记录快照时间点、确认快照可访问。回退触发条件建议提前量化，例如：
- 关键项目的问题记录缺失超过约定阈值；
- 核心工作流在目标系统中无法流转，影响日常交付；
- 权限错乱导致用户无法访问应有项目或看到不应看到的数据；
- 附件大面积不可打开，影响评审与交付。
触发条件要写明判断人、判断时限和回退执行人。回退决策一旦做出，应有明确的执行顺序：停止目标系统写入、恢复 Jira 写入、通知团队、记录回退原因。回退不是失败，而是把问题控制在可恢复范围内。
切换后设置观察期，观察期内集中跟踪遗留问题：未关闭的差异项、用户反馈的异常、自动化规则未按预期运行的情况。观察期的结束标志是所有高优先级遗留问题已关闭或有明确处理计划。观察期内的反馈渠道和问题登记方式要提前告知团队，避免问题散落在聊天记录里。
风险清单怎么落到协作与评审上
前面几节产出的盘点表、映射表、前置条件清单、校验报告和回退方案，需要组织成可跟踪、可评审的工作项，否则容易停留在文档里无人推进。风险项作为工作项记录时，至少包含：风险类别、影响描述、发生概率、责任人、通过标准、当前状态。通过标准要可核验，例如“附件抽样 50 个全部可打开”，而不是“附件迁移完成”。
迁移任务与校验结果应有明确的状态流转和评审节点。典型流转是：范围盘点完成→映射表评审通过→前置条件清零→试迁移校验通过→切换方案评审→正式切换→观察期关闭。每个节点设置评审人，评审结论记录在对应工作项中，未通过则退回修改，不进入下一阶段。
迁移文档与映射表需要版本留存。字段映射表和未映射项清单在试迁移后往往会有修订，保留版本记录可以追溯某条映射规则何时变更、由谁确认。切换与回退决策同样要留痕：决策时间、决策人、依据的数据和结论，便于事后复盘。
这类过程管理可以在协作工具中承载。以 ONES 为例，其 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并可迁移用户、用户组、问题类型、工作流、字段配置和权限配置，问题数据中的属性、附件和评论也在迁移范围内。迁移前，团队可以把风险项、迁移任务和校验结果登记为工作项，用状态流转串联盘点、映射、试迁移、切换各阶段，把映射表和校验报告作为文档留存版本，让评审结论和回退决策有据可查。对于使用了 Jira 插件的团队，ONES 建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，定制场景仍需逐项评估，不宜假设所有插件都能一一对应。具体迁移范围与字段类型级别的映射规则，应以实际迁移方案和试迁移校验结果为准。
常见问题
Jira 云版和数据中心版在迁出准备上有什么不同？
两种部署形态在管理员权限、导出入口和数据范围上存在差异，会直接影响范围盘点的口径和导出方式的选择。准备阶段应由 Jira 管理员确认当前版本可用的导出路径、能否覆盖附件与历史记录、导出期间是否需要冻结写入，再据此确定盘点表的字段和迁移窗口。具体差异以企业实际使用的 Jira 版本和管理员确认为准，不宜按通用经验直接套用。
自定义字段在目标系统没有对应类型，应该保留还是丢弃？
先判断该字段是否承载业务判断依据。级联选择可拆为多个单值字段，或把完整路径写入文本字段保留原文；多值字段若目标端只支持单值，需明确保留哪一个值、其余值记录在哪里；公式字段通常迁移计算结果而非公式本身，要确认历史值是否需要保留。无论选择哪种处置，都要在未映射项清单中登记字段名、影响的问题数量、处置方式、确认人和确认时间，避免静默丢弃后在切换后引发争议。
试迁移要跑多少数据才算够？
判断标准是覆盖面而非数据量。样本应覆盖多种问题类型、包含附件和评论、有一定历史记录，最好还包含使用了自定义字段和复杂工作流的项目。校验时按记录数、字段值、状态历史、附件可打开、评论顺序逐项核对，抽样要覆盖不同项目、不同问题类型和不同时间段，避免只抽最新数据。试迁移校验报告是进入正式切换的准入材料，结论需明确哪些差异已关闭、哪些带条件接受、哪些需在切换后跟踪。
切换后发现部分附件打不开，应该立即回退吗？
是否回退取决于影响范围和预设阈值。回退触发条件应在切换前量化，例如关键项目记录缺失超过约定阈值、核心工作流无法流转、权限错乱导致越权访问、附件大面积不可打开。若只是个别附件异常，可先登记为遗留问题并在观察期内修复；若影响评审与交付的关键材料，则按预设条件启动回退。回退决策要写明判断人、判断时限和执行顺序：停止目标系统写入、恢复 Jira 写入、通知团队、记录回退原因。
迁移期间的风险和任务用什么方式跟踪比较稳妥？
把风险项作为工作项登记，至少包含风险类别、影响描述、发生概率、责任人、通过标准和当前状态，通过标准要可核验，例如“附件抽样 50 个全部可打开”。迁移任务按范围盘点、映射表评审、前置条件清零、试迁移校验、切换方案评审、正式切换、观察期关闭的顺序设置评审节点，未通过则退回修改。映射表和未映射项清单在试迁移后常有修订，需保留版本记录；切换与回退决策同样留痕，记录决策时间、决策人、依据数据和结论。这类过程管理可以在协作工具中承载，以 ONES 为例，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并可迁移用户、用户组、问题类型、工作流、字段配置和权限配置，团队可把风险项、迁移任务和校验结果登记为工作项，用状态流转串联各阶段，把映射表和校验报告作为文档留存版本。
