研发历史记录在迁移后出现遗漏，通常源于源数据盘点、实体与字段映射、用户身份映射、历史附件与链接保留、增量同步五个环节中的某一处口径或执行缺口。排查时先界定遗漏范围，再按链路逐项取证，最后用数量核对与抽样比对确认恢复。本文按症状、原因、处置、验证四步展开，并在处置环节说明ONES在迁移范围与数据核对上的衔接方式。
要点总览（TL;DR）
- 研发历史记录遗漏多发生在五个环节：源数据盘点与清理、实体与字段映射、用户身份映射、历史附件与链接保留、增量同步闭合。
- 排查按“上游未确认、下游不成立”的顺序推进：先确认源端导出范围，再查字段映射、身份映射、附件与链接，最后核对增量窗口。
- 处置前先冻结源端或留存快照；覆盖写入与删除须先备份、列明影响范围，并设定停止条件。
- 补齐后用数量核对与抽样比对双重验证，并对增量同步设置差异告警，把核对清单纳入下次迁移的准备与验收。
遗漏出现在哪里：先界定症状与范围
“历史记录遗漏”是一个笼统的说法，直接开始修数据容易把不同性质的问题混在一起。第一步是把遗漏拆成可观察的症状，确定排查边界，并建立可用于比对的基准。范围界定清楚之后，后续的原因排查才有明确的取证对象。
按记录类型分类遗漏表现
研发历史记录包含多种类型，不同类型的遗漏表现和成因差异较大，应分别登记：
- 需求、任务、缺陷等工作项本身缺失，表现为某项目下的工作项总数少于源端。
- 评论缺失，表现为工作项存在但讨论内容为空或只剩部分评论。
- 变更历史缺失，表现为状态流转、字段修改的轨迹不完整，工作项当前值正确但历史轨迹断档。
- 附件缺失，表现为记录存在但附件列表为空，或附件数量少于源端。
- 关联关系缺失，表现为工作项之间的关联、父子层级、跨记录引用断裂。
把症状按类型分开登记，可以快速看出遗漏是集中在某一类记录，还是普遍存在于所有类型。集中在一类，通常指向该类数据的映射或迁移规则；普遍存在，则更可能指向源端导出范围或增量窗口。
按时间区间、项目范围、数据来源定位分布
在类型之外，还要记录遗漏的分布特征。时间上，遗漏是集中在某个日期之前，还是散布在整个历史区间；项目上，是全部项目都有，还是集中在个别项目；数据来源上，是从某一系统或某一批导出文件迁入的记录才有遗漏。这三个维度交叉之后，往往能把原因假设缩小到一两个环节。例如遗漏集中在某时间点之前，常见于该时点之前的数据处于归档状态而未纳入导出；遗漏集中在个别项目，常见于该项目使用了特殊的字段配置或权限结构。
区分数据内容遗漏与流程、插件行为差异
排查中会遇到一类容易混淆的现象：记录都在，但状态名称、流转路径、字段选项与原来不同。这属于流程与插件行为的迁移差异，不在本文讨论的数据内容遗漏范围内，应单独记录并交由流程迁移的专项处理。区分方法很直接：核对记录条数与关键内容字段，若条数与内容一致、仅表现形式不同，归为行为差异；若条数或内容缺失，才进入本文的排查链路。
建立比对基准
没有基准就无法判断“遗漏”。排查开始前应固定两类基准：一是源端按记录类型、项目、时间区间导出的数量统计；二是从源端抽取的一份明细清单，包含记录标识、标题、创建时间、创建人、附件数量等关键字段。基准应在源端数据冻结或留存快照之后生成，避免排查期间源数据继续变化导致基准失效。后续所有比对都以这份基准为准。
五类常见原因及各自的排除证据
研发历史记录的迁移链路可以概括为：源端导出、实体与字段映射、用户身份映射、附件与链接随记录迁移、增量同步闭合。遗漏通常发生在其中某一环。下面按链路顺序列出原因假设，每条假设都给出可验证的证据和排查顺序。需要强调的是，这些是待验证的假设，只有取得对应证据后才能作为结论。
原因假设与验证证据对照
| 环节 | 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|---|
| 源数据盘点与清理 | 源端已删除或归档的数据未纳入导出；脏数据在清洗阶段被过滤且未留记录；导出条件设置过窄 | 源端导出日志与过滤规则；被过滤记录的清单；导出条件的时间、状态、项目范围设置 | 第1步 |
| 实体与字段映射 | 字段未建立映射；枚举值与选项集不匹配导致取值丢失；必填约束或格式校验导致记录被跳过 | 映射配置表；迁移日志中的跳过或失败记录；目标端字段空值分布 | 第2步 |
| 用户身份映射 | 账号未匹配导致创建人、处理人缺失或记录归属异常；用户组与权限结构未同步 | 账号匹配结果清单；目标端责任人字段的空值与异常归属统计 | 第3步 |
| 历史附件与链接 | 附件未随记录迁移；跨记录引用链接断裂；页面内嵌图片或宏内容丢失 | 附件数量比对；链接抽查结果；内嵌内容的渲染检查 | 第4步 |
| 增量同步 | 切换窗口内的新增或修改未纳入；时间戳口径不一致导致边界数据重复或漏迁 | 切换窗口的时间记录；源端与目标端在窗口期内的变更数量比对 | 第5步 |
为什么按这个顺序排查
排查顺序遵循“上游未确认，下游不成立”的原则。源端导出范围决定了后续所有环节的输入，如果源端本身就没有导出某批记录，再去检查字段映射只会浪费排查时间。字段映射和身份映射属于转换环节，二者都会导致记录被跳过或内容缺失，但字段映射影响的是记录内容，身份映射影响的是记录归属，先查字段再查身份可以避免把归属异常误判为记录缺失。附件与链接依附于记录存在，记录本身缺失时附件问题无从谈起，因此放在映射之后。增量同步是最后一道关口，只有前面环节都确认无误，窗口期内的遗漏才能被单独识别出来。
每条假设的结论状态应明确标注为“已证实”“已排除”或“待验证”。例如，若源端导出日志显示某批归档数据确实未包含在导出范围内，且遗漏记录与该批数据完全吻合，则源数据盘点环节的假设可标记为已证实；若导出范围覆盖完整，则该假设排除，继续向下游排查。
按链路处置：从源端核对到增量补齐
原因定位之后，处置应按链路顺序推进，每一步都明确输入、动作和停止点。涉及覆盖写入或删除的操作，必须先完成备份并确认影响范围，达不到条件就停止，不以“先修了再说”的方式推进。
第一步：冻结源端数据或留存快照
输入是仍在运行的源系统。动作是在处置开始前对源端做一次完整快照，或按计划冻结写入。这一步的目的是保证排查和补迁期间源数据不再变化，否则比对基准会持续漂移，补迁范围也无法确定。完成标志是快照可读、可导出，且冻结期间的写入有明确的暂存或补录安排。若源系统无法冻结，至少应记录冻结时点，并在后续比对中排除该时点之后的变更。
第二步：按记录类型抽样比对，定位缺口环节
输入是S1中建立的源端数量统计与明细清单。动作是按记录类型分别抽取样本，逐条比对目标端的存在性、关键字段和附件数量，统计缺口比例。完成标志是能明确回答“缺口集中在哪一类记录、哪一个环节”。如果缺口集中在记录本身缺失，回到源数据盘点和映射环节；如果记录存在但字段为空，聚焦字段映射；如果记录存在但责任人异常，聚焦身份映射。
第三步：补配字段与身份映射并控制重跑范围
输入是映射配置表和迁移日志中的跳过、失败记录。动作是补齐缺失的字段映射、修正枚举值与选项集的对应关系、补配未匹配的账号。重跑时应按受影响的记录范围执行，避免全量重跑引入重复数据。完成标志是重跑后目标端的跳过记录清零，字段空值分布与源端一致，责任人字段无异常归属。若重跑涉及覆盖已有记录，须先备份目标端现有数据，并明确覆盖的记录范围；覆盖后抽样核对内容，发现异常立即停止并回滚。
第四步：补迁附件与链接并校验
输入是附件数量比对结果和链接抽查清单。动作是补迁缺失附件，修复断裂的跨记录引用，检查内嵌图片与宏内容的呈现。完成标志是附件数量与源端一致、抽查链接可正常跳转、内嵌内容完整显示。补迁附件时注意同名文件的覆盖策略，避免用旧版本覆盖目标端已有内容。
第五步：补齐增量窗口并处理重复数据
输入是切换窗口的时间记录和窗口期内的变更清单。动作是将窗口期内源端的新增与修改补入目标端，对因时间戳口径不一致产生的边界重复数据做去重处理。完成标志是窗口期内的变更数量与补入数量一致，重复数据已清理且清理记录可追溯。去重涉及删除时，先导出待删除记录清单并备份，确认清单范围后再执行。
处置中的风险边界
以下情形应停止操作并重新评估：备份未完成或备份不可验证；覆盖或删除的影响范围无法准确列出；重跑后缺口比例未下降反而上升；增量补齐后发现源端在冻结期外仍有写入且未纳入计划。这些停止条件应在处置开始前与相关方确认，避免执行中临时判断。
在迁移范围与数据核对的组织上，ONES的Jira迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence迁移覆盖页面正文、附件、图片、常用宏及批注，并包含用户、用户组与权限结构的迁移。这些范围说明可以作为制定盘点清单和比对项的参照。ONES同时建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，以降低数据丢失风险。具体到字段映射规则、身份匹配失败的处理方式和增量同步机制，需在迁移前与实施方逐项确认，并以实际环境为准。
验证恢复与防止再次遗漏
补齐操作完成不等于遗漏已解决。验证需要同时回答两个问题：缺口是否真的补上了，以及同类问题下次是否还会发生。前者靠数量核对与抽样比对，后者靠把核对动作固化为迁移前后的常规机制。
数量核对与抽样比对的双重验证
数量核对按记录类型、项目、时间区间三个维度，将目标端统计与源端基准逐一对照，差异应为零或落在事先约定的容差内。抽样比对从每个维度抽取样本，逐条核对关键内容。两种方式缺一不可：数量核对能发现整体缺口，但无法识别内容错误；抽样比对能发现内容问题，但覆盖有限。抽样应优先覆盖此前出现过缺口的记录类型和时间段。
完整性检查项
- 关键字段：标题、状态、优先级、自定义字段的取值与源端一致，空值分布无异常。
- 附件：数量一致，抽查文件可下载打开，文件名与版本正确。
- 链接：工作项之间的关联、父子层级、跨记录引用可正常跳转。
- 责任人：创建人、处理人、参与人归属正确，无集中指向某一默认账号的异常。
- 历史轨迹：状态流转与字段修改记录的时间顺序完整，无断档。
增量同步的持续监控与差异告警
切换完成后的一段时间内，源端可能仍有零星写入或存在并行使用的情况。应对增量同步设置持续监控：按固定周期比对源端与目标端的记录数量与关键字段，出现差异时触发告警并记录差异明细。监控周期和告警阈值应在切换方案中事先约定，监控记录作为后续问题追溯的依据。当连续若干周期无差异后，可逐步降低监控频率。
把核对清单纳入下次迁移的常规环节
本次排查中形成的比对基准、原因假设表、处置步骤和验证清单，应整理为下次迁移的准备与验收材料。准备阶段用盘点清单确认导出范围，用映射配置表确认字段与身份覆盖；验收阶段用数量核对与抽样比对清单逐项签字确认。把“源端是否完整—映射是否覆盖—附件与链接是否随记录迁移—增量窗口是否闭合”作为固定的检查顺序写入迁移方案，可以让同类遗漏在准备阶段就被发现，而不是等到切换后才暴露。
常见问题
源端系统在排查期间还在使用，无法冻结，怎么保证比对结果可信？
无法冻结时，至少记录一个明确的冻结时点，并以该时点生成源端数量统计和明细清单作为基准。后续比对中，把该时点之后源端产生的变更单独列出，不纳入缺口统计，避免把正常新增误判为遗漏。同时与业务方约定排查期间的写入暂存或补录安排，待处置完成后再按增量方式补入目标端。
记录条数对得上，但评论和变更历史少了，属于哪一环的问题？
条数一致而评论、变更历史缺失，说明工作项主体已迁入，缺口集中在依附于记录的明细数据上。排查重点放在两处：一是迁移范围是否包含评论与历史轨迹这类子数据，二是映射与转换阶段是否因格式或字段不匹配跳过了部分明细。可抽取若干工作项，逐条比对源端与目标端的评论数量和历史轨迹时间顺序，据此判断缺口是整体未迁还是部分丢失。
补迁时重跑会不会产生重复记录？如何控制范围？
全量重跑容易引入重复数据，应按受影响的记录范围执行。先用迁移日志中的跳过、失败记录确定重跑清单，再按记录标识做存在性判断，已存在的记录走更新而非新建。若重跑涉及覆盖目标端已有内容，须先备份并明确覆盖范围，覆盖后抽样核对，发现异常立即停止并回滚。
切换后一段时间才发现遗漏，增量窗口已经过去，还能补吗？
可以补，但要先确认源端在切换后是否仍有写入、这些写入是否已被其他方式带入目标端。做法是以切换时点为界，导出源端该时点之后的变更清单，与目标端逐条比对，形成待补清单后按增量方式补入。补入前备份目标端相关记录，补入后核对数量与关键字段，并把这次补入记录归档，作为后续差异追溯的依据。
ONES 的迁移方案覆盖哪些数据范围，能作为盘点清单的参照吗？
据 ONES 官方资料，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并包含用户、用户组与系统配置的迁移；Confluence 迁移覆盖页面正文、附件、图片、常用宏及批注，以及用户、用户组、空间权限与页面权限。这些范围可以作为制定盘点清单和比对项的参照。字段映射规则、身份匹配失败的处理方式、增量同步机制等细节，需在迁移前与实施方逐项确认，并以实际环境为准。
