研发历史数据迁移范围的划分，核心是回答“哪些数据必须跟着业务走、哪些只需留档备查”。比较稳妥的做法是按业务连续性、审计追溯、协作引用三条需求线逐类判断，把数据分成迁移、归档、不迁移三档，再据此安排批次。历史项目跨度多年、存在归档诉求时，这套分层尤其适用；ONES 可作为承载迁移范围清单与批次推进的方向之一。
要点总览（TL;DR）
- 研发历史数据迁移范围按业务连续性、审计追溯、协作引用三条需求线判断，把数据分为迁移、归档、不迁移三档，逐类标注处置方式与理由。
- 仍在迭代、承担审计或追溯义务、被其他工作项或文档引用的数据应纳入迁移；已关闭多年仅需备查的转入只读归档；无引用、无审计义务、无复用价值的草稿与临时记录不迁移。
- 按需求线划分而非按系统表结构全量搬运，能减少字段映射与关联重建的工作量，也避免把无人使用的历史记录带进新系统。
- 精细划分需要投入数据盘点、字段映射、引用核对和迁移窗口协调；历史跨度长、跨团队引用多的团队更容易收回这部分投入。
- 引用关系梳理不清、审计口径未定、归档环境不具备只读访问能力或迁移窗口与业务节奏冲突时，应暂缓或缩小范围，先做跨年度小范围试点验证划分是否成立。
先给结论：三类数据、三种处置
研发历史数据迁移范围可以按处置方式分为三档，每档对应不同的使用需求。划分结论取决于项目当前状态和合规要求，同一类数据在不同团队可能落入不同档位，因此需要逐类判断，不能套用统一标准。
| 处置档位 | 定义 | 典型判断依据 |
|---|---|---|
| 迁移 | 进入新系统，保持可编辑、可检索、可关联，参与日常协作 | 仍在迭代；承担审计或追溯义务；被其他工作项、文档、测试用例引用 |
| 归档 | 转入只读归档环境，可查阅、可调取，不参与日常编辑 | 已关闭多年；仅需备查；审计要求为“可提供”而非“在线可操作” |
| 不迁移 | 留在原环境或按制度销毁，不进入新系统 | 无引用关系；无审计义务；无复用价值的草稿、临时记录、重复数据 |
三条判断依据分别回答三个问题：业务连续性问“这条数据还会不会被继续使用”，审计追溯问“这条数据是否需要在未来某一天被调取证明”，协作引用问“这条数据是否还被其他对象指向”。三条中任意一条成立，就应优先考虑迁移；三条都不成立，才进入归档或不迁移的讨论。
需要强调的是，这个结论是条件式的。项目仍在迭代、合规要求明确、引用关系清晰的团队，适合按三档精细划分；项目已整体停摆、审计要求尚未明确的团队，应先缩小范围、保留归档，等条件成熟再决定迁移边界。
为什么按需求线划分，而不是按数据表划分
按系统表结构全量迁移，看起来最省心，实际代价往往被低估。研发工具里的表结构包含大量关联表：工作项、状态流转记录、字段值、评论、附件、关联关系、操作日志。全量搬运意味着每一张表都要做字段映射、类型转换和关联重建，数据量越大，映射错误和关联断裂的概率越高，验证工作量也随表数量成倍增长。更关键的是，全量迁移会把大量已经无人使用的历史记录带进新系统，增加检索噪音，也让新系统的权限配置和性能规划变得复杂。
按需求线划分则直接对应真实使用场景。业务连续性对应“团队明天还要接着干活”的数据，这部分必须完整、可编辑；审计追溯对应“未来可能被调取”的数据，这部分要求完整、可查、不可篡改；协作引用对应“被其他对象指向”的数据，这部分要求关联关系不断裂。三类需求对数据完整性和可用性的要求不同，处置方式自然不同。
划分结果可以直接转化为迁移批次。通常先迁移活跃项目和被高频引用的数据，保证切换后业务立即恢复；再迁移有审计义务但使用频率低的数据；归档数据单独安排一次批量导出和入库；不迁移数据在清单中标注理由后封存。批次顺序的依据是业务影响面，而非数据量大小。
哪些数据应纳入迁移：适用条件
纳入迁移的数据类别可以按以下条件逐条对照。满足任意一条，就应进入迁移档；多条同时满足的，优先级更高。
- 活跃或近期仍有迭代的项目数据：项目当前处于进行中状态，或最近一个规划周期内仍有需求、缺陷、任务在流转。这类数据迁移后要能继续编辑、流转和统计。
- 存在审计、合规、追溯义务的记录：所在行业或组织制度要求保留研发过程记录，且要求记录可检索、可关联、可导出。这类数据即使项目已关闭，也应迁移而非仅归档。
- 被其他工作项、文档、测试用例引用的数据：历史需求被当前版本引用，历史缺陷被回归测试引用，历史文档被现行规范引用。引用关系一旦断裂，追溯链条就断了，这类数据必须随引用方一起迁移。
- 跨团队仍在协作引用的历史条目：其他团队的计划、评审、发布记录中仍指向这些条目。迁移时要同步核对跨团队可见性和权限继承。
对照时建议以“数据类别”为单位而非以“单个项目”为单位。同一项目内，活跃需求属于迁移档，三年前的临时讨论记录可能属于不迁移档。按类别划分能让清单更稳定，也便于后续批次复用。
迁移要投入什么：前提与成本项
精细划分范围本身需要投入，判断是否值得做，要先看清这些成本项。
- 数据盘点与字段映射的人力：需要熟悉原系统数据结构的人逐类梳理数据类别，确认字段含义、枚举值、必填约束，并完成新旧字段的映射表。跨度多年的项目往往存在字段含义演变，映射工作量集中在这些历史差异上。
- 归档环境的存储与只读访问能力：归档档位要求数据可查阅、可调取，同时不被误改。需要提前确认归档环境的存储容量、检索方式和访问权限设计。
- 审计与引用关系的核对工作：引用关系需要逐条核对，确认迁移后指向仍然有效；审计义务需要与合规或质量部门确认口径，明确哪些记录必须在线可查、哪些只需可导出。
- 迁移窗口与业务停摆的协调成本：迁移期间相关项目可能需要暂停写入，窗口选择要与迭代节奏、发布计划协调。分批迁移可以缩短单次停摆时间，但增加了协调次数。
这些投入与迁移范围成正比。范围划得越细，盘点和核对的人力越多，但迁移量和验证量相应减少。团队规模较小、历史数据引用关系简单的，可以适当粗划；历史跨度长、跨团队引用多的，精细划分的投入更容易收回。
在清单落地和批次推进环节，可以把数据类别清单、字段映射表和批次计划放进统一的工作项与文档中管理，让每一类数据的处置状态、负责人和验证结果都可追踪。ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录等对象，并建议在正式迁移前确认数据范围、功能匹配和系统适配，这与先划分范围、再分批推进的思路一致。
什么情况下应暂缓或缩小迁移范围
以下条件出现时，强行按原计划全量迁移的风险高于收益，应暂缓或缩小范围。
- 历史数据引用关系无法梳理清楚：无法确认哪些数据被引用、引用方向如何，迁移后可能出现关联断裂且难以发现。此时应先做引用关系盘点，或把不确定的部分整体转入归档，保留原环境只读访问作为兜底。
- 审计要求尚未明确：合规或质量部门尚未给出保留期限、可查方式和调取流程。在口径明确前，把有潜在审计价值的数据先归档保留，避免迁移后因不满足要求而返工。
- 归档环境不具备只读访问能力：归档档位的前提是可查阅。如果归档环境只能存储不能检索，归档数据实际上无法满足备查需求，此时应缩小迁移范围、优先保证迁移档质量，同时推进归档环境建设。
- 迁移窗口与业务节奏冲突：发布窗口、季度结算、重要评审期间不宜安排大规模迁移。可以拆小批次，先迁移低风险类别，把高关联数据留到节奏平稳的窗口。
暂缓不等于放弃。把暂缓原因写进清单，标注解除条件和责任人，范围划分就从一次性判断变成了可持续推进的计划。
用一个小范围试点验证划分是否成立
三档划分是否合理，靠试点验证比靠讨论更可靠。试点选取应满足两个条件：跨年度，即包含至少一个早期项目和一個近期项目；有代表性，即覆盖活跃迭代、已关闭但有审计义务、存在跨团队引用等不同情形。
试点验证围绕三个要点展开：
- 迁移后引用关系是否可追溯：抽查被引用的工作项、文档和测试用例，确认迁移后指向正确、跳转可达、历史版本可查。
- 归档数据是否满足审计查阅：模拟一次审计调取，从归档环境检索目标记录，确认内容完整、附件可打开、时间与操作人信息可读。
- 不迁移数据的判断是否站得住：回查被列为不迁移的类别，确认确实无引用、无审计义务、无复用价值，避免误判造成不可恢复的丢失。
试点结果用于调整划分清单：引用关系断裂的类别上调为迁移，归档查阅不满足要求的上调为迁移或补充归档能力，误判为不迁移的类别及时纠正。清单稳定后再推广到全量批次，验证口径沿用试点中已确认的检查项。
常见问题
项目已经关闭多年，但当时的需求文档偶尔还会被新项目翻出来参考，这类数据算迁移还是归档？
关键看“被引用”是否仍在发生。如果新项目的需求、设计或测试用例中仍有指向这些历史文档的链接，引用关系就构成协作引用需求，应纳入迁移档，保证跳转可达、内容可查。若只是团队偶尔凭记忆去翻，没有实际的对象指向，可以转入只读归档，满足查阅即可。
实际操作中，建议先做一次引用关系抽查：在新系统的工作项和文档里检索历史条目的链接，统计仍被指向的条目，再决定这部分数据整体迁移还是按条目拆分处置。
审计部门只要求“能提供记录”，不要求在线可查，归档是否就够用了？
“能提供”通常意味着在约定时限内可以调取到完整记录，包括内容、附件、操作人和时间信息。归档档位如果具备只读检索和导出能力，一般可以满足这类要求；如果归档环境只能存储、无法按条件检索，调取就会依赖人工翻找，难以保证时限。
建议在划分前与合规或质量部门确认三件事：保留期限、调取时限、需要提供的信息项。口径明确后，再判断哪些记录必须迁移到在线环境、哪些放入归档即可，避免迁移完成后因不满足调取要求而返工。
历史项目跨度七八年，字段含义中途改过好几次，字段映射怎么做才不会出错？
字段含义演变是长周期项目迁移中最容易出问题的部分。可行的做法是按时间段分段梳理：把历史项目按字段口径变化的时间点切成几段，每段单独确认字段含义、枚举值和必填约束，再分别建立映射关系。
映射表完成后，用少量代表性数据做一次试迁移，逐字段比对迁移前后的值，重点检查枚举值转换和空值处理。发现偏差就回到映射表修正，确认稳定后再用于同段的其他项目。这样能把字段差异的影响控制在分段范围内，避免一处映射错误扩散到全量数据。
团队规模不大，历史数据也不多，还需要做这么细的三档划分吗？
划分的精细程度可以与数据规模和引用复杂度匹配。团队小、历史项目少、跨团队引用关系简单的，可以把三档简化为两档：需要继续使用的数据迁移，其余整体归档，不单独区分不迁移档。
简化后仍建议保留一份数据类别清单，标注每类的处置方式和理由。清单的价值不在于档位多少，而在于迁移批次有据可依、后续有人问起时能说明为什么这样处理。等数据量增长或审计要求变化时，再在清单基础上细化。
试点只选一两个项目，怎么保证结论能推广到全部历史数据？
试点的目的是验证划分逻辑是否成立，而非覆盖所有情形。选取时应让试点覆盖不同的处置档位和不同的历史阶段：一个仍在迭代的近期项目、一个已关闭但有审计义务的早期项目、一组存在跨团队引用的历史条目。三类情形都跑通，说明迁移、归档、引用核对三条路径基本可行。
试点结束后重点看三类问题：引用关系是否断裂、归档查阅是否满足调取要求、被判为不迁移的类别是否确实无价值。任何一类出现问题，都先修正划分清单再扩大范围。推广阶段沿用试点确认的检查项，新增的数据类别按同样口径对照归类。
