核对Jira迁移后的数据是否完整，关键是把“完整”拆成可计数的对象口径：按问题、评论、附件、状态历史、字段值、用户与权限分组，分别确定源端基准数量、目标端落地数量和允许的例外清单，再用“目标端数量÷源端数量”和“差异条数”双向核对。核对时固定同一时间窗和同一筛选条件，对分母为零、字段不可映射、附件缺失等情形单独登记，最后以抽样逐条比对和差异闭环作为通过依据。单看总数一致，不足以证明数据完整。
要点总览（TL;DR）
- 完整性核对先把“完整”拆成可计数的对象口径：问题、评论、附件、状态历史、字段值、用户与权限六类分别计数、分别判定。
- 每个指标写清分子、分母、时间窗和单位，源端以导出快照为基准并记录导出时间点，目标端用同一筛选条件取数。
- 核对按总量比对、关键字段比对、分层抽样逐条验证、差异登记与闭环四步推进，完整率与差异条数同时记录。
- 总量一致不足以证明完整，评论缺失、附件损坏、字段被默认值填充都可能被总数掩盖，判断依据是差异清单的处置结论。
- 不设通用达标线，通过标准由业务验收方与迁移执行方在核对前共同确认并写入验收文档。
核对完整性要回答哪些问题
完整性核对的目标是确认迁移后业务可以继续使用、历史可以追溯。它回答三个问题：迁移后的项目还能不能正常流转，历史问题还能不能查到当时的上下文，权限和用户关系还能不能让合适的人看到合适的数据。把“迁移任务执行成功”当作验收结论，容易漏掉字段值丢失、评论缺失、附件打不开这类问题，它们往往不影响迁移程序跑完，却直接影响业务使用。
核对对象建议按以下六类分组，每组单独计数、单独判定：
- 问题：记录总数、各问题类型数量、各项目数量。
- 评论：评论总条数、每个问题的评论数分布。
- 附件：附件文件数、总容量、可下载可打开情况。
- 状态与流转历史：状态变更记录条数、关键问题的流转路径是否可还原。
- 字段值：关键字段的非空率与取值一致性，如状态、经办人、优先级、创建时间、解决时间。
- 用户与权限：用户与用户组数量、项目权限配置、空间或项目可见范围。
通过口径由三条共同构成：数量一致（在约定例外范围内）、关键字段一致（抽样逐条验证）、差异有登记与处置结论。三条缺一不可，任何一条未完成，本次核对都不宜判定为通过。核对开始前，业务验收方与迁移执行方应共同确认这三条的具体含义，并写入验收说明，避免事后对“一致”的理解产生分歧。
指标与统计范围怎么定
指标要能被第三方复算，就必须写清分子、分母、时间窗和单位。建议按下表建立指标清单，每个指标对应一条可执行的查询条件。
| 指标 | 分子（目标端） | 分母（源端基准） | 时间窗 | 单位 |
|---|---|---|---|---|
| 问题记录完整率 | 目标端问题数 | 源端导出问题数 | 按创建时间区间，如2023-01-01至2024-06-30 | 条 |
| 评论完整率 | 目标端评论数 | 源端评论数 | 同上，按评论所属问题的创建时间 | 条 |
| 附件完整率 | 目标端可访问附件数 | 源端附件数 | 同上 | 个 |
| 历史条目完整率 | 目标端状态变更记录数 | 源端状态变更记录数 | 同上 | 条 |
| 关键字段非空率 | 目标端该字段非空的问题数 | 源端该字段非空的问题数 | 同上 | 条 |
| 用户覆盖完整率 | 目标端已建用户数 | 源端导出用户数 | 迁移时点快照 | 人 |
统计范围要固定三件事：项目范围（哪些项目纳入本次核对）、创建时间区间（起止日期，含边界）、状态范围（是否包含已关闭、已归档项目）。分母以源端导出快照为准，导出时记录导出时间点。明确排除项并写入说明，例如已删除且不可恢复的数据、明确不迁移的测试项目、归档后不再维护的历史项目。排除项一旦确定，源端和目标端使用同一份排除清单，否则分子分母口径不一致，算出的完整率没有意义。
数据口径与证据从哪里取
源端基准的取数方式有三种常见选择：Jira的筛选器导出为CSV、使用内置报表或统计插件计数、通过API分页拉取后汇总。无论哪种方式，都要记录导出时间点、筛选条件原文和导出人。导出时间点很重要，因为迁移后源端可能仍在被使用，晚于迁移时点的数据不应计入基准。
目标端结果使用与源端相同的筛选条件查询或导出。常见错误是源端按“创建时间”筛选，目标端按“更新时间”筛选，或者源端包含子任务、目标端默认不显示子任务，导致数量差异被误判为数据丢失。取数前先把两边的筛选条件逐项对照，确认项目范围、时间字段、状态集合、是否含子任务四项一致。
证据留存建议至少包括：源端导出文件（带时间戳命名）、目标端导出文件、使用的查询语句或筛选条件截图、差异登记表、抽样比对记录。这些材料是验收文档的附件，也是后续争议时的判断依据。证据不需要复杂，但要能让另一个人按同样条件复算出同样的数字。
完整性核对的计算与比对步骤
核对按四步推进，前一步未完成不进入下一步，避免在错误基数上做抽样。
第一步，总量比对。对每个指标计算完整率：完整率＝目标端数量÷源端数量×100%，同时记录差异条数＝源端数量－目标端数量。完整率接近100%且差异条数为零或全部落在已登记的例外清单内，才进入下一步。差异条数为正说明目标端少于源端，需要排查；为负说明目标端多出记录，常见原因是重复导入或源端导出后又有新增。
第二步，关键字段比对。对状态、经办人、优先级、创建时间、解决时间等字段，按取值分布比对。例如源端“高优先级”问题120条，目标端应为120条；源端经办人为空的记录数，目标端也应保持为空，不能被默认值填充。时间字段注意时区与格式，源端显示为本地时间、目标端存储为UTC时，直接比对字符串会全部不一致，应先统一换算再比。
第三步，抽样逐条比对。按项目或时间分层抽样，每层抽取一定数量的问题，逐条打开核对评论条数与内容、附件能否下载打开、状态历史是否完整、关键字段值是否一致。抽样比例根据项目重要性和差异情况确定，差异集中的项目应提高抽样量直至全量核对。
第四步，差异登记与闭环。每条差异登记为一行，字段包括：差异编号、项目、对象类型（问题/评论/附件/字段/用户）、源端标识、差异描述、原因分类、是否可接受、处置结论、责任人、状态。原因分类建议使用固定枚举：字段不可映射、附件缺失或损坏、重复记录、权限导致不可见、源端数据本身异常、待排查。每条差异必须有处置结论，状态从“待处理”流转到“已修复”或“已接受”，核对才算闭环。
一个可复算的核对示例
以下为演示情景，数字为假设值，用于说明计算方式。
设定某项目在源端导出快照中：问题500条、评论3200条、附件860个、状态变更记录4100条。迁移后目标端同口径查询得到：问题498条、评论3175条、附件852个、状态变更记录4088条。
- 问题完整率＝498÷500×100%＝99.6%，差异2条。
- 评论完整率＝3175÷3200×100%＝99.22%，差异25条。
- 附件完整率＝852÷860×100%＝99.07%，差异8个。
- 历史条目完整率＝4088÷4100×100%＝99.71%，差异12条。
差异登记与判定示例：
- 问题差异2条，排查为源端两条记录属于已删除状态、导出时被包含但不在迁移范围，登记为“源端数据本身异常”，判定可接受，附导出截图。
- 评论差异25条，集中在3个问题，原因是这3个问题在源端含内嵌图片的评论，迁移后图片未随评论保留，登记为“附件缺失”，判定不可直接接受，需补迁或由业务方确认可放弃。
- 附件差异8个，其中5个为超过单文件大小限制未迁移，3个迁移后文件大小为零无法打开，均登记为“附件缺失或损坏”，状态为待修复。
- 历史条目差异12条，排查为源端存在状态回退再前进的连续变更，目标端合并了相邻同状态记录，登记为“字段不可映射”，需业务方确认流转路径是否仍可还原。
这个例子说明：四项完整率都在99%以上，但评论和附件存在实质性缺失，不能仅凭总量接近就判定通过。差异条数比完整率更能定位问题，完整率用于汇报，差异清单用于处置。
结果怎么解读，哪些情况不能算通过
分母为零时，完整率没有定义，不能写成100%。处理方式是标注“源端无此类数据”，并在结论中说明该指标不适用，而不是默认通过。例如某项目源端没有附件，附件完整率一栏应写“不适用”，避免拉高整体观感。
数据不可比的情形需要单独说明，不能直接算作差异：字段映射变更导致一个源端字段拆成两个目标端字段，或两个源端字段合并为一个；状态体系不同导致状态名称无法一一对应；时间格式或时区差异导致比对结果全部不一致；权限模型差异导致部分数据在目标端对当前核对人不可见。这些情形应先调整比对口径或改用映射表比对，确认口径可比后再计算完整率。
单指标一致不等于完整。问题总数一致，可能掩盖评论缺失、附件损坏、字段被默认值填充。反过来，某个指标略低于100%，也未必代表迁移失败，可能全部落在已登记的合理例外内。判断依据是差异清单的处置结论，而不是单一百分比。
本文不设通用达标线。完整率达到多少算通过，取决于业务对历史数据的使用强度、差异涉及的问题是否仍在流转、缺失内容能否从源端补取。通过标准应由业务验收方与迁移执行方在核对前共同确认，并写入验收文档，核对结束后按同一标准判定。
核对过程中的协作与记录怎么落地
核对涉及三类角色，分工应在开始前明确：迁移执行方负责源端导出、目标端取数、差异修复；业务验收方负责确认关键字段和业务可用性、判定差异是否可接受；数据核对人负责比对计算、抽样验证、差异登记与进度跟踪。小团队中一人可兼多角，但判定“可接受”的动作应由业务方完成，避免执行方自评。
差异以工作项形式登记比放在表格里更利于跟踪。每条差异作为一个工作项，关联所属项目、对象类型、源端标识和处置状态，状态按“待排查—待修复—待确认—已关闭”流转，修复后由核对人复验再关闭。这样差异的负责人、处理过程和结论都留在系统里，验收时可以直接按状态统计未闭环数量。
核对结论沉淀为验收文档，内容包括：核对范围与排除项、指标清单与公式、各指标源端与目标端数量、差异汇总与处置结论、抽样记录、证据附件链接、双方确认记录。文档状态从草稿到评审通过，评审通过即作为本次迁移的验收依据。
如果迁移目标平台是ONES，核对工作可以顺着其已有的对象组织方式落地。ONES的Jira迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并把数据完整、业务连续作为迁移目标；迁移范围包括用户与用户组、问题类型与工作流等系统配置，以及问题属性、附件、评论等数据。核对中发现的差异可以直接登记为工作项，关联到对应项目，验收文档放在Wiki中并保留证据链接，差异状态和文档评审状态共同构成可追踪的验收记录。具体迁移范围以实际迁移项目评估结果为准，完整性核对的指标与通过标准仍需双方在项目中约定。
常见问题
源端在迁移后仍被使用，基准数量应该以哪个时间点为准？
以迁移时点的源端导出快照为准，并在导出时记录导出时间点、筛选条件原文和导出人。迁移后源端若仍有新增或修改，这些数据不属于本次迁移范围，计入基准会让目标端数量永远对不上。如果迁移期间源端没有冻结写入，建议在迁移窗口内先做一次全量导出作为基准，再对窗口内的增量单独登记，核对时分“基准部分”和“增量部分”分别比对。
差异登记为“可接受”之后，还需要做什么？
“可接受”是处置结论，不是流程终点。每条差异仍需写明判定依据（例如源端数据本身已删除、业务方确认该评论内容无保留价值），由业务验收方确认，并在验收文档中汇总可接受差异的条数和涉及对象。核对人应按状态统计未闭环数量，确认所有差异都从“待处理”流转到“已修复”或“已接受”，核对才算闭环。可接受差异清单也是后续复盘迁移质量的依据。
子任务、已关闭项目和归档数据要不要计入核对范围？
是否计入由核对前约定的项目范围、时间区间和状态范围决定，关键是源端和目标端使用同一份范围定义。子任务在部分工具中默认不显示，若源端导出包含子任务而目标端查询未包含，数量差异会被误判为数据丢失。已关闭和归档项目如果不在迁移范围内，应写入排除清单，两边同时排除。范围一旦确定就固定下来，中途调整需要重新取数并说明原因。
状态名称对不上、时间显示不一致，这类差异怎么处理？
先判断是口径问题还是数据问题。状态体系不同导致名称无法一一对应时，应建立源端到目标端的状态映射表，按映射关系比对，而不是直接比名称字符串。时间字段注意时区与格式，源端本地时间与目标端UTC存储直接比对会全部不一致，应先统一换算再比。字段被拆分或合并的情形，按映射关系重组后再计数。确认口径可比之后算出的差异，才进入差异登记表按真实缺失处理。
核对发现附件或评论缺失，补迁之后要重新核对哪些内容？
补迁完成后，对涉及的项目和对象类型重新取数，重算该指标的完整率与差异条数，并更新差异登记表中对应条目的状态。抽样验证应覆盖补迁的对象，确认附件能下载打开、评论内容完整。补迁可能引入重复记录，需要同时检查目标端数量是否超出源端基准。全部差异闭环后，更新验收文档中的数量表和结论，保留补迁前后的证据，便于追溯处置过程。
