ira 迁移数据完整性校验实操：为什么条数对上了，内容还是丢了

全文约 1317 字，阅读约 3 分钟。重点内容：迁移验收只核对 Issue 条数是最常见的致命盲区。附件超时中断、Unicode 字符解析失败、变更人字段映射丢失这三类损耗都不会报错。文末给可直接复用的三步校验流程。

智序 ORDR项目管理系统出品

做过 Jira 迁移的人大概都有个错觉：迁移工具跑完没报错、Issue 条数对得上，就算成了。实际上真正会出事的三类数据损耗，全都不会在日志里留下痕迹。

先看一组公开的抽检数据。某金融企业的 Jira 实例约 150GB，包含附件、截图、测试日志，用迁移工具官方声称的「一键迁移」跑完之后抽检结果是这样：

附件丢失约 3.2%，接近 4800 个文件。其中 60% 是大于 20MB 的大附件，根因是迁移工具默认并发限制导致请求超时
评论丢失约 0.8%，约 1200 条。集中在含中文双引号、表情符号这类 Unicode 特殊字符的评论，解析阶段被丢弃
工作流日志中的「变更人」字段约 5% 未能正确映射，直接后果是审计追溯链断裂

这三类的共同点：迁移工具视角下它们都属于「已处理」，不会进错误日志。

为什么官方迁移工具也靠不住

Jira 的数据模型里有大量隐藏外键和自增 ID。迁移工具通常只做基础字段映射，两个地方会漏。

一是插件数据。测试步骤、自定义度量这类由第三方插件写入的数据，不在标准数据模型里，迁移工具不会碰。你在 Jira 里看到的字段，导出后可能根本不存在。

二是存储路径权限。工具默认假设附件目录可读，实际部署里附件常挂在独立存储上，权限不足时表现为「跳过」而不是「失败」。

还有个更隐蔽的：声称支持增量迁移的工具，增量窗口期内源端 Jira 仍在被写入，最终两边数据必然不一致。

条数校验为什么无效

有家金融科技公司迁完第三天才发现问题：项目里少了 200 多条改动历史，包含需求变更记录、代码评审意见、测试环节讨论。Issue 本身一个没少，少的是 Issue 内部的 changelog 和 comment chain。

所以 count(*) 对得上是必然的，它只统计主表行数。丢失发生在关联表：jiraaction（评论）、changegroup / changeitem（变更历史）、fileattachment（附件元数据）。验收脚本如果只比对主表，这些永远查不出来。

这家公司不算不上心，有专职 DevOps、做过完整导出测试、staging 环境也跑过一轮验证。问题恰好藏在「看起来一切正常」的正向反馈里。

同一份复盘统计了 17 起迁移事故，样本覆盖金融科技、智能制造、游戏出海、SaaS 四个行业，团队规模 60 到 800 人。其中只有 2 起是工具已知 bug 导致的直接损坏，剩下 15 起全部指向三点：导出策略设计的盲区、团队对「完整验收」定义的低估、迁移流程中缺失独立校验环节。

可复用的三步校验流程

第一步，导出侧建基线。导出完整 XML 备份之后，单独生成一份附件 MD5 清单。这一步的意义在于给你一个跟迁移工具无关的独立参照，后面所有比对都以它为准。

# 思路示意：遍历附件目录生成 (相对路径, size, md5) 清单 find $JIRA_HOME/data/attachments -type f -printf '%Pt%sn' > attach.list while IFS=$'t' read -r p s; do echo -e "$pt$st$(md5sum "$JIRA_HOME/data/attachments/$p" | cut -d' ' -f1)" done < attach.list > attach.md5

第二步，导入侧抽检内容而不是条数。随机抽 10% 的 Issue，对每一条逐项核对附件数量与 MD5、评论条数与正文长度、变更历史的时间轴与变更人。重点是把「变更人」单独拎出来核，它是审计场景唯一有效的字段，也是最容易在用户映射阶段丢的。

第三步，留回退窗口。旧系统保留只读访问 30 天。上面那套流程全跑完，仍然会有约 0.2% 的偏差，主要是被删除后又恢复过的 Issue，这部分只能靠手动补录。留只读期就是给这种补录留时间。