Jira迁移完成后发现数据对不上，先别急着重跑迁移。多数差异来自统计口径不一致、字段映射与默认值处理、附件和关联对象未随主记录迁移，以及状态与历史记录的转换规则不同，真正丢失数据的比例相对较小。排查主线是：先界定差异类型并统一比对口径，再按原因假设逐项验证，从低成本核对推进到抽样逐条比对，修复前备份，修复后按同一口径复验。
要点总览（TL;DR）
- 先界定“对不上”的类型：数量差异、字段内容差异、关联关系丢失、状态与历史时间线异常，四类症状对应不同的排查路径。
- 统一比对口径是排查前提：确认统计时间点、过滤条件、是否含已删除/归档/子任务，比对的是迁移前后同一批数据而非新旧系统全量。
- 按“总量与过滤条件—抽样逐字段比对—迁移日志与批次—映射表覆盖”的顺序推进，从低成本核对逐步缩小范围。
- 真实丢失是最后才下的结论：口径统一、映射核对、抽样比对后仍缺记录，且日志显示批次已完整执行，才可初步定性。
- 修复前先备份并设定停止点，修复后按同一口径复验，把映射规则、过滤条件和默认值处理固化为迁移检查项。
先确认“对不上”到底指什么
“数据对不上”是一句笼统的描述，可能指向完全不同的四类问题，排查路径也各不相同。第一步是把这句话拆成可验证的差异类型，并写下来作为后续比对的基准。
四类差异症状
- 数量差异：迁移后某项目、某问题类型或某状态下的记录条数与迁移前不一致，表现为总数少了、多了或分布变了。
- 字段内容差异：记录条数一致，但具体字段的值不同，例如负责人为空、优先级变成默认值、枚举值显示为未映射项、日期偏移。
- 关联关系丢失：主记录存在，但子任务、问题链接、附件、评论、关联的测试或需求对象没有一起过来，或指向了错误的对象。
- 状态与历史时间线异常：当前状态与迁移前不符，或变更历史缺失、顺序错乱、时间戳被重写为迁移当天。
这四类症状的成因和验证方法不同。数量差异优先查过滤条件和迁移批次；字段差异优先查映射表；关联丢失优先查对象依赖是否纳入迁移范围；状态与时间线异常优先查工作流转换规则。先归类，能避免在错误方向上花时间。
统一比对口径
归类之后，要确认两边的数字是在同一口径下取出来的。需要逐项确认：
- 统计时间点：迁移前快照取的是哪一天、哪个时刻的数据，迁移后是否在同一时点口径下统计。迁移期间原系统若仍有新增或修改，数量天然会对不上。
- 过滤条件：两边是否使用了相同的项目范围、问题类型、状态集合和筛选条件。一边按“全部问题”统计、另一边按“未关闭问题”统计，差异就来自条件本身。
- 是否包含已删除、归档和子任务：已删除记录、归档项目、子任务在两边系统的默认统计中处理方式可能不同，需要明确纳入还是排除，并在两边保持一致。
- 比对对象是同一批数据：正确做法是拿迁移前导出的同一批记录，与迁移后对应记录逐一对照，而不是拿新系统全量数据与旧系统全量数据直接比总数。后者会把迁移期间的新增数据、未纳入迁移范围的项目一起算进来，制造假差异。
把差异类型和比对口径写成一份简短说明，注明数据来源、取数时间、过滤条件和纳入范围。这份说明既是排查基准，也是后续复验时判断“差异是否收敛”的依据。
常见原因假设与各自的排除证据
下面按成因分组列出假设，每条都给出验证方法和排除证据。排查时把假设当假设，用证据决定取舍，避免看到数量不一致就直接判定为数据丢失。
| 差异类型 | 可能原因 | 验证方法与排除证据 |
|---|---|---|
| 数量差异 | 统计口径不同：过滤条件、时区、状态归类不一致 | 用完全相同的过滤条件和时区重新取数；若差异消失或大幅缩小，说明是口径问题 |
| 数量差异 | 迁移批次中断或部分记录被权限过滤未导出 | 查迁移日志与批次记录，确认批次是否完整执行；对比导出清单与源系统记录清单 |
| 字段内容差异 | 字段类型不匹配、必填项被填默认值、枚举值未映射 | 抽取若干条记录逐字段对照；检查映射表中该字段是否有对应项，未映射项通常表现为空值或默认值 |
| 关联关系丢失 | 子任务、问题链接、附件、评论未随主记录迁移 | 在目标系统打开典型记录，检查子任务列表、链接区、附件区和评论区是否完整；对照源系统同一记录 |
| 关联关系丢失 | 用户映射缺失，导致负责人、经办人、评论作者为空或错位 | 核对用户映射表覆盖范围，检查是否存在同名、离职、外部账号等未映射用户 |
| 状态与时间线异常 | 工作流状态机转换规则不同，历史状态被合并或重写 | 对比同一记录在两边系统的状态变更历史条数、顺序和时间戳；时间戳集中变为迁移当天是典型信号 |
| 真实丢失 | 迁移范围未覆盖某类对象，或导出阶段被过滤 | 抽样逐条比对后仍找不到记录，且迁移日志显示该批次已执行完毕，才可初步判定为丢失 |
口径类原因：先排除最省力的可能
时区和状态归类是最容易被忽略的两类口径问题。跨时区团队中，按日期筛选的结果可能整体偏移一天；状态归类上，源系统把某些状态视为“进行中”，目标系统归入“待处理”，按状态分组统计时就会出现分布差异。验证方法是固定同一时区、同一状态集合重新统计，差异消失即可排除。
映射类原因：从映射表找证据
字段内容错位通常能在映射表里找到直接证据：某字段在映射表中没有对应项，迁移后表现为空值或落到默认值；必填字段在源系统中允许为空，目标系统强制填充，就会出现批量默认值；单选、多选等枚举字段的值未逐项映射，会显示为未识别项。逐项检查映射表的覆盖率，比逐条翻记录更快。
关联类与转换类原因：打开记录看细节
关联丢失和状态时间线异常都需要打开具体记录核对。子任务、链接、附件、评论属于依附于主记录的对象，是否随主记录一起迁移取决于迁移范围的定义；用户映射缺失则会让负责人、评论作者等字段变空。状态历史方面，两套系统的工作流模型不同，历史状态在转换中被合并、截断或时间戳被重写，都会让时间线看起来“对不上”，这类差异需要对照源系统的历史记录逐条确认。
真实丢失：最后才下的结论
只有在口径已统一、映射表已核对、抽样逐条比对后记录仍然缺失，并且迁移日志显示对应批次已完整执行的情况下，才把问题定性为真实丢失。定性之后再去查该批次覆盖的对象范围、导出时的权限过滤条件，以及是否有对象类型整体未纳入迁移计划。
按顺序执行的排查步骤
排查从低成本、大范围的核对开始，逐步缩小到具体字段和具体记录。每一步都有明确的判断标准，达到标准再进入下一步。
第一步：核对总量与过滤条件
用统一后的口径分别统计迁移前后各项目、各问题类型的记录数，做成对照表。判断标准：如果差异集中在某几个项目或某类对象，问题范围就锁定在这些项目；如果全局普遍偏少，优先怀疑批次或权限过滤；如果只是分布不同而总数接近，优先怀疑状态归类和时区。
第二步：抽取典型记录逐字段比对
从差异集中的范围里抽取有代表性的记录，覆盖不同问题类型、不同状态、有无子任务和附件、有无多次状态变更等情形。逐字段对照标题、描述、负责人、优先级、日期、枚举值，再检查子任务、链接、附件、评论和状态历史。判断标准：能定位到具体字段或具体对象类型，就算完成本步；如果抽样记录全部一致，回到第一步检查口径。
第三步：检查迁移日志与批次记录
查看迁移执行日志，确认各批次是否完整执行、有无中断、跳过或报错记录，以及报错涉及的对象范围。判断标准：日志中若有失败批次或跳过记录，且范围与第一步的差异范围吻合，即可定位到批次层面；日志显示全部成功而差异仍在，则问题更可能出在映射或转换规则上。
第四步：核对映射表覆盖情况
逐项检查用户、状态、枚举值、字段类型的映射表，确认源系统中的每个取值都有对应项，没有遗漏、重复映射或错误指向。判断标准：映射表覆盖率达到百分之百，且抽样记录的字段值与映射规则一致。
第五步：修复前备份并设定停止点
在重跑迁移、批量修改字段、删除重复记录等操作之前，先导出当前数据快照或完成备份，并明确本次操作的范围和停止条件，例如“只重跑某项目某批次”“字段修正仅限某枚举值”。操作过程中一旦发现影响范围超出预期，立即停止并回到快照。破坏性操作没有备份就不执行，这是排查过程中必须守住的边界。
修复后的复验与复发预防
修复动作完成不等于问题解决，需要用同一套口径证明差异已经收敛，并把这次排查的结论沉淀为下次迁移的检查项。
复验：用同一口径重新比对
复验时沿用第一步确定的差异分类和比对口径，重新统计总量、重新抽取同一批记录逐字段对照、重新检查关联对象和状态历史。判断标准：此前记录的每一处差异都已消除或有明确解释，抽样记录与源系统一致。复验结果要写成清单，逐条标注差异项、原因、修复动作和验证结论。
保留验收证据
把迁移前后的数据快照、比对清单、迁移日志和复验记录一并归档。这些材料既是本次迁移的验收证据，也是后续出现争议时判断责任范围的依据。比对清单建议包含：差异类型、涉及对象、记录数量、原因归类、处理方式和复验结果。
固化为迁移检查项
把本次排查中确认的规则写进迁移检查清单，供后续迁移或增量同步复用：
- 迁移前明确数据范围，逐项列出纳入和排除的对象类型，包括子任务、附件、评论、链接和已归档项目。
- 字段映射表在迁移前完成全量核对，枚举值逐项对应，默认值处理规则提前确认并记录。
- 用户映射覆盖全部账号，包括离职、外部和同名账号的处理方式。
- 状态与历史记录的转换规则提前确认，明确时间戳是否保留原值。
- 比对口径在迁移前确定，包括统计时间点、过滤条件和时区。
增量同步与小批量试迁移
如果迁移后还有增量同步或二次迁移，先做小批量试迁移：选取一个有代表性的项目，完整走一遍迁移、比对、复验流程，确认映射规则和转换规则在实际数据上成立，再扩大到全量。试迁移阶段发现的差异，修正成本远低于全量迁移后返工。
在排查和复验过程中，比对清单、映射规则和复验记录需要有固定的承载位置，避免散落在个人表格里。ONES 的文档与工作项可以承载这类迁移检查项和差异记录：把每一条差异登记为工作项，关联到对应的迁移批次和负责人，修复后在同一处更新复验结论，验收时按清单逐条核对。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，迁移内容包括用户、用户组、系统配置以及问题数据的属性、附件和评论，这些范围可以直接对应到上面的检查项；对于依赖插件的定制场景，迁移前需要逐项评估，不能假设所有插件功能都能一一对应。把迁移范围、映射规则和比对口径在迁移前确认清楚，是减少迁移后数据对不上的有效方式。
常见问题
迁移期间原系统还有人在用，数量对不上算正常吗？
这种情况下的数量差异通常来自数据本身在变化，而非迁移出错。迁移前快照取的是某一时刻的数据，迁移执行期间原系统若有新增、修改或关闭问题，迁移后的数据与快照天然不一致。排查时先确认迁移窗口内原系统的写入情况，再决定是接受这部分差异，还是在切换前做一次增量补齐。如果差异量级与迁移窗口内的活跃操作量大致吻合，基本可以归为口径问题。
抽样比对时发现个别记录字段为空，是迁移丢了还是映射没配好？
先查映射表，再下结论。打开该字段的映射配置，确认源系统中的取值在映射表中是否有对应项。没有对应项时，迁移后通常表现为空值或落到默认值；如果映射表覆盖完整而记录仍为空，再检查源系统该记录本身是否就为空，以及该字段是否在迁移范围内。个别记录为空更常见的原因是枚举值未映射或用户映射缺失，批量记录同时为空才更值得怀疑迁移范围或批次问题。
状态历史的时间戳全变成迁移当天了，这算数据丢失吗？
这属于转换类差异，记录本身还在，但历史时间线被重写了。两套系统的工作流模型不同，历史状态在转换中可能被合并、截断，时间戳也可能被替换为迁移执行时间。判断方法是打开源系统同一记录，对照状态变更的条数、顺序和原始时间戳。如果业务上需要保留原始时间线，应在迁移前确认转换规则是否支持保留原值，并在复验清单中把这一项单独列出核对。
确认是真实丢失后，能直接重跑整个迁移吗？
不建议直接全量重跑。先做两件事：一是导出当前数据快照或完成备份，明确重跑的范围和停止条件，例如只重跑某个项目或某个批次；二是查清丢失原因，是批次中断、权限过滤还是对象类型未纳入范围，原因不同修复方式也不同。全量重跑可能覆盖已修复的数据或产生重复记录，扩大影响面。范围明确、备份到位后再执行，执行完按原比对口径复验。
后续还有增量同步，怎么避免同样的差异再出现一次？
把这次排查确认的规则固化为检查项，并在增量同步前做小批量试迁移。检查项至少覆盖：数据范围逐项列出纳入和排除的对象类型，字段映射表全量核对，用户映射覆盖离职、外部和同名账号，状态与历史记录的转换规则提前确认，比对口径在同步前确定。试迁移选取一个有代表性的项目完整走一遍迁移、比对、复验流程，确认规则在实际数据上成立后再扩大范围，修正成本远低于全量返工。
