迁移验证的依据要能回答三件事：迁移范围是否完整、字段与附件是否对得上、业务能否在目标环境正常运转。可用的依据包括迁移前的对象盘点与数量基线、字段映射对照表、试迁移的抽样比对记录、附件与关联关系的校验结果、关键业务场景的验收记录、并行运行期间的差异清单，以及切换窗口与回退点的书面确认。这些依据应在迁移前确定口径，在试迁移和正式切换中逐项留痕。ONES 的迁移方案覆盖 Jira 项目、工作项、状态、字段、流程、附件和历史记录，以及 Confluence 空间、页面、附件和权限结构，验证记录与验收结论可以在 ONES 中随迁移批次一并留存。
要点总览（TL;DR）
- 迁移验证的依据分为四类：范围与数量基线、试迁移比对记录、业务验收与并行差异清单、切换与回退决策记录，四类证据共同回答范围是否完整、字段附件是否对得上、业务能否正常运转。
- 数量基线应在迁移前从源系统导出并冻结，作为完整性比对的唯一参照；迁移后重新统计会因源端变化或口径不同产生偏差。
- 试迁移比对覆盖总量、关键字段抽样、附件可打开性与关联关系四个层面，每条差异登记处理人和关闭标准，关闭后再进入下一轮。
- 业务验收由实际使用者走查主流程，并行期间的差异需归因到映射规则、工具问题或源数据质量，并由业务确认人认可关闭。
- 切换前逐项核对验证通过条件，回退触发条件建议量化；验证证据按迁移批次归档，命名体现批次、对象类型和验证日期，便于后续批次复用。
先定验证范围：源系统、目标系统与对象清单
验证工作的第一步是把迁移方向和边界写清楚。源系统与目标系统各自的名称、版本、部署形态，以及本次属于第几个迁移批次，都应记录在案。方向一旦确定，后续所有数量比对和抽样都以此为准，避免中途出现“从目标端反查源端”的口径混乱。
纳入验证的对象类型需要逐项列出。研发数据迁移通常涉及工作项、需求、缺陷、测试用例、文档、附件、评论和关联关系；从 Confluence 迁移知识库时，还包括空间、页面、页面树层级和权限结构。对象类型列得越具体，后续数量基线越容易对齐。
数量基线应在迁移前从源系统导出并冻结，作为完整性比对的唯一参照。迁移后重新统计会因源端仍在变化或统计口径不同而产生偏差，因此基线导出时间、导出人和导出条件都要记录。范围表可按以下结构填写：
| 对象类型 | 源端数量 | 目标端预期数量 | 负责人 | 备注 |
|---|---|---|---|---|
| 工作项（按项目分列） | 导出值 | 与源端一致 | 数据负责人 | 注明导出时间 |
| 附件 | 导出值 | 与源端一致 | 数据负责人 | 含文件名与大小清单 |
| 评论 | 导出值 | 与源端一致 | 数据负责人 | 含作者与时间 |
| 关联关系 | 导出值 | 与源端一致 | 业务负责人 | 父子、关联、用例链接 |
| 文档页面 | 导出值 | 与源端一致 | 知识库负责人 | 含层级与权限 |
同时要明确不在本次验证范围内的内容，例如历史归档项目、已关闭且不再流转的项目、外部集成产生的临时数据。把这些内容写进范围表，可以避免验收阶段因“这部分为什么没迁”反复解释，也防止验证工作量无边界扩张。
验证前要准备哪些输入与依赖
验证能否顺利开展，取决于几类输入是否提前到位。字段映射对照表是核心输入，它规定了源端字段与目标端字段的对应关系以及取值转换规则，例如状态名称如何对应、优先级枚举如何转换、人员账号如何匹配。本文引用映射设计的成果，不在此重做映射；验证阶段的任务是按映射表逐项确认实际迁移结果是否符合约定。
试迁移环境或影子环境的可用性是另一项前置条件。验证需要在与正式目标环境配置一致的环境中进行，否则比对结果无法代表正式切换后的状态。环境就绪时间应纳入迁移计划，避免验证被环境问题阻塞。
抽样规则需要提前确定，常见做法是按项目、时间范围、状态和业务重要性组合抽取样本。高风险项目、近期活跃项目、状态流转复杂的工作项应提高抽样比例；长期未变动的数据可降低比例。样本清单在抽样时固定，验证过程中不随意替换，保证结果可复核。
参与验收的业务角色与确认人也要在验证开始前明确。数据比对通常由迁移实施人员完成，业务可用性判断则需要需求、测试、项目管理等角色的实际使用者参与。迁移日志、错误报告与重跑机制的可用性同样属于依赖项：出现失败记录时，需要能定位原因、修正后重跑，并保留重跑前后的记录对照。
建议把上述内容整理成验证输入清单与责任人对照表，逐项标注“已就绪”“待确认”“缺失”，在试迁移启动前完成一次检查。
试迁移阶段怎么比对：完整性、字段与附件
试迁移是正式切换前最关键的验证环节，比对工作可分为总量、抽样、附件、关联关系四个层面，每个层面都要有明确的判定口径和差异登记方式。
总量比对看各对象类型在源端与目标端的数量是否一致。数量不一致时，差异不能只记一个数字，而要登记差异对象类型、差异数量、可能原因和处理状态。常见原因包括源端在迁移窗口内仍有新增数据、部分对象因权限或状态被过滤、迁移任务中断后未完整重跑。
抽样比对是逐条核对关键字段，包括标题、状态、负责人、优先级、创建与更新时间、自定义字段取值。核对时以字段映射对照表为准，同名不同义的字段尤其要逐项确认，例如源端的“处理人”与目标端的“经办人”是否按映射规则正确转换，状态名称相近但流转含义不同的情况是否按约定处理。
附件与富文本的校验不能只看数量。应抽查文件能否正常打开、文件名与大小是否与源端一致，富文本中的图片是否正常显示、表格与代码块格式是否保留。附件数量一致但部分文件损坏或链接失效，同样属于未通过项。
关联关系的校验关注链接是否保留，包括父子工作项、需求与测试用例、缺陷与版本、页面之间的引用。关联关系断裂往往不会在数量统计中暴露，需要通过抽样打开具体对象查看关联页签来确认。
| 检查项 | 样本 | 结果 | 差异说明 | 处理状态 |
|---|---|---|---|---|
| 工作项总量 | 全量统计 | 一致/不一致 | 差异数量与原因 | 待处理/已关闭 |
| 关键字段抽样 | 按规则抽取 | 通过/不通过 | 字段名与期望值 | 待处理/已关闭 |
| 附件可打开性 | 抽查文件 | 通过/不通过 | 文件名与问题描述 | 待处理/已关闭 |
| 关联关系 | 抽查对象 | 通过/不通过 | 断链类型 | 待处理/已关闭 |
试迁移比对记录表应覆盖上述检查项，每条差异都指定处理人和关闭标准。差异关闭后再进入下一轮验证，避免遗留项带入正式切换。
业务验收与并行运行：怎么判断可以切换
数据比对通过只说明“数据搬过去了”，业务验收要回答“团队能不能在目标系统正常干活”。关键业务场景走查是主要手段：新建工作项、状态流转、评审审批、缺陷关闭、测试用例执行与关联、文档编辑与发布等主流程，都应由实际业务角色在目标环境中完整走一遍，并记录每一步是否可完成、是否存在操作障碍。
并行运行适用于对连续性要求较高的迁移。源系统与目标系统在一段时间内同时可用，团队在新系统中开展新工作，同时按固定频率比对两边数据。并行窗口的长度取决于业务节奏和风险容忍度，比对频率可以按日或按周设定，关键是频率和比对范围提前约定，不临时调整。
并行期间发现的差异要进入统一清单，逐条归因：属于映射规则问题的，回到映射表修正；属于迁移工具问题的，提交处理并重跑；属于源数据本身质量问题的，由业务方确认处理方式。差异关闭需要业务确认人认可，不能由实施方单方面标记完成。
业务确认人的签字或书面确认形式应在验收前约定，可以是验收单签认、邮件确认或在协作工具中留下审批记录。未通过项的放行规则同样要提前写明：影响主流程的未通过项构成阻断，必须修复后重新验收；不影响主流程的遗留项可带条件放行，但需登记责任人和计划关闭时间。
切换窗口与回退条件：验证依据如何支撑决策
切换决策建立在前面各阶段积累的证据之上。切换窗口的时间安排需要与业务低峰期对齐，并约定冻结期：在冻结期内源系统停止新增和修改数据，确保迁移数据与验证数据一致。冻结期的起止时间、通知范围和例外审批方式都应书面确认。
切换前必须满足的验证通过条件应逐项列出，通常包括：各对象类型数量与基线一致或差异已登记并接受；抽样比对通过率达到约定标准；附件与关联关系抽查无阻断性问题；关键业务场景走查全部通过；并行差异清单中的阻断项已关闭。这些条件与验证记录一一对应，决策时可直接引用。
回退触发条件建议量化，便于在压力下快速判断：关键数据缺失比例超过约定阈值、核心主流程在目标系统不可用、并行差异超出约定范围且无法在窗口内修复。回退点、回退操作的责任人和数据恢复方式要在切换前明确，包括源系统在冻结期内的数据如何处理、回退后如何通知相关团队。
| 决策项 | 通过标准 | 当前状态 | 遗留项 | 签认人 |
|---|---|---|---|---|
| 数据完整性 | 数量一致或差异已接受 | 待填 | 待填 | 数据负责人 |
| 业务可用性 | 主流程走查通过 | 待填 | 待填 | 业务确认人 |
| 回退预案 | 触发条件与责任人明确 | 待填 | 待填 | 迁移负责人 |
切换后短期观察同样属于验证的一部分。观察项可包括登录与权限是否正常、关键报表数据是否准确、附件下载是否稳定、通知与自动化规则是否按预期触发。复查时点建议设在切换后第一周和第一个月末，分别检查即时问题和累积问题。
在 ONES 中，迁移范围表、比对记录、差异清单和验收结论可以作为工作项与文档随批次留存，切换决策检查表的签认记录也能在同一处追溯。ONES 迁移方案围绕 Jira 的项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并将 Confluence 空间、页面、附件和权限结构迁入 ONES Wiki，验证阶段可按这些对象类型组织核对项；对于依赖原插件或已有定制的场景，迁移前仍需逐项评估功能匹配情况。
验证证据怎么留档与复用
验证证据按类别组织，便于复查时快速定位：数量基线属于范围类证据，比对记录和差异清单属于过程类证据，业务验收记录和签认文件属于结论类证据。每类证据都应与迁移批次绑定，注明批次编号、对象类型和验证日期。
存放位置和命名规则要统一。命名可采用“批次号-对象类型-证据类型-日期”的结构，例如批次号加工作项加比对记录加日期。存放位置应选择团队可访问且有权限控制的协作空间，避免证据散落在个人目录中。
后续迁移批次可以复用已有验证清单，但需要根据本批次的对象范围和映射变化更新检查项。复用不等于照搬：新增对象类型要补充对应检查项，映射规则调整的部分要重新抽样，上一批次的高频差异应作为本批次的重点核对项。每次复用后更新清单版本，保留历史版本以便对照。
证据归档完成后，建议形成一份验证证据归档目录与复用说明，列明每类证据的位置、责任人和适用批次，作为下一次迁移启动时的直接输入。
常见问题
源系统在迁移窗口内仍有新增数据，数量基线怎么处理？
数量基线应在迁移前导出并冻结，同时记录导出时间、导出人和导出条件。如果源系统在迁移窗口内仍有新增或修改，需要先约定冻结期：冻结期内源系统停止新增和修改，确保迁移数据与基线口径一致。冻结期无法完全停写时，可把窗口内新增数据单独登记为增量批次，在比对时与基线分开统计，避免把增量差异误判为迁移丢失。
附件数量一致但部分文件打不开，算验证通过吗？
不算。附件校验除数量外，还应抽查文件能否正常打开、文件名与大小是否与源端一致，富文本中的图片是否正常显示、表格与代码块格式是否保留。数量一致但存在损坏文件或失效链接，属于未通过项，应登记到比对记录表并指定处理人，修复后重新抽查确认关闭。
并行运行要持续多久，比对频率怎么定？
并行窗口长度取决于业务节奏和风险容忍度，没有统一标准。比对频率可以按日或按周设定，关键是频率和比对范围提前书面约定，执行中不临时调整。对连续性要求高的迁移，可适当延长并行窗口并提高比对频率；差异清单中的阻断项全部关闭、主流程走查稳定后，再进入切换决策。
哪些未通过项可以带条件放行，哪些必须阻断切换？
放行规则应在验收前写明。影响主流程的未通过项构成阻断，例如关键数据缺失、核心流程在目标系统无法完成，必须修复后重新验收。不影响主流程的遗留项可带条件放行，但需登记责任人、计划关闭时间和业务确认人的认可记录。阻断与放行的判定由业务确认人和迁移负责人共同签认，避免实施方单方面决定。
上一批次的验证清单能直接用于下一批次吗？
可以复用，但需要按本批次情况更新。新增对象类型要补充对应检查项，映射规则调整的部分要重新抽样，上一批次的高频差异应作为本批次重点核对项。每次复用后更新清单版本并保留历史版本，便于对照不同批次的验证口径变化。
