研发数据迁移的风险往往在正式执行前就已埋下：源数据里的空值、重复、格式错乱和关联断链，会在映射和导入阶段集中暴露。本文把识别工作放在迁移启动之前，用抽样画像和规则校验逐项核验，范围限定在数据内容本身，不展开流程与插件行为迁移、切换后的结果核验。
要点总览（TL;DR）
- 把“数据质量差”拆成按对象和症状两维的可核验条目：工作项、需求、缺陷、用例、附件、评论、用户与组织，对应字段缺失、重复冲突、格式枚举不一致、关联断链、增量不可追踪五类症状。
- 每类症状先列原因假设，再用空值率、取值分布、唯一键冲突数、引用完整性检查、变更日志与时间戳等证据确认或排除，证据不足时标注待验证，不写成结论。
- 排查顺序先做全量轻量扫描得到整体画像，再对活跃项目、历史归档项目、跨项目关联和附件体量大的对象分层抽样，按影响数量、是否阻断映射、可否自动修复、修复成本四个维度定级。
- 清洗和映射调整后用同口径指标对比、抽样人工复核和关联完整性复查确认恢复；增量阶段监控新增空值、冲突数、断链数和变更未捕获数，把校验规则固化为迁移前检查清单和定期巡检。
- 批量改写、删除重复等不可逆操作前先备份或导出快照并设定停止点，遗留风险在风险登记表中记录接受条件、接受人和时间。
迁移前要盯住哪些源数据质量症状
“数据质量差”这个判断无法直接指导行动，需要拆成按对象和症状两个维度可观察的条目。先圈定迁移范围，列出关键对象清单，再对每类对象逐项检查症状，才能把模糊的担忧变成可核验的问题。
迁移范围通常包含以下对象：工作项（任务、子任务）、需求、缺陷、用例、附件、评论、用户与组织。每类对象承载的信息不同，风险表现也不同。例如工作项的风险集中在字段和关联，附件的风险集中在文件路径和体量，用户与组织的风险集中在账号映射和归属关系。
症状可以归为五类，它们对应不同的检查手段：
| 症状类别 | 可观察表现 | 典型涉及对象 |
|---|---|---|
| 字段缺失 | 必填字段为空、关键属性大面积未填、历史记录字段缺失 | 工作项、需求、缺陷、用例 |
| 重复与冲突 | 同一业务对象存在多条记录、同一唯一键对应不同内容 | 工作项、用户与组织 |
| 格式与枚举不一致 | 状态值写法不统一、优先级取值超出预期集合、日期格式混杂、富文本与附件路径异常 | 工作项、评论、附件 |
| 关联断链 | 父子关系、关联关系指向已删除对象或跨项目不可解析对象 | 工作项、需求、用例 |
| 增量变更不可追踪 | 缺少更新时间字段、软删除不留痕、并发修改无记录 | 全部对象 |
需要区分三类问题：数据内容问题（本文讨论范围）、流程与插件配置问题（如工作流状态机、字段联动规则在目标系统能否对应）、切换后验证问题（迁移完成后数据是否完整可用）。后两类同样重要，但排查方法和责任角色不同，混在一起会让诊断失焦。把边界写清楚，后续的证据收集才有明确对象。
每类症状的原因假设与排除证据
看到症状后，第一反应往往是给出原因，但原因在验证之前只是假设。可行的做法是为每类症状列出可能原因，再指定一种证据去确认或排除，证据不足时保持“待验证”状态，不写进结论。
字段缺失
可能原因包括：历史录入时该字段尚未设为必填、必填要求是后期才加的、早期通过批量导入留下的空值。验证方式是统计目标字段的空值率，并按项目、创建时间段、创建人做分布抽样。如果空值集中在某个时间段之前的记录，说明是必填项后置导致；如果分散在各时期，更可能是录入习惯问题。空值率本身是事实，成因仍需分布对比才能判断。
重复与冲突
可能原因包括：多套系统合并后同一对象被重复创建、手工建单未查重、同步回写造成副本。验证方式是选定业务唯一键（如需求编号、缺陷标题加项目）统计冲突数量，再对疑似重复记录做相似度比对，确认是真正重复还是恰好同名。冲突记录要区分“内容一致可合并”和“内容不同需人工裁决”两类，后者不能自动处理。
格式与枚举不一致
可能原因包括：不同时期状态值命名规则变化、多团队自定义优先级、日期字段混用不同格式、富文本中嵌入外部图片或附件引用路径。验证方式是对每个待映射字段做取值分布统计，列出全部实际取值并与目标系统的枚举集合比对，找出无法直接映射的值。附件路径要单独检查是否存在指向外部存储或已失效位置的引用。
关联断链
可能原因包括：父对象或关联对象已被删除但引用未清理、跨项目关联在权限或范围上不可解析、关联字段指向的对象类型在目标系统中不存在。验证方式是做引用完整性检查：遍历每条关联记录，确认被引用对象在源系统中存在且可访问，统计断链数量和分布。跨项目关联要单独统计，因为它们在映射时往往需要额外规则。
增量变更不可追踪
可能原因包括：源系统部分对象缺少更新时间字段、删除操作采用软删除但未保留可识别标记、并发修改时后写覆盖先写且无历史记录。验证方式是检查关键对象是否具备可用的时间戳字段，抽样比对变更日志与对象当前状态是否一致，确认软删除记录能否被识别。如果时间戳缺失，增量同步阶段就无法判断哪些记录发生了变化，这一项要在迁移方案中提前标注。
每条假设都应记录为“假设—证据—结论”三段，证据不足时结论栏写“待验证”，并注明还需要什么数据。这样做的价值在于：后续排查有明确目标，评审时也能区分哪些是已确认事实、哪些仍是推测。
按什么顺序做抽样核验与风险定级
时间和人力有限时，排查顺序决定了能否先暴露高影响风险。建议分两步：先做全量轻量扫描，再对高风险对象做分层抽样。
全量轻量扫描的成本低、覆盖全，适合先跑一遍。扫描项包括各对象记录数、关键字段空值率、唯一键冲突数、关联引用总数。这一步不追求精确到每条记录，目的是得到整体画像，找出异常集中的对象和字段。
分层抽样针对扫描暴露的高风险对象展开，抽样层应覆盖：活跃项目（当前在用的数据，映射要求最高）、历史归档项目（数据量大、录入规范可能较差）、跨项目关联（映射规则复杂）、附件体量大的对象（传输和路径风险高）。每层抽取的样本量以能判断分布为准，样本要包含边界情况，例如最早创建和最近修改的记录。
风险定级建议从四个维度判断，可以合并为一个简单评分：
| 维度 | 判断问题 | 高风险的信号 |
|---|---|---|
| 影响对象数量 | 该问题涉及多少条记录、多少个项目 | 涉及多个活跃项目或大量核心工作项 |
| 是否阻断映射 | 该问题是否导致字段或对象无法映射到目标系统 | 关键字段无对应枚举、关联对象不存在 |
| 是否可自动修复 | 能否用规则批量处理 | 只能人工逐条裁决 |
| 修复成本 | 修复需要多少人力、时间和协调 | 需要业务方确认、跨团队协调 |
对批量改写、删除重复记录这类不可逆操作，执行前先备份或导出快照，并设定停止点：例如清洗脚本处理到一定比例时暂停，抽样复核结果符合预期再继续。停止点的作用是防止规则误伤在批量执行中被放大。
排查结果汇总为风险登记表，字段包括：症状、证据（指标或样本）、影响范围、风险等级、处置建议（清洗、调整映射、暂缓迁移）、责任人、状态。登记表是后续处置和验证的依据，也是迁移评审的输入材料。
在抽样核验和风险登记环节，ONES 对工作项、字段状态和关联关系的管理方式可以承接部分组织工作：迁移范围中的工作项、需求、缺陷等对象及其字段和关联，可以在 ONES 中按项目建立对应的核验清单和问题记录，把每条待验证假设登记为可跟踪的工作项，关联到具体项目和责任人，状态随核验进展更新。ONES 公开的 Jira 迁移方案说明其迁移范围覆盖项目、工作项、状态、字段、附件和历史记录，并建议在正式迁移前确认数据范围、功能匹配和系统适配，这与先核验再迁移的顺序一致。源数据质量画像和引用完整性检查的具体工具能力，需以实际方案评估为准。
处置后的验证与复发预防
清洗和映射调整完成后，需要确认问题确实消除，而不是被掩盖。验证的核心是用同一口径对比处置前后的指标。
验证方式包括三类：
- 清洗前后同口径指标对比：空值率、唯一键冲突数、断链数在处置前后用相同规则统计，指标下降且剩余项有明确解释才算通过。
- 抽样人工复核：从处置过的记录中分层抽取样本，由业务方确认内容正确，重点检查自动合并和批量改写的记录。
- 关联完整性复查：重新执行引用完整性检查，确认断链已修复或已登记为遗留风险。
增量同步阶段要设置监控项，把风险识别从一次性动作变成持续机制。建议监控：新增记录的空值数、冲突数、断链数、变更未捕获数（即发生了修改但增量机制未识别到的记录数）。这些指标按批次或按周期统计，出现异常上升时触发排查。
复发预防的关键是把校验规则固化下来：将本次使用的检查项整理为迁移前检查清单，纳入后续每次迁移或数据导入的准备工作；对长期运行的系统，把空值率、冲突数、断链数纳入定期数据巡检，形成基线，偏离基线时及时处理。
遗留风险需要明确接受条件并记录：哪些问题本次不处理、原因是什么、影响范围多大、由谁确认接受。记录方式可以沿用风险登记表，状态标记为“已接受”，并注明接受人和接受时间。这样在迁移评审和后续巡检中，遗留风险有据可查，不会被误认为已解决。
常见问题
源系统里字段空值率很高，是否一定要在迁移前全部补齐？
不一定。先判断空值集中在哪些字段和哪些记录：如果空值集中在必填项设置之前的历史记录，且这些字段在目标系统中并非关键映射字段，可以在风险登记表中登记为遗留风险，明确接受条件和接受人后继续迁移。如果空值出现在目标系统的必填字段或关键业务属性上，就需要在迁移前补齐或制定默认值规则。判断依据是空值率、分布特征以及该字段是否阻断映射，而不是空值率本身的高低。
跨项目关联和附件引用这类断链，抽样检查能覆盖到吗？
抽样可以发现断链的存在和大致分布，但要确认全貌，建议对关联引用做一次全量引用完整性检查，统计断链数量和涉及的项目范围。抽样更适合判断断链集中在哪些对象类型和项目层。附件引用要单独检查是否存在指向外部存储或已失效位置的路径，这类问题在抽样中容易被漏掉，因为附件体量大的对象往往只占少数。两类检查结合，才能支撑后续的映射调整或清洗决策。
增量同步阶段发现变更未捕获数上升，应该先停同步还是先排查？
先判断影响范围再决定。变更未捕获数上升意味着部分修改没有进入同步流程，继续同步可能造成目标系统数据与源系统不一致。可行的做法是暂停该批次同步，核对源系统中缺少可用时间戳或变更记录的对象范围，确认是时间戳字段缺失、软删除未留痕还是并发修改覆盖导致。排查清楚后补充变更捕获规则，再重新执行同步，并对暂停期间的变化做一次补偿比对。是否暂停取决于业务对数据一致性的要求，但暂停前应记录当前同步位点，避免恢复时重复或遗漏。
风险登记表应该由谁维护，迁移完成后还需要保留吗？
风险登记表建议由迁移项目的负责人或数据负责人维护，每条风险指定处置责任人。迁移完成后应保留，原因有两点：一是遗留风险的接受记录需要在后续巡检和评审中可查；二是登记表中的检查项和指标口径可以转化为迁移前检查清单，供下一次迁移或数据导入复用。保留形式可以沿用原表并标记状态，也可以整理为团队的数据质量基线文档，关键是让接受条件和责任人持续可见。
ONES 在迁移前评估方面有哪些公开说明可以参考？
ONES 公开的 Jira 迁移方案说明其迁移范围覆盖项目、工作项、状态、字段、附件和历史记录，并建议在正式迁移前确认数据范围、功能匹配和系统适配，把迁移工具、原厂服务和分阶段切换结合起来以降低数据丢失或业务中断风险。对于企业已有的定制场景，ONES 也提示迁移前需要逐项评估，避免直接假设所有插件都能一一对应。这些表述可以作为迁移前评估的参考，源数据质量画像和引用完整性检查的具体工具能力，需结合实际方案评估确认。
