Jira 迁移验收清单要长期可用，需要把它当作有版本、有责任人、有触发条件的活文档：明确谁在什么时点更新，按迁移阶段拆分检查项，每项写清通过标准、证据和负责人，标出阻断项与解除条件，并在复盘、字段或流程变更、工具升级后回写清单。以下给出一套可直接套用的维护框架。
要点总览（TL;DR）
- 清单要指定归口人和各项负责人，并把更新时点写进清单：迁移启动前、试迁移后、正式切换前、切换后复盘，以及字段或流程变更、工具版本升级时。
- 按准备、试迁移、正式切换、切换后四个阶段组织检查项，每项写清负责人和检查时点，阶段划分建议保留，条目可按项目规模增删。
- 通过标准要可观察、可计数、可判定，例如“抽样200条含附件记录，差异数为0”；每项检查配证据类型和统一命名规则，证据放在固定目录。
- 阻断项集中在数据丢失、权限错配、关键工作流不可用、回退方案缺失四类，判定人与检查项负责人分开，解除阻断须附复检证据。
- 清单用版本号与修订记录管理，每次复盘结论、缺陷根因、字段或流程变更都回写为新增或修订的检查项，由归口人统一执行。
谁在什么时点更新这份清单
清单失效通常源于两个原因：没人负责维护，或者只在迁移启动时用一次。要让清单持续有效，先要确定使用对象、维护责任人和更新触发时点，再谈检查项内容。
使用对象决定清单的颗粒度。迁移负责人关注整体进度与阻断项；业务系统负责人关注字段映射、工作流和权限是否符合本部门实际；测试与运维关注数据完整性、通知和回退可用性；数据核对人关注记录数、附件和评论的逐项比对。四类角色在清单上看到的重点不同，但共用同一份条目和同一套通过标准。
维护责任人建议分两层：清单归口人负责整体版本、结构和修订记录，通常由迁移负责人或项目经理担任；每个检查项的负责人对该项的通过标准和证据负责，由对应职能角色担任。归口人不替各项负责人判断技术结果，只负责汇总状态、组织评审和发布新版本。
更新时点要写进清单本身，而不是靠记忆。常见触发条件如下表：
| 触发时点 | 更新内容 | 责任人 |
|---|---|---|
| 迁移启动前 | 确认检查项范围、负责人、通过标准初稿 | 清单归口人 |
| 试迁移完成后 | 根据试迁移暴露的问题补充或修订检查项 | 各项负责人，归口人汇总 |
| 正式切换前 | 冻结检查项版本，确认阻断项全部关闭 | 迁移负责人 |
| 切换后复盘 | 回写缺陷根因、新增检查项、清理失效条目 | 清单归口人 |
| 字段或流程变更 | 更新映射相关检查项与通过标准 | 业务系统负责人 |
| 工具版本升级 | 复核依赖版本的功能检查项 | 测试与运维 |
更新频率建议与迁移节奏绑定：迁移期间按周评审一次，切换窗口内按日同步阻断项状态，切换完成后转入季度评审。例外情况包括临时变更需求、监管或审计要求、重大缺陷复盘，这类情况不受固定周期限制，由归口人发起临时修订并记录原因。
按迁移阶段拆分的检查项
清单结构稳定的前提是按迁移阶段组织检查项，每个阶段有明确的进入和退出条件。下面给出一个可直接套用的框架，团队可按项目规模增删条目，但阶段划分建议保留。
| 阶段 | 检查项 | 负责人 | 检查时点 |
|---|---|---|---|
| 准备 | 迁移范围已确认，项目、问题类型清单完成 | 迁移负责人 | 启动前 |
| 准备 | 字段、状态、工作流映射表完成并经业务确认 | 业务系统负责人 | 启动前 |
| 准备 | 账号、用户组、权限配置梳理完成 | 系统管理员 | 启动前 |
| 准备 | 备份方案与回退方案已评审通过 | 运维 | 启动前 |
| 试迁移 | 样本数据量与实际记录数一致 | 数据核对人 | 试迁移后 |
| 试迁移 | 附件、评论、历史记录完整可查 | 数据核对人 | 试迁移后 |
| 试迁移 | 工作流流转与通知触发符合预期 | 测试 | 试迁移后 |
| 正式切换 | 数据冻结窗口已通知并执行 | 迁移负责人 | 切换前 |
| 正式切换 | 增量同步完成且核对通过 | 数据核对人 | 切换时 |
| 正式切换 | 用户通知与培训完成 | 业务系统负责人 | 切换前 |
| 切换后 | 抽样数据核对通过，差异已记录 | 数据核对人 | 切换后一周内 |
| 切换后 | 旧系统只读保留，访问方式已公告 | 运维 | 切换后 |
| 切换后 | 用户问题收集完毕并逐项闭环 | 迁移负责人 | 切换后两周内 |
准备阶段的重点是范围与映射，这一阶段遗漏的字段或权限问题，到试迁移阶段会以数据差异的形式放大。试迁移阶段用真实样本验证完整性，样本量要覆盖主要问题类型、含附件的记录和跨项目关联。正式切换阶段的核心是冻结窗口和增量同步，通知与培训要在此之前完成。切换后阶段不能省略旧系统只读保留和问题闭环，这两项决定团队能否平稳过渡。
每项检查的通过标准与证据
检查项写成“建议做好数据核对”就无法判断是否完成。通过标准要满足三个条件：可观察、可计数、可判定。可观察指结果能被第三方看到；可计数指有明确的数量或比例；可判定指结论只有通过或不通过，没有“基本完成”。
写法上，把动作换成结果。例如“核对附件完整性”改为“抽样 200 条含附件记录，附件可下载且文件大小与原系统一致，差异数为 0”。再如“验证权限”改为“抽取 5 个典型角色登录，可见项目范围与原系统一致，越权访问数为 0”。
| 检查项 | 通过标准示例 | 证据类型 | 留存位置 |
|---|---|---|---|
| 记录数核对 | 各项目问题数与源系统导出数一致，差异为 0 或已逐条说明 | 导出记录、核对报告 | 迁移项目文档库/核对报告目录 |
| 附件完整性 | 抽样记录附件可下载，大小与源系统一致 | 截图、抽样清单 | 迁移项目文档库/证据目录 |
| 权限配置 | 典型角色可见范围与原系统一致，越权数为 0 | 截图、签字确认 | 迁移项目文档库/权限核对目录 |
| 工作流可用 | 关键流程可完整流转，通知按规则触发 | 操作日志、截图 | 迁移项目文档库/流程验证目录 |
| 回退方案 | 回退步骤经演练可在约定时间内完成 | 演练记录、签字确认 | 迁移项目文档库/回退方案目录 |
证据留存要有统一命名规则，建议采用“阶段-检查项编号-日期-版本”的格式，例如“试迁移-C03-20250610-v1”。证据放在固定目录，清单中只记录位置索引，避免把大文件直接嵌入清单。无法判定时，由该项负责人提交说明，注明缺失信息和影响，升级给清单归口人决定是按“有条件通过”记录还是挂起，挂起项在下次评审时必须给出结论。
阻断项与完成条件
并非所有检查项都同等重要。阻断项指不通过就不能进入下一阶段的条目，识别标准集中在四类：数据丢失或无法核对、权限错配导致越权或不可见、关键工作流不可用、回退方案缺失或未演练。
| 阻断项 | 判定人 | 解除条件 | 复检要求 |
|---|---|---|---|
| 记录数差异未说明 | 数据核对人 | 差异逐条定位并补齐或书面确认可接受 | 重新全量核对一次 |
| 权限错配 | 系统管理员 | 权限配置修正，典型角色复测通过 | 抽样角色复测并留证 |
| 关键工作流不可用 | 测试 | 流程修复并完成端到端验证 | 关键流程全量回归 |
| 回退方案缺失 | 运维 | 方案评审通过并完成演练 | 演练记录归档 |
阻断项的判定人要与检查项负责人分开，避免自己检查自己放行。升级机制建议设两级：一级由迁移负责人在日会上协调，二级在阻断项超过约定时限未解除时升级到项目决策层。解除阻断必须附复检证据，复检由判定人或其指定人员执行，复检通过后清单状态才可改为关闭。
非阻断项单独记录，注明影响范围、计划处理时间和跟踪人，在切换后复盘时逐项确认。非阻断项不能因为不影响上线就长期挂起，超过约定周期未处理的，由归口人评估是否升级为阻断项或正式关闭。
清单的版本管理与回写机制
清单的每次修订都要可追溯，否则无法判断某个检查项是何时加入、因何修改。修订记录至少包含五个字段：版本号、日期、修订人、变更内容、影响范围。版本号建议采用主次版本，结构或阻断项调整升主版本，条目措辞和证据要求调整升次版本。
| 版本 | 日期 | 修订人 | 变更内容 | 影响范围 |
|---|---|---|---|---|
| v1.0 | 迁移启动前 | 清单归口人 | 建立分阶段检查项与通过标准初稿 | 全部阶段 |
| v1.1 | 试迁移后 | 数据核对人 | 新增附件抽样比例要求 | 试迁移、切换后 |
| v2.0 | 切换后复盘 | 清单归口人 | 新增权限复测为阻断项，清理失效条目 | 准备、正式切换 |
回写时机与内容要对应：每次复盘结论转化为新增或修订的检查项；每个缺陷的根因分析对应一条通过标准的收紧；新增的字段或流程变更对应映射检查项的更新。回写由归口人统一执行，避免多人同时改同一份清单造成冲突。
清单存放位置要唯一，建议放在迁移项目共用的文档空间，设置编辑权限给归口人和各项负责人，其他成员只读。定期评审建议每季度一次，评审内容包括失效条目清理、通过标准是否仍可判定、阻断项清单是否仍适用。工具版本升级或组织流程调整后，应触发一次专项评审，而不是等到下个固定周期。
用协作平台承载清单的更新与维护
清单维护中最常见的问题是版本散落在多个文档、责任人只写在表头、证据分散在个人电脑。把清单拆成“文档承载正文与修订记录、工作项承载检查项执行”两部分，可以让更新动作有明确落点。
具体做法是：把每个检查项建成工作项，字段包含所属阶段、负责人、检查时点、通过标准和证据位置，截止时间与迁移里程碑对齐。清单正文和修订记录放在文档中，保留版本历史，评审通过后发布新版本，工作项引用对应版本文档。阻断项用状态和标签标记，评审后按“待处理—复检中—已关闭”流转，状态变更留痕。复盘结论由归口人回写为新增或修订的检查项，并在修订记录中注明来源。
ONES 的 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并可迁移用户、用户组、问题类型、工作流、字段配置、权限配置等问题数据相关配置，这为迁移后的验收核对提供了对应对象。迁移前建议按 ONES 的实践先确认数据范围、功能匹配和系统适配，把插件依赖和定制场景逐项评估，再据此确定检查项和通过标准。清单模板、版本管理和权限控制的具体实现方式，建议在选型阶段结合实际环境向原厂确认。
常见问题
迁移验收清单由谁维护，归口人和各项负责人如何分工？
建议分两层：清单归口人负责整体版本、结构和修订记录，通常由迁移负责人或项目经理担任；每个检查项的负责人对该项的通过标准和证据负责，由对应职能角色担任。归口人不替各项负责人判断技术结果，只负责汇总状态、组织评审和发布新版本。这样既有人对清单整体负责，每项检查也有明确的责任人。
试迁移后清单需要做哪些调整？
试迁移是清单第一次接受真实数据检验的时点。建议根据试迁移暴露的问题补充或修订检查项，重点看三类情况：样本数据量与实际记录数是否一致、附件和评论是否完整可查、工作流流转与通知是否符合预期。发现遗漏的检查项或通过标准写得太松，由各项负责人提出修订，归口人汇总后发布新版本，并在修订记录中注明变更来源。
通过标准写得太模糊怎么办？
把动作描述换成结果描述。例如“核对附件完整性”改为“抽样200条含附件记录，附件可下载且文件大小与原系统一致，差异数为0”；“验证权限”改为“抽取5个典型角色登录，可见项目范围与原系统一致，越权访问数为0”。如果某项确实难以量化，由该项负责人提交说明，注明缺失信息和影响，升级给归口人决定按有条件通过记录还是挂起，挂起项在下次评审时必须给出结论。
阻断项解除后还需要复检吗？
需要。解除阻断必须附复检证据，复检由判定人或其指定人员执行，复检通过后清单状态才可改为关闭。复检要求因阻断类型不同：记录数差异未说明的，重新全量核对一次；权限错配的，抽样角色复测并留证；关键工作流不可用的，关键流程全量回归；回退方案缺失的，演练记录归档。复检证据与初次检查证据放在同一目录，便于追溯。
清单多久评审一次，哪些情况可以临时修订？
迁移期间建议按周评审一次，切换窗口内按日同步阻断项状态，切换完成后转入季度评审。临时变更需求、监管或审计要求、重大缺陷复盘等情况不受固定周期限制，由归口人发起临时修订并记录原因。工具版本升级或组织流程调整后，应触发一次专项评审，而不是等到下个固定周期。
