Jira 迁移验收要回答的核心问题是：迁移后的系统能否支撑业务正常运行，并且出现问题时能够回退。这份清单按迁移前准备、数据与配置迁移、试迁移与正式切换、上线后观察组织检查项，每项写明通过标准、证据和负责人，并标出阻断项。阻断项未关闭，不进入下一阶段。清单适用于迁移负责人、Jira 管理员、业务线代表、IT/安全人员和最终用户代表，在试迁移后、正式切换前和观察期分别执行。
要点总览（TL;DR）
- 验收按迁移前准备、数据与配置迁移、试迁移与正式切换、上线后观察四个阶段推进，每项检查写明通过标准、证据和负责人。
- 通过标准要可观察、可复核，尽量带数量或状态阈值，例如抽样 20 个问题关键字段一致率 100%、关键流程 5 条全部走通。
- 数据丢失、权限越权、关键流程不可用、回退方案缺失四类问题作为阻断项，未关闭不进入下一阶段。
- 验收完成以阻断项全部关闭并签字、非阻断项有整改计划、观察期反馈处理完毕、记录归档为条件。
- 把检查项建为工作项，负责人、状态、证据和放行条件在同一处追踪，交接时按阶段检索即可。
谁在什么时点使用这份验收清单
验收责任需要落到具体角色，避免出现“大家都看过、没人签字”的情况。建议在项目启动时确定各角色，并在每个检查时点前确认参与人。下表给出角色与时点的对应关系，实际项目可按团队规模合并角色，但签字责任不能省略。
| 角色 | 主要职责 | 参与时点 |
|---|---|---|
| 迁移负责人 | 组织验收、汇总结论、判定阻断项是否关闭、签署阶段放行 | 全部时点 |
| Jira 管理员 | 提供数据比对结果、字段与工作流映射说明、权限配置证据 | 迁移前、试迁移后、正式切换前 |
| 业务线代表 | 确认关键流程可用、抽样核对本业务线数据、确认用户可操作 | 试迁移后、切换后观察期 |
| IT/安全 | 核对账号与权限映射、集成连通性、备份与回退方案 | 迁移前、正式切换前 |
| 最终用户代表 | 执行首日可用性抽查，反馈入口、通知、常用操作问题 | 切换后观察期 |
清单的使用方式是逐项记录，而非整体打勾。每项检查填写结论（通过/未通过/不适用）、证据位置和负责人签字；未通过项写明原因和复检时间。阶段放行以阻断项全部关闭为前提，非阻断项可以带条件通过，但需登记整改期限。
迁移前准备阶段检查项
准备阶段的目标是锁定迁移范围和前置条件。范围不清、映射未评审、回退方案缺失，都会让后续验收失去判断基准。下表检查项需在正式迁移开始前完成。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 迁移范围清单 | 项目、问题类型、附件、评论、历史记录逐项列明，并经业务线确认无遗漏 | 范围清单文档及确认记录 | 迁移负责人 | 是 |
| 账号与权限映射方案 | Jira 用户、组、项目角色与目标系统账号一一对应，无未映射账号 | 映射表、IT/安全评审记录 | Jira 管理员、IT/安全 | 是 |
| 字段、状态、工作流映射表 | 自定义字段、状态、流转规则均有对应关系，业务线代表已评审签字 | 映射表及评审记录 | Jira 管理员 | 是 |
| 备份与回退方案 | 源系统备份完成并验证可恢复；回退触发条件、操作步骤、责任人明确 | 备份验证记录、回退方案文档 | IT/安全 | 是 |
| 干系人通知与培训安排 | 切换时间、冻结期、新入口和操作变化已通知到用户；培训或操作指引已发放 | 通知记录、培训签到或指引文档 | 迁移负责人 | 否 |
范围清单要具体到项目和数据对象，例如“包含 A、B 两个项目的全部问题类型及附件，不含已归档项目”。回退方案需要写明在什么条件下启动回退、由谁决策、回退后源系统如何恢复写入，这些内容在切换前确认，切换当天才补会来不及。
数据与配置迁移检查项
这一阶段核对迁移结果与源系统的一致性。检查对象是数据完整性、字段映射、流程配置和权限方案，判断依据是可复核的比对结果，而非迁移工具的运行日志。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 问题数量比对 | 各项目问题总数与源系统一致，差异逐条说明原因 | 数量比对报告 | Jira 管理员 | 是 |
| 关键字段抽样 | 按项目抽取约定数量的问题，标题、描述、经办人、优先级、截止日期等关键字段一致 | 抽样记录及差异清单 | Jira 管理员、业务线代表 | 是 |
| 附件与评论完整性 | 抽样问题的附件可下载打开，评论条数与内容一致 | 抽样截图、比对记录 | Jira 管理员 | 是 |
| 历史变更记录 | 抽样问题的状态变更、经办人变更等历史可查，时间顺序正确 | 历史记录截图 | Jira 管理员 | 否 |
| 状态与工作流流转 | 关键流程按映射后配置实际走通，状态名称、流转条件、必填项符合预期 | 流程走查记录 | 业务线代表 | 是 |
| 权限与角色映射 | 抽样账号在目标系统中可见项目、可执行操作与源系统一致，无越权访问 | 权限核对表、越权测试记录 | IT/安全 | 是 |
| 看板、过滤器等配置 | 常用看板和过滤器已迁移或重建，筛选结果与源系统一致 | 配置清单及结果比对 | Jira 管理员 | 否 |
抽样口径要在检查前约定，例如每个项目抽取 20 个问题，覆盖不同问题类型和状态。历史变更记录、看板与过滤器的迁移覆盖程度，建议在项目启动时向迁移实施方确认具体范围，再据此设定通过标准，避免验收时才发现口径不一致。
试迁移与正式切换检查项
试迁移验证迁移方案是否可行，正式切换验证切换动作是否按计划完成。两个时点的检查重点不同，不能合并为一次验收。
试迁移后
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 试迁移验证结论 | 数据、流程、权限三类检查完成，问题清单已登记 | 试迁移验收报告 | 迁移负责人 | 是 |
| 问题关闭情况 | 阻断级问题全部关闭并复检通过；非阻断问题有整改计划 | 问题清单及复检记录 | Jira 管理员 | 是 |
| 迁移耗时与窗口匹配 | 试迁移实际耗时在计划窗口内，正式迁移时间安排据此确认 | 迁移日志、时间记录 | 迁移负责人 | 否 |
正式切换前后
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 冻结期执行 | 源系统在约定时间停止写入，冻结期间无新增业务数据 | 冻结通知、系统记录 | 迁移负责人 | 是 |
| 切换后入口与登录 | 新系统地址可访问，抽样用户可正常登录 | 登录测试记录 | IT/安全 | 是 |
| 通知与集成连通性 | 邮件通知可发出，与代码仓库、CI、IM 等集成连接正常 | 通知测试、集成连通记录 | Jira 管理员 | 是 |
| 用户首日可用性抽查 | 用户代表完成创建问题、流转、评论、上传附件等常用操作 | 抽查记录及问题反馈 | 最终用户代表 | 是 |
切换后观察期建议至少覆盖一个完整业务周期，观察期内每日汇总用户反馈，按阻断与非阻断分类处理。观察期结束前，回退方案保持可用状态。
每项检查的通过标准与证据要求
通过标准写得含糊，验收就会变成主观判断。可用的通过标准通常包含数量、比例或明确状态，例如“抽样 20 个问题，关键字段一致率 100%”“关键流程 5 条全部走通”“越权测试 0 例”。无法量化的项目，用可观察的状态描述，例如“附件可下载并正常打开”。
| 证据类型 | 适用检查项 | 留存要求 |
|---|---|---|
| 截图 | 字段内容、附件、历史记录、权限界面 | 注明问题编号、检查人和日期 |
| 比对报告 | 问题数量、字段抽样、看板筛选结果 | 附差异清单及原因说明 |
| 抽样记录 | 关键字段、评论、附件、用户操作 | 记录抽样规则和样本清单 |
| 签字确认 | 范围清单、映射表、阶段放行 | 签字人与日期可追溯 |
未通过项要记录三项内容：不符合的具体表现、影响范围和复检时间。复检时使用同一通过标准，复检通过后更新结论并保留原记录，便于后续复盘。证据统一存放在验收工作项或指定文档库中，避免散落在个人聊天记录里。
阻断项与完成条件
阻断项的判定原则是：该项不通过时，业务无法正常开展或存在不可接受的风险。以下四类问题应作为阻断项处理，未关闭不得进入下一阶段。
| 阻断项 | 判定标准 | 关闭条件 | 责任人 |
|---|---|---|---|
| 数据丢失 | 问题数量、关键字段、附件或评论存在无法解释的缺失 | 差异逐条查明并补齐，或经业务线确认可接受并签字 | Jira 管理员 |
| 权限越权 | 抽样账号可见不应可见的项目或可执行未授权操作 | 权限配置修正后复测通过 | IT/安全 |
| 关键流程不可用 | 核心业务流转无法走通或状态错误 | 流程配置修正并重新走查通过 | 业务线代表 |
| 回退方案缺失 | 无可用备份、无回退步骤或无决策责任人 | 回退方案完成演练或验证，责任人确认 | IT/安全 |
整体验收完成的条件包括：全部阻断项关闭并有签字；非阻断项有明确整改计划和时间；观察期用户反馈完成分类处理；验收记录归档。签署方式建议由迁移负责人汇总，业务线代表和 IT/安全分别确认各自范围，形成一份阶段放行记录。
用工作项承载验收记录与交接
清单如果只存在于表格文件中，阻断项状态和阶段放行容易脱节。把检查项建为工作项，可以让负责人、状态、证据和放行条件在同一处追踪。ONES 工作项管理支持为每个检查项设置负责人、状态和截止时间，将比对报告、截图等证据作为附件关联到对应工作项，评审意见记录在评论中。
具体做法是：按阶段建立工作项分组，阻断项单独标记并在状态上限制流转，只有阻断项关闭后，阶段放行工作项才能进入完成状态。验收结论和证据随工作项归档，后续复盘或交接时按阶段检索即可。这样，验收记录从个人表格转为团队可查的过程记录，交接时不需要重新收集材料。
常见问题
试迁移发现问题较多时，正式切换时间要不要顺延？
判断依据是问题是否属于阻断项。阻断级问题未关闭并复检通过，正式切换应顺延；非阻断问题可以带整改计划进入切换，但需登记整改期限和责任人。顺延决策由迁移负责人根据问题清单作出，并同步通知干系人调整冻结期和培训安排。
源系统里已归档的项目要不要纳入迁移范围？
由业务线在准备阶段明确决定，并写入范围清单。常见做法是只迁移仍在使用的项目，归档项目保留只读备份。无论哪种选择，都要在范围清单中写明边界，例如“包含 A、B 两个项目的全部问题类型及附件，不含已归档项目”，避免验收时对数量差异产生争议。
观察期要持续多久，期间还能启动回退吗？
观察期建议至少覆盖一个完整业务周期，具体长度按业务节奏确定。观察期内回退方案保持可用状态，一旦出现阻断级问题且短时间无法修复，按切换前确认的触发条件和决策人启动回退。观察期结束、用户反馈分类处理完毕后，回退方案才可退出待命状态。
历史变更记录、看板、过滤器这类配置迁移到什么程度算通过？
先在项目启动时向迁移实施方确认这些对象的迁移覆盖范围，再据此设定通过标准。可用的写法是抽样比对：抽取约定数量的问题核对历史记录时间顺序，常用看板和过滤器逐一比对筛选结果。覆盖范围未确认前，不建议把“全部迁移”写成通过标准。
验收记录放在表格文件里，交接时要注意什么？
表格文件适合记录，但阻断项状态与阶段放行容易脱节。交接时至少保证三点：每项检查有负责人和结论，证据有统一存放位置，阻断项关闭与阶段放行有签字记录。把检查项建为工作项可以缓解这个问题，负责人、状态、附件和评审意见在同一处可查，交接时按阶段检索即可。
