研发历史数据是研发过程中形成、需要长期保留并可追溯的业务记录，既包括仍在流转的需求、任务和缺陷，也包括已关闭或归档、日后仍要查证的内容。判断一条记录是否属于研发历史数据，关键看它是否承载研发对象的状态、关系或证据。本文聚焦数据内容本身的范围与组成，流程配置、插件行为和迁移结果核验不在重点展开。
要点总览（TL;DR）
- 研发历史数据是研发活动中产生、记录对象状态与关系、需要长期保留并可追溯的业务记录，判断时看它是否承载状态、关系或过程证据。
- 范围上包括需求、任务、缺陷、测试用例、评审评论、附件、关联关系与操作记录，已关闭和已归档数据同样属于历史数据；流程配置、插件行为和结果核验归其他主题。
- 组成上可分为业务实体、关系与上下文、附属数据、增量数据四类，盘点清单和字段映射表可按这四类组织。
- 数据记录“发生了什么”，配置规定“可以怎样发生”，迁移时两者通常分开处理，插件扩展数据需按三条标准单独判断。
- 只迁未关闭数据、忽略评论附件、把日志当无用数据，是造成追溯缺口的三个典型误解。
研发历史数据的直接定义
研发历史数据可以定义为：在需求提出、任务执行、缺陷修复、测试验证、代码提交、构建发布和评审协作等研发活动中产生，记录研发对象在某一段时间内的状态、变更过程与相关证据，并因追溯、审计、复盘或交接需要而被保留的业务记录。这个定义包含三个要素：产生于研发活动、记录状态或关系、需要保留并可追溯。三者同时成立，才构成严格意义上的研发历史数据。
据此可以给出三条可操作的判断标准：
- 是否承载研发对象的状态。一条记录如果描述了某个需求处于什么阶段、某个缺陷由谁在何时修复、某个任务完成了多少工作量，它就属于历史数据。状态可以是当前的，也可以是某一历史时点的快照。
- 是否承载对象之间的关系。需求与任务的拆解关系、缺陷与测试用例的关联、提交与工作项的引用关系，这些关系本身构成追溯链条，属于历史数据的一部分。
- 是否构成过程证据。评审意见、评论讨论、附件中的设计稿与日志、操作记录，能够证明某项决策如何做出、某次变更由谁发起，属于证据性历史数据。
与普通文件、临时沟通记录的区别在于：普通文件如果只是存放资料、未与研发对象建立关联，通常按文档资料管理；临时沟通记录如即时消息中的口头约定，若未被沉淀到工作项或文档中，一般不纳入研发历史数据的迁移范围。判断时看它是否被研发流程引用、是否影响后续追溯，而非看它存放在哪个工具里。
范围边界：哪些算、哪些不算
研发历史数据的范围容易与相邻内容混淆。下面的表格按内容项给出归属判断，帮助在盘点时快速分类。需要说明的是，“不属于本文重点”仅表示这些内容在本篇概念解释中不展开，并不表示它们在迁移项目中可以忽略。
| 内容项 | 归属判断 | 说明 |
|---|---|---|
| 需求、任务、缺陷、测试用例 | 属于 | 研发核心业务实体，含已关闭与已归档记录 |
| 评审记录、评论、批注 | 属于 | 构成决策与讨论的过程证据 |
| 附件、图片、设计稿 | 属于 | 与业务实体关联时纳入，需保留关联关系 |
| 对象间的父子关系、关联链接 | 属于 | 追溯链条的组成部分 |
| 操作记录、变更历史 | 属于 | 用于审计与责任追溯 |
| 已关闭、已归档数据 | 属于 | 归档不改变其历史数据属性 |
| 流程状态机、字段配置、权限方案 | 不属于本文重点 | 属于配置，归配置迁移主题 |
| 插件产生的扩展数据 | 需单独判断 | 视其是否承载业务状态与证据而定 |
| 迁移结果核验、切换管理 | 不属于本文重点 | 属于迁移实施与验证主题 |
归档数据与已关闭数据仍属于历史数据，这一点在盘点时最容易被低估。团队常以“已经不用了”为由把关闭记录排除在迁移范围外，但追溯需求往往恰恰发生在项目结项之后，例如复盘缺陷根因、应对审计问询、交接给新维护团队。是否迁移应以追溯需要为准，而非以记录当前是否活跃为准。
研发历史数据由哪几部分组成
把研发历史数据拆成四类，可以直接对应到盘点清单和字段映射表的结构。四类数据的处理难度依次上升：实体数据有明确字段，关系数据依赖两端对象都存在，附属数据涉及文件存储，增量数据涉及迁移窗口的时间安排。
业务实体数据
需求、任务、缺陷、测试用例、代码提交与合并请求、构建与发布记录等，是历史数据的主体。每个实体包含标题、描述、状态、负责人、优先级、时间字段等属性。盘点时需要统计各实体的记录数量、字段清单和状态分布，作为映射表的输入。
关系与上下文数据
父子关系、关联链接、依赖关系、评论、评审记录属于这一类。它们本身不是独立实体，但决定了实体之间能否还原出完整的追溯链。映射时要确认关系两端对象都在迁移范围内，否则会出现指向空对象的悬空关联。
附属数据
附件、图片、日志、用户身份与时间戳属于附属数据。附件需要保留与原记录的绑定关系和原始文件名；用户身份需要与目标系统的账号建立对应，否则历史记录中的“谁操作”会丢失；时间戳应保留原始发生时间，而非迁移执行时间。
增量数据
迁移期间源系统仍在产生新记录，这部分增量数据需要在方案中明确处理方式，例如设定冻结窗口或在切换前做一次补充同步。增量数据的范围与切换策略相关，具体机制需结合项目实际方案确认。
在研发数据盘点与映射环节，ONES 的迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录组织迁移范围，并将问题数据的属性、属性值、附件、评论等纳入迁移内容，可作为按上述四类结构整理清单时的参照。方案同时建议在正式迁移前确认数据范围、功能匹配和系统适配，这与先盘点实体、再梳理关系、最后处理附属与增量的顺序一致。
与流程配置、插件行为的区别
研发历史数据与流程配置的分界，可以用一句话概括：数据记录“发生了什么”，配置规定“可以怎样发生”。流程状态机、字段配置、权限方案、问题类型定义属于配置，它们描述系统的运行规则，本身不承载某次研发活动的具体状态。迁移时两者通常分开处理，因为配置需要按目标系统的能力重新设计，而数据需要尽量原样保留。
以状态字段为例：某个缺陷从“待修复”流转到“已修复”再流转到“已验证”，这条流转记录及其时间、操作人属于历史数据；而“待修复→已修复→已验证”这条状态机路径属于流程配置。前者要保留，后者在目标系统中可能被重新设计为不同的状态集合，此时历史数据中的状态值需要通过映射表转换到新状态体系。
插件产生的扩展数据需要单独判断归属。判断依据仍是三条标准：它是否记录了研发对象的状态、是否建立了对象间关系、是否构成过程证据。例如插件写入工作项的额外字段值，若被团队用于追踪业务状态，应纳入数据范围；插件自身的运行日志若只用于排障，一般不作为研发历史数据迁移。ONES 的 Jira 迁移方案将用户、用户组、系统配置与项目配置（含问题类型、工作流、字段配置、权限配置）分别列出，体现了配置与数据分开处理的思路；Confluence 迁移则覆盖页面正文、附件、图片、常用宏及批注，其中批注属于典型的过程证据。
具体例子与常见误解
下面用一个演示情景说明研发历史数据的实际形态。某团队的一个需求“支持批量导出报表”从创建到关闭经历了完整链路：需求由产品经理创建并附上原型图；拆解为三个开发任务和一个测试任务；开发过程中产生两次代码提交并关联到任务；测试阶段提交两个缺陷，其中一个缺陷关联到对应测试用例；需求评审中留下五条评论和一次评审结论；需求上线后关闭，三个月后因客户反馈重新打开并补充一条缺陷。这条链路中，需求、任务、缺陷、测试用例是实体数据；拆解关系、提交关联、缺陷与用例的关联是关系数据；原型图、评论、评审结论是附属与上下文数据。任何一环缺失，后续复盘“为什么这个缺陷没被用例覆盖”都会失去依据。
围绕这个例子，有三条常见误解值得纠正：
- 只迁移未关闭数据。有人认为关闭的记录已无价值。实际上追溯需求多发生在项目结束后，关闭记录恰恰是复盘和审计的主要对象。遗漏关闭数据会在时间轴上留下断档。
- 忽略评论与附件。评论和附件常被视为“附带内容”而排在迁移优先级末尾。但决策理由往往只存在于评论中，设计约束往往只存在于附件里，缺失后实体数据仍在、决策依据却无法还原。
- 把日志当作无用数据。操作日志记录了谁在何时改了什么，是审计和责任追溯的直接证据。将其排除会削弱历史数据的证据属性。
这三类误解共同造成的后果是追溯缺口：数据看起来迁移完成了，记录数量对得上，但当需要回答“这个变更当时为什么这么定”时，找不到评论、找不到附件、找不到操作人。盘点阶段按实体、关系、附属、增量四类逐项核对，并在映射表中标注每类数据的保留规则，可以在迁移前就发现这类缺口。
常见问题
已关闭甚至已归档的需求和缺陷，还需要纳入研发历史数据范围吗？
需要。归档和关闭改变的是记录的活跃状态，不改变它的历史数据属性。复盘缺陷根因、应对审计问询、向新维护团队交接时，追溯对象往往正是这些已结束的记录。盘点时如果按“当前是否还在流转”来筛选，时间轴上就会出现断档。更稳妥的做法是以追溯需要为准，在映射表中为关闭和归档数据单独标注保留规则。
迁移期间源系统还在产生新记录，这部分数据怎么处理？
这部分属于增量数据，需要在方案中提前约定处理方式，常见做法是设定冻结窗口，或在切换前安排一次补充同步。增量范围与切换策略直接相关，具体机制要结合项目实际方案确认。盘点阶段先把实体、关系、附属数据梳理清楚，再确定增量窗口，顺序上更稳妥。
评论、附件和操作日志在迁移中优先级较低，可以先放一放吗？
不建议把它们排在最后。决策理由常常只存在于评论里，设计约束常常只存在于附件里，操作日志则记录了谁在何时改了什么。这些内容缺失后，实体数据看起来完整，但“当时为什么这么定”无法回答。盘点时可以把它们与实体数据一起列入清单，并在映射表中标注保留规则，避免迁移完成后才发现证据链断开。
插件写入工作项的扩展字段，算研发历史数据还是插件行为？
按三条标准单独判断：它是否记录了研发对象的状态、是否建立了对象间关系、是否构成过程证据。如果插件写入的字段值被团队用来追踪业务状态，应纳入数据范围；如果只是插件自身的运行日志、仅用于排障，一般不作为研发历史数据迁移。判断依据是内容承载的业务含义，而非它由哪个插件产生。
历史数据中的状态值在目标系统中不存在，迁移时怎么衔接？
这属于数据与配置分开处理的典型情形。原系统中的状态流转记录及其时间、操作人属于历史数据，需要保留；状态机路径属于流程配置，在目标系统中可能被重新设计。此时需要通过映射表把历史状态值转换到新状态体系，并在盘点阶段就确认状态集合的对应关系，避免迁移后出现无法归类的状态。
