研发历史记录遗漏，指系统迁移或数据导出时，没有随工作项主体一并保留的附属历史信息。常见类型包括评论与回复、字段变更历史、状态流转记录、附件与内嵌图片、关联链接与依赖关系、操作日志与审计痕迹、工时与估算变更、标签与版本归属变更。判断一条信息是否属于遗漏范围，可以看它是否依附于某个工作项，并承载研发决策与协作过程。
要点总览（TL;DR）
- 研发历史记录遗漏指迁移或导出时未随工作项主体保留的附属历史信息，判断口径是“依附于工作项”且“承载研发决策与协作过程”。
- 常见类型包括评论与回复、字段变更历史、状态流转记录、附件与内嵌图片、关联链接与依赖关系、操作日志与审计痕迹、工时与估算变更、标签与版本归属变更。
- 遗漏多源于主体数据与附属历史分开处理：账号映射缺失导致评论与变更记录被静默跳过，附件引用与文件实体不同步，跨项目关联关系断链。
- 记录遗漏与工作流配置迁移、迁移结果核验、字段映射错误属于不同范畴，排查时先确认记录是否存在，再判断是否映射出错。
- 迁移前按记录类型逐项确认导出范围、账号映射、文件路径重写和关系重建规则，比迁移后逐条比对更有效。
研发历史记录遗漏指什么
研发历史记录遗漏描述的是迁移结果中的一种缺口：工作项的标题、描述、负责人、状态等主体字段已经进入新系统，但围绕这个工作项发生的讨论、修改和流转痕迹没有同步保留。它发生在数据迁移、批量导出、系统重建或格式转换的过程中，结果表现为新系统里的工作项看起来完整，点开却缺少过程信息。
判断一条信息是否属于遗漏范围，可以用两个条件来界定。第一，它依附于具体工作项，离开工作项就没有独立意义，例如某条评论、某次状态变更、某个附件。第二，它承载研发决策与协作过程，能说明“为什么改”“谁提出的”“什么时候发生的”。同时满足这两条，就应当纳入历史记录的迁移范围。只满足第一条而不承载决策过程的信息，例如单纯的系统缓存或临时渲染数据，通常不作为历史记录对待。
这个定义也划出了本文的讨论边界。研发历史记录遗漏关注的是“记录内容有没有带过去”，工作流、字段配置、插件行为属于配置类迁移对象，迁移完成后的抽样核验与切换管理属于另一类工作，两者与记录遗漏相关但不等同。
哪些记录类型属于遗漏范围
按依附于工作项这一口径，研发历史记录遗漏通常覆盖以下几类内容。每一类在迁移后缺失时，表现各不相同，识别方式也有差异。
| 记录类型 | 具体内容 | 遗漏后的典型表现 |
|---|---|---|
| 评论与回复 | 工作项下的讨论、评审意见、补充说明、回复串及其作者与时间 | 工作项存在但讨论区为空，评审结论和决策依据消失 |
| 字段变更历史 | 优先级、负责人、截止日期等字段的每次修改及修改前后值 | 只看到当前值，无法还原需求被调整的过程 |
| 状态流转记录 | 工作项在各状态间的进入、离开时间与操作人 | 状态停在最终值，流转耗时和卡点无法统计 |
| 附件与内嵌图片 | 设计稿、日志文件、截图、文档，以及正文中引用的图片 | 附件列表为空，或正文图片显示为失效占位 |
| 关联链接与依赖关系 | 阻塞、被阻塞、重复、关联等链接，父子工作项关系，跨项目引用 | 关系图断裂，依赖链在迁移后无法追溯 |
| 操作日志与审计痕迹 | 创建、删除、权限变更、批量操作等系统级记录 | 合规审计时缺少操作留痕，责任链不完整 |
| 工时与估算变更 | 预估工时、实际工时、剩余工时的历次调整 | 只剩最终数字，投入偏差和估算修正过程丢失 |
| 标签与版本归属变更 | 标签的增删、版本或迭代归属的调整记录 | 当前标签可见，但归属调整的时间线无法还原 |
评论、变更历史、附件和关联链接都属于遗漏范围，这一点在迁移实践中容易达成共识，难点在于执行时是否逐项纳入迁移清单。其中关联链接与依赖关系需要特别注意：单个工作项迁移时关系可能完整，跨项目批量迁移时则容易只保留项目内关系，跨项目引用被截断。工时与估算变更、标签与版本归属变更则常被当作“当前值”处理，只迁结果不迁过程，从而形成隐性遗漏。
这些记录在迁移中如何产生遗漏
遗漏的形成机制，多数源于主体数据与附属历史被分开处理。迁移工具通常先识别工作项主体，再按类型分别抽取附属信息，每一类走不同的导出路径和映射规则。路径越多，衔接点越多，丢失的机会也越多。
评论与变更历史依附于用户和时间戳。迁移时需要把原系统的操作人映射到新系统的账号，把原始时间转换为目标系统的时间格式。如果某个账号在目标系统中不存在、映射表缺失，或者时间戳在转换中越界，这条记录就可能被跳过而不是报错。批量迁移中这类静默跳过最难发现，因为工作项本身迁移成功，错误不会阻断流程。
附件走独立的存储路径。工作项记录里保存的是附件引用，文件实体存放在对象存储或文件服务器中。迁移时如果只导出了引用而没有同步文件实体，或者文件实体迁移完成但引用地址没有重写，附件就会表现为丢失或无法打开。内嵌图片的问题更隐蔽，它嵌在描述或评论的富文本中，需要解析正文并替换图片地址，解析规则不完整时图片会保留占位而内容缺失。
关联关系在跨项目时容易断链。依赖关系、父子关系、关联链接往往以工作项标识为锚点，迁移后标识发生变化，如果关系表没有同步重建，或者只重建了同项目内的关系，跨项目引用就会指向空值。审计日志和操作记录则常因权限模型差异被排除在迁移范围之外，迁移方案默认只迁业务数据，系统级留痕另行处理。
这些机制说明，记录遗漏很少是单点故障，更多是多个处理环节叠加的结果。迁移前按记录类型逐项确认导出范围、账号映射、文件路径和关系重建规则，比迁移后逐条比对更有效。
容易与历史记录遗漏混淆的相邻概念
记录遗漏常与三类相邻工作混在一起讨论，区分它们有助于把迁移范围圈定清楚。
| 相邻概念 | 关注对象 | 与记录遗漏的区别 |
|---|---|---|
| 工作流与扩展能力迁移 | 状态机、字段配置、权限方案、插件与自动化规则 | 迁移的是“系统怎么运转”的配置，记录遗漏关注“发生过什么”的内容 |
| 迁移验证与切换管理 | 抽样比对、数量核对、回滚方案、切换窗口 | 属于迁移后的质量保障动作，记录遗漏是验证要发现的问题之一 |
| 字段映射错误 | 字段与字段值之间的对应关系 | 映射错误会让数据进错位置或值被改写，记录遗漏是数据根本没有进入目标系统 |
工作流与扩展能力迁移处理的是配置对象，例如问题类型、工作流定义、字段配置和权限配置。这些内容迁移失败会影响新系统中工作项如何流转，但不属于历史记录遗漏。迁移验证与切换管理是在迁移执行之后开展的核验工作，它负责发现遗漏，本身不定义遗漏范围。字段映射错误与记录遗漏的结果有时相似，都表现为信息不可用，但成因不同：前者是数据到了但放错或变形，后者是数据没有随主体一起迁移。排查时先确认记录是否存在，再判断是否映射错误，可以避免把两类问题混为一谈。
一个具体例子与常见误解
假设一个需求工作项在迁移前包含：标题与描述、三条评审评论、负责人从张三改为李四的变更记录、从“待评审”到“开发中”的状态流转、两张设计稿附件、一条阻塞另一个项目的依赖链接，以及预估工时从 8 小时调整为 12 小时的记录。迁移后，新系统中该工作项标题、描述和当前负责人都在，评论为空，变更历史只显示当前值，附件列表为空，依赖链接消失，工时只保留 12 小时。按本文口径，评论、变更历史、状态流转、附件、依赖链接和工时调整记录都属于遗漏，只有主体字段完成了迁移。
常见误解之一，是认为只迁标题和描述就算完整。标题和描述只说明工作项“是什么”，评审意见、修改原因和流转耗时说明它“为什么变成现在这样”。研发交接、复盘和审计依赖的正是后者，缺少这些内容，迁移后的工作项只能当作新任务使用，历史连续性中断。
常见误解之二，是认为附件没丢就等于历史完整。附件只是记录类型中的一项，评论、变更历史、关联关系和审计痕迹同样承载决策过程。即使附件全部迁移成功，评论缺失仍会导致评审结论无法追溯，依赖链接缺失仍会导致排期依据消失。判断迁移是否完整，应当按记录类型逐项核对，而不是用某一类记录的存在代替整体结论。
在迁移方案中把评论、附件、历史记录与关联关系一并纳入范围，并明确账号映射、文件路径重写和关系重建的处理方式，是减少这类遗漏的常见做法。ONES 的 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，问题数据迁移包括属性和属性值、附件、评论等信息，目标是在切换工具后保持研发过程连续。具体项目中细粒度历史类型和跨项目关联关系的处理方式，仍需在迁移评估阶段逐项确认。
常见问题
评论和变更历史迁移后数量对不上，应该先查什么？
先确认差异是“记录没迁过来”还是“记录迁过来但归属错了”。可以抽取若干工作项，比对原系统与新系统的评论条数、变更记录条数，并核对每条记录的作者和时间戳。如果条数缺失且集中在特定人员或特定时间段，优先检查账号映射表和时间格式转换规则；如果条数一致但作者显示为空或时间偏移，属于映射问题而非记录遗漏。
批量迁移中账号不存在时，部分工具会跳过该条记录而不中断任务，这类静默跳过不会在迁移日志中显性报错，需要按人员维度单独核对。
附件文件都迁过去了，为什么还算历史记录不完整？
附件只是记录类型中的一项。评论、字段变更历史、状态流转记录、关联链接与审计痕迹同样承载研发决策过程，附件完整不能替代其他类型的核对。此外，附件本身也有两种失败形态：文件实体迁移成功但工作项中的引用地址未重写，表现为附件列表为空或打不开；正文内嵌图片的地址未替换，表现为占位符残留。判断完整性应按记录类型逐项核对，而不是用某一类记录的存在代替整体结论。
跨项目的依赖关系和关联链接在迁移中如何处理？
关联关系通常以工作项标识为锚点存储，迁移后标识变化，关系表需要同步重建。同项目内的关系相对容易保留，跨项目引用则容易在批量迁移时被截断，只保留项目内关系。迁移前应梳理跨项目依赖清单，确认关系重建规则是否覆盖跨项目场景，并在迁移后抽取若干条依赖链做端到端核对。
ONES 官网迁移资料写到可迁移项目、工作项、状态、字段、流程、附件和历史记录，未逐项说明关联关系的处理方式，具体项目中需在迁移评估阶段确认。
操作日志和审计痕迹属于迁移范围吗？
从记录类型界定看，操作日志与审计痕迹依附于工作项、承载操作责任链，属于历史记录遗漏的讨论范围。但在实际迁移方案中，这类系统级留痕常因权限模型差异被单独处理，默认只迁业务数据。如果合规审计要求保留完整操作留痕，需要在迁移前明确这部分是否纳入范围，以及目标系统的审计能力能否承接，避免迁移完成后才发现责任链不完整。
流程配置迁移失败和记录遗漏是同一类问题吗？
两者属于不同范畴。流程配置迁移处理的是状态机、字段配置、权限方案、插件与自动化规则，关注新系统“怎么运转”；记录遗漏关注的是“发生过什么”的内容有没有带过去。配置迁移失败会影响工作项在新系统中的流转方式，记录遗漏则表现为工作项存在但过程信息缺失。ONES 的 Jira 迁移能力中，问题类型、工作流、字段配置、权限配置属于配置类迁移对象，与评论、附件等历史记录分开表述。
