Jira迁移到ONES的数据验收，需要把“迁移完成”拆成可逐项判断的检查点：先锁定迁移范围与字段映射基线，再按试迁移、正式迁移、切换前三个关口核验问题、附件、评论、状态历史、用户权限与关联关系，最后以抽样比对和签字确认收口。每项检查都写明通过标准、证据和负责人；数量对不上、关键历史丢失、权限越界属于阻断项，未闭环不能宣布迁移完成。
要点总览（TL;DR）
- 验收分三个关口：试迁移后验证方案可行性，正式迁移后核对全量数据，切换前确认遗留项闭环并具备放行条件。
- 核对数据前先锁定迁移范围清单、字段映射表和用户对照表，三者是后续数量与内容比对的基准。
- 检查覆盖问题数量、字段与正文、评论、附件、状态历史、关联关系、看板筛选口径和权限可见范围，每项都要有通过标准、证据和负责人。
- 数量不符、关键字段大面积丢失、附件不可用、权限越界、关键历史断裂属于阻断项，清零后才能宣布迁移完成；遗留项登记责任人与期限后可带条件放行。
- 验收清单建议在ONES中建为工作项，证据作为附件关联，阻断项单独标记，签字记录归档供切换后回溯。
谁在什么时点使用这份验收清单
这份清单面向迁移项目负责人、Jira管理员、ONES管理员、业务模块负责人和数据核对人。它解决的是“谁在哪个节点查什么、对结果负什么责任”，具体检查内容由后续章节展开。验收不是迁移结束后的一次性动作，而是分布在三个关口：试迁移后验证方案可行性，正式迁移后核对全量数据，切换前确认遗留项已闭环并具备放行条件。
验收启动前需要三份前置输入，缺少任何一份都会让后续比对失去基准：
- 迁移范围清单：列明纳入迁移的项目、问题类型、字段和排除项，作为数量与内容比对的依据。
- 字段映射表：记录Jira字段到ONES字段的对应关系、默认值规则和转换规则。
- 用户对照表：记录Jira账号与ONES账号的对应关系，包括离职账号、共享账号和外部协作账号的处理方式。
| 角色 | 主要职责 | 介入时点 |
|---|---|---|
| 迁移项目负责人 | 组织验收、裁定阻断项、签署验收结论 | 三个关口全程 |
| Jira管理员 | 提供原系统数据口径、导出对照数据、解释字段与流程配置 | 试迁移前至正式迁移后 |
| ONES管理员 | 确认目标端配置、执行比对、提交证据 | 试迁移后至切换前 |
| 业务模块负责人 | 确认本模块数据可用、关键历史完整、权限范围合理 | 正式迁移后、切换前 |
| 数据核对人 | 执行抽样比对、填写比对记录、登记差异 | 试迁移与正式迁移阶段 |
迁移范围与字段映射的基线核对
核对数据之前先锁定“应该迁什么”。基线一旦确认，后续所有数量差异和内容差异都以它为准，避免迁移过程中反复调整口径导致验收无法收口。基线核对由迁移项目负责人牵头，Jira管理员与ONES管理员共同确认，形成书面记录后再进入试迁移。
基线核对包含三类内容：
- 纳入与排除清单：逐项列出项目、问题类型、状态、优先级、自定义字段，标明纳入或排除。废弃项目、测试项目、已归档项目要单独说明处理方式。
- 字段映射表：每个Jira字段对应到ONES的哪个字段，类型是否变化，枚举值如何对应，无值或无法映射时填什么默认值。状态与工作流的映射要单独成表，因为状态名称相同不代表流转规则一致。
- 不迁移项记录：部分历史附件、插件产生的扩展数据、已废弃字段等不迁移内容，要写明原因、影响范围和业务方确认人。
基线确认表的通过标准是：每个纳入项都有明确的目标位置，每个排除项都有书面理由和确认人，字段映射覆盖范围清单中的全部字段且无“待定”项。基线确认后如需变更，走变更记录并同步通知数据核对人，否则正式迁移阶段的数量比对会失去参照。
分阶段检查项：从试迁移到正式切换
以下检查项按阶段排列，每项都对应一个可判断的结果。试迁移阶段以样本项目为主，目的是暴露映射和转换问题；正式迁移阶段覆盖全量数据；关系与权限阶段确认数据之间的关联和可见范围；切换前阶段收口遗留项。
试迁移阶段
- 选取覆盖主要问题类型和自定义字段的样本项目，执行全量比对，不只抽查。
- 检查字段空值：Jira中有值而ONES为空、Jira为空而ONES出现默认值的情况都要记录。
- 检查字段截断：长文本、多选值、富文本正文是否完整保留。
- 抽查附件可下载性：随机选取附件打开，确认文件名、大小和内容可读。
- 核对评论条数与作者归属，确认评论时间顺序与原文一致。
正式迁移阶段
- 比对问题总数与各项目问题数，以范围清单为基准逐项目核对。
- 核对评论条数、评论作者和评论所在问题，确认无错位。
- 核对状态与历史流转记录：当前状态是否正确，状态变更时间线是否保留关键节点。
- 核对用户与用户组：账号是否建立、所属组是否正确、离职账号的历史数据归属是否合理。
关系与报表阶段
- 核对问题链接、子任务与父任务、史诗与故事的关联关系是否完整。
- 核对看板与筛选器的口径：原Jira中按状态、经办人、版本筛选的结果，在ONES中是否得到一致集合。
- 核对依赖报表或统计的模块，确认统计口径变化已告知业务方。
权限阶段
- 核对项目角色与用户组的对应关系，确认成员在ONES中的角色与原Jira一致。
- 核对可见范围：原Jira中受限项目或受限问题类型，在ONES中是否仍只对相同人群可见。
- 用不同角色的测试账号实际登录验证，确认无越界可见。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|---|
| 试迁移 | 样本项目全量比对 | 字段值、正文、评论逐项一致，差异已逐条说明 | 比对对照表 | 数据核对人 |
| 试迁移 | 附件可下载性抽查 | 抽查附件均可打开，文件名与大小一致 | 抽查记录与截图 | 数据核对人 |
| 正式迁移 | 问题总数与分项目数 | 与范围清单完全一致，差异为0或已逐条说明 | 数量对照表 | ONES管理员 |
| 正式迁移 | 评论条数与作者归属 | 条数一致，作者与所属问题无错位 | 导出对照表 | 数据核对人 |
| 正式迁移 | 状态与历史流转 | 当前状态正确，关键节点时间线完整 | 状态时间线截图 | 业务模块负责人 |
| 关系与报表 | 链接、子任务、史诗关联 | 关联关系完整，无孤立或错挂 | 关联清单比对 | 数据核对人 |
| 关系与报表 | 看板与筛选器口径 | 同条件筛选结果集合一致，差异已说明 | 筛选结果对照 | 业务模块负责人 |
| 权限 | 角色、用户组、可见范围 | 角色对应正确，受限内容无越界可见 | 测试账号验证记录 | ONES管理员 |
每项检查的通过标准与证据要求
检查项只有配上可判断的标准才有验收意义。“基本一致”“大致完整”这类描述无法作为放行依据，每项检查都要回答三个问题：比什么、比到什么程度算通过、留下什么证据。
数量类检查以范围清单为基准，要求总数与分项目数完全一致。出现差异时，差异为0才直接通过；存在差异的，必须逐条说明原因并确认属于预期排除项，未说明的差异不计入通过。
内容类检查采用抽样比对。抽样比例和抽样规则在验收前书面确定，例如按项目抽取一定比例的问题，覆盖每种问题类型和关键自定义字段。抽样发现的问题按同一规则扩大抽样，确认是个例还是系统性问题。字段值、正文、评论要求逐字一致，格式差异单独记录。
附件类检查核对文件名、大小和可打开性。抽查覆盖不同大小和不同类型的附件，大附件和图片类附件单独抽样。
历史类检查核对状态变更时间线与原系统一致，重点确认关键节点：创建、首次流转、关闭、重新打开。中间状态的合并或省略要在基线中事先约定，未约定的缺失视为不通过。
| 检查类别 | 通过标准 | 证据形式 |
|---|---|---|
| 数量类 | 总数与分项目数完全一致，差异为0或已逐条说明 | 导出对照表、差异说明单 |
| 内容类 | 按约定抽样比例比对，字段值、正文、评论逐字一致 | 抽样记录、比对截图 |
| 附件类 | 文件名、大小一致，抽查附件可正常打开 | 抽查清单与打开截图 |
| 历史类 | 状态时间线与原系统一致，关键节点无缺失 | 时间线截图、节点对照表 |
| 权限类 | 角色对应正确，受限内容无越界可见 | 测试账号验证记录 |
证据统一归档到对应检查项下，由数据核对人提交、模块负责人复核。验收单签字前，证据缺失的检查项按未通过处理。
阻断项与完成条件
验收中的问题分两类处理：阻断项必须清零，遗留项可以登记后带条件放行。两类问题混在一起管理，容易出现“大部分没问题”的模糊结论，导致切换后才发现关键数据不可用。
阻断项包括：问题数量与范围清单不符且无说明；关键字段大面积丢失或错位；附件不可用或无法打开；权限越界导致受限内容对无关人员可见；关键历史流转断裂，无法还原问题处理过程。阻断项在关闭前保持未完成状态，由迁移项目负责人裁定，不允许以“后续补”为由放行。
遗留项包括：低优先级字段的格式差异、非关键附件缺失、报表展示样式差异等不影响业务连续的问题。每项遗留项登记问题描述、影响范围、责任人和修复期限，由业务模块负责人确认可接受。
宣布迁移验收完成需要同时满足三个条件：阻断项全部清零并有复核记录；遗留项全部登记，责任人和期限明确；验收单由迁移项目负责人、Jira管理员、ONES管理员和业务模块负责人签字确认。签字记录与验收证据一并归档，供切换后回溯。
用ONES承载验收过程与结果留痕
验收清单如果只停留在表格里，执行进度和证据分散在个人手中，切换后很难回溯。把清单落到ONES中执行，可以让检查项、证据、阻断标记和签字记录形成一条可追溯的记录链。ONES的Jira迁移方案本身覆盖项目、工作项、状态、字段、流程、附件和历史记录的迁移，用户、用户组、问题类型、工作流、字段配置和权限配置也在迁移范围内，验收时可以直接在目标系统中核对对应内容。
具体落地方式如下：
- 检查项建为工作项：每个检查项作为一个工作项，按试迁移、正式迁移、切换前设置状态，负责人字段填写对应角色，时点作为计划日期。
- 证据关联到检查项：比对截图、导出对照表、抽样记录作为附件上传，或关联到对应文档，保证证据与检查项一一对应。
- 阻断项单独标记：阻断项使用独立标签或字段标记，关闭前保持未完成状态，在验收看板中单独呈现，避免被普通检查项淹没。
- 结论归档：验收结论、签字确认单和遗留项登记表归档到项目文档中，切换后如出现数据疑问，可按检查项回溯当时的比对证据和确认人。
这样执行的好处是验收进度对所有人可见，阻断项不会被遗漏，遗留项的修复期限有跟踪载体。对于依赖Jira插件的定制场景，迁移前需要逐项评估，评估结论也应作为检查项记录在案，作为切换前确认功能匹配的依据。
常见问题
试迁移阶段已经全量比对过样本项目，正式迁移后还需要再抽样吗？
需要。试迁移的样本项目用于暴露字段映射和转换规则的问题，正式迁移覆盖的是全量数据，两者核对对象不同。正式迁移后仍要按事先约定的抽样比例和规则做内容比对，重点覆盖试迁移中未纳入的项目、问题类型和自定义字段。试迁移阶段发现并修复的问题，也应在正式迁移后复查同类数据，确认修复规则在全量范围内生效。
迁移后发现少量问题数量差异，但业务方认为不影响使用，可以直接放行吗？
要看差异性质。数量类检查的通过标准是总数与分项目数完全一致，差异为0或已逐条说明。如果差异能对应到范围清单中的预期排除项，并有书面记录，可以按通过处理；无法说明来源的差异属于阻断项，需要先定位原因再判断。业务方确认“不影响使用”不能替代差异说明，否则切换后出现数据缺失时无法回溯责任边界。
Jira中的插件扩展数据和定制字段，验收时怎么处理？
迁移前需要逐项评估依赖插件的定制场景，评估结论作为检查项记录在案，作为切换前确认功能匹配的依据。验收时按基线中的不迁移项记录核对：每项不迁移内容写明原因、影响范围和业务方确认人。插件产生的数据如果影响业务流程，应在切换前确认替代方式或手工补录方案，并登记为遗留项跟踪到闭环。
权限验收用管理员账号检查配置够不够？
不够。配置层面的角色和用户组对应关系只能说明设置意图，实际可见范围要用不同角色的测试账号登录验证。重点检查原Jira中受限的项目或问题类型，在ONES中是否仍只对相同人群可见，以及离职账号、共享账号和外部协作账号的历史数据归属是否合理。测试账号验证记录作为权限类检查的证据归档。
验收单签字后，切换上线时又发现数据问题怎么办？
签字确认的是验收时点按清单核对的结果，签字记录和比对证据应一并归档，便于切换后按检查项回溯当时的核对范围和确认人。切换上线阶段新发现的问题，按问题性质重新判断：属于阻断项的，暂停相关模块使用并组织修复；属于遗留项的，登记责任人和期限后跟踪。验收归档的价值正在于能快速定位问题出在迁移环节还是切换后的使用环节。
