历史项目跨度多年，迁移时最容易出现的两种做法是全量搬走和一刀切丢弃。更稳妥的判断方式是先看数据在新工具中是否仍被读取、被引用或被审计要求覆盖，再据此分成必须迁移、归档保留、停止迁移三类。本文按这一口径说明取舍依据、前提条件和暂缓信号，适用于从既有研发工具迁出的场景。
要点总览（TL;DR）
- 历史项目数据按“必须迁移、归档保留、停止迁移”三类处理，判断顺序是先看审计追溯的硬性要求，再看业务连续性，最后看协作引用是否会被继续打开。
- 仍在迭代或维护的项目数据、未关闭的审计事项、被新项目持续引用的提交与评审记录、跨项目依赖与版本关联，通常应纳入迁移范围。
- 已结项且无活跃引用的项目数据适合归档保留，归档需同时满足可检索、可导出、保留期限与审计要求对齐三项条件，归档不等于删除。
- 源系统字段完整度、目标系统对历史数据的承载方式、盘点与映射人力、业务冻结窗口是迁移前必须确认的四项前提。
- 源数据质量差、审计口径未明确、迁移成本高于使用价值或试点未通过时，应暂缓或缩小迁移范围，先用覆盖三类数据的试点验证取舍判断。
先给结论：历史数据分三类处理
历史项目数据的取舍结论是有条件的：当数据仍支撑活跃业务、仍处于审计覆盖期、或仍被其他项目与文档引用时，应纳入迁移；当数据已无活跃使用但存在留存义务或未来查阅可能时，应归档保留；当数据既无使用需求、也无留存义务、引用链已经断开时，可以停止迁移。三类划分按“审计追溯—业务连续性—协作引用”的顺序判断，先排除硬性约束，再评估实际使用。
三类数据对应的典型对象可以先用一张表对照，具体判断方法在后文展开。
| 类别 | 典型数据对象 | 判断要点 |
|---|---|---|
| 必须迁移 | 在维护项目的需求、缺陷、任务；未关闭的审计事项；被持续引用的提交、变更与评审记录；跨项目依赖与版本关联 | 新工具中仍有流程读取、审计要求覆盖或引用链会继续打开 |
| 归档保留 | 已结项且无活跃引用的项目数据、历史文档、旧版本记录 | 当前不常用，但需保留可检索、可导出能力以备查阅或审计 |
| 停止迁移 | 重复导入的临时数据、无业务含义的测试数据、引用链已断且无留存义务的记录 | 无使用需求、无留存义务、无引用关系 |
这个结论成立的前提是：源系统能够导出所需字段，目标系统对历史数据有明确的承载方式，且审计要求的时间范围已经确认。三项前提中任何一项未确认，划分结果都只能作为初步方案，需要在试点中修正。
取舍依据从哪三个需求来
三条需求要转化成可以逐条回答的判断问题，才能落到具体数据对象上。业务连续性问的是“新工具中是否还有活跃流程依赖这条数据”；审计追溯问的是“合规与内审要求覆盖哪些时间范围和对象”；协作引用问的是“需求、缺陷、提交、文档之间的引用链是否还会被继续打开”。三个问题分别对应不同的数据范围，回答完再合并。
业务连续性：看活跃流程是否依赖
判断方法是沿着当前在跑的项目和迭代往下查：这条需求是否还在排期，这个缺陷是否还会被修复，这个任务是否还挂在未完成的版本上。仍在迭代或维护中的项目，其需求、缺陷、任务属于活跃数据，迁移后要能继续流转状态、关联版本。已结项项目的同类数据则要看是否还有维护窗口。
审计追溯：先确认覆盖范围
审计追溯是硬约束，需要先向合规或内审确认两件事：覆盖的时间范围，例如近三年还是全部历史；覆盖的对象，例如变更记录、审批记录、发布记录。确认之后，落在范围内的记录无论项目新旧都应保留，且保留方式要满足可查询、可导出的要求。范围未明确时，不宜先按“项目太老”做删除判断。
协作引用：检查引用链是否会被打开
研发数据的特点是相互引用：一个缺陷关联一次提交，一次提交关联一个评审，评审又写在文档里。判断时抽取部分新项目，看它们是否引用了历史项目的提交、变更或文档。只要引用链会被继续打开，被引用的那一端就需要可访问，迁移或归档都要保证链接可达。
三个需求冲突时怎么排
冲突常见于“业务上已不用、但审计要求保留”的数据。处理顺序是先满足审计追溯的硬性要求，再评估业务连续性的实际影响，最后处理协作引用的可达性。审计要求属于外部约束，不能靠内部评估豁免；业务连续性和协作引用则可以通过归档加检索的方式折中，不必全部迁入活跃库。
哪些数据通常必须迁移
必须迁移的对象有一个共同特征：迁移后仍会被读取、被流转或被追溯。以下四类数据在多数从既有研发工具迁出的场景中应优先纳入迁移范围。
- 仍在迭代或维护中的项目及其需求、缺陷、任务。这些数据要承接后续的排期、状态流转和版本发布，迁移后需保持字段、状态和关联关系可用。判断标志是项目仍有排期或在维护窗口内。
- 未关闭的审计事项与合规要求覆盖的记录。包括尚未闭环的审批、变更和发布记录。判断标志是审计范围明确覆盖且事项未关闭，这类数据迁移后要能按时间、对象检索。
- 被新项目或文档持续引用的提交、变更与评审记录。判断标志是抽取新项目时能查到指向历史记录的链接。迁移时要保证引用关系不断裂，否则新项目中的追溯会中断。
- 跨项目依赖与版本关联数据。多个项目共享的组件版本、依赖关系、发布批次，一旦拆散会导致版本追溯失真，应随活跃项目一并迁移。
这四类对象的数量通常远小于全部历史数据，但承载了迁移后最主要的日常读取和追溯需求，取舍时应优先保障其字段完整度和关联关系。
哪些数据适合归档保留
归档保留适用于“当前不常用、但不能丢”的数据。典型对象是已结项且无活跃引用的项目数据，包括旧项目的需求与缺陷记录、历史文档、已下线版本的变更记录。这类数据迁入活跃库会占用日常检索空间，直接停止迁移又可能违反留存要求，归档是折中方式。
归档需要满足三项要求，缺一项就不能算合格的归档：
- 可检索。能按项目、时间、关键词找到目标记录，而不是只能整包导出后再人工翻找。
- 可导出。审计或法务需要时能导出原始记录，格式和字段保持可读。
- 期限对应审计要求。归档保留期限应与审计覆盖范围对齐，审计要求覆盖多久，归档就至少保留多久；期限未确认前，按较长的可能范围预留。
需要明确归档与删除的边界：归档是保留数据并降低日常可见性，删除是数据不再存在。对于审计范围内的记录，归档可以替代迁入活跃库，但不能替代保留本身。归档方案设计时要把“谁能查、怎么查、多久后可处置”写清楚，避免归档库变成无人维护的黑箱。
在归档与引用链管理环节，ONES 的迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并将 Confluence 空间、页面、附件和权限结构迁入 ONES Wiki，保留原有知识组织方式；其迁移目标包含数据完整与业务连续，并支持国产化、私有化及安全合规相关要求，具体适配范围需按企业环境确认。这些能力可用于承接需要保留检索与引用关系的历史数据，归档策略仍需结合自身审计口径确定。
投入与前提：迁移前要确认什么
取舍判断本身不消耗太多资源，真正需要投入的是把判断落到可执行范围上。迁移前应确认以下四项，任何一项缺失都会让三类划分停留在纸面。
源系统的导出范围与字段完整度
先盘点源系统能导出哪些对象、哪些字段，特别是状态变更历史、评论、附件、关联关系这类容易被忽略的内容。字段缺失会直接影响“必须迁移”对象的可用性，例如缺陷缺少状态历史，迁移后追溯就断了。盘点结果应形成对象与字段的清单，作为映射确认的输入。
目标系统对历史数据的承载方式
确认目标系统对活跃数据和历史数据分别怎么承载：活跃项目进入日常空间，历史项目是否有独立的归档空间或标记方式，检索入口是否覆盖归档数据。承载方式决定了归档类数据是“迁入但降级可见”，还是“留在独立归档库”，两种做法对检索和导出的要求不同。
人力投入：盘点、映射确认、抽样核对
需要预留三类人力：数据盘点由熟悉业务的人判断对象归属；映射确认由了解两侧系统的人核对字段对应关系；抽样核对由使用方验证迁移后数据是否可读可用。三项工作可以并行，但都需要在正式迁移前完成，不能压缩成迁移后的一次性检查。
时间窗口与业务冻结安排
历史数据迁移通常与活跃数据切换分开安排。需要确认迁移期间哪些项目暂停写入、冻结多长时间、冻结期内新产生的数据如何补迁。时间窗口应与业务节奏错开，例如避开版本发布期，冻结安排要提前通知到使用方。
什么情况下应暂缓或缩小迁移范围
暂缓不是放弃，而是在条件不成熟时避免把问题带进新系统。出现以下信号时，应缩小范围或推迟全量迁移。
- 源数据质量差、字段缺失严重。当关键对象缺少状态历史、关联关系大面积断裂时，先迁移字段完整的活跃项目，缺失部分单独评估是补录还是归档，避免把脏数据整体搬入。
- 审计要求尚未明确。覆盖范围和对象未确认前，对边界模糊的历史数据先保留在原系统或归档库，不做删除判断，待口径明确后再定去留。
- 迁移成本明显高于继续使用价值。当某批历史数据的整理、映射、核对成本超过其未来被读取的预期时，可将其降级为归档或暂留原系统，把资源集中在活跃数据和审计范围内数据上。
- 试点未通过。引用链断裂、归档不可检索、审计记录不可追溯等问题在试点中暴露且未解决时，不扩大迁移范围。
缩小范围的常见做法是先迁活跃项目与审计范围内记录，历史项目整体归档，待试点验证后再决定是否补充迁移。这个顺序把风险控制在可回退的范围内。
用试点验证取舍判断
三类划分是否成立，靠一个小范围样本检验比靠讨论更可靠。试点样本应覆盖三类数据：一个仍在维护的活跃项目、一个已结项的旧项目、一批处于审计范围内的记录。三类样本分别对应业务连续性、归档检索和审计追溯三条判断线。
试点要验证三个问题：
- 引用链是否完整。从新项目的需求或缺陷出发，能否沿着关联找到迁移后的提交、变更和评审记录，链接不断、内容可读。
- 归档是否可检索。用项目名、时间、关键词检索归档数据，能否定位到具体记录并导出。
- 审计记录是否可追溯。按审计要求的时间范围和对象查询，能否还原变更与审批过程。
试点结果反馈到全量取舍的方式是修正边界：如果活跃项目的引用链在迁移后断裂，说明关联数据的迁移范围需要扩大；如果归档数据检索不到，说明归档承载方式需要调整或该类数据应改为迁移；如果审计记录无法还原，说明字段映射或保留方式存在缺口。试点通过的标准是三个问题都能给出肯定答案，且抽样核对中未发现影响使用的字段缺失。未通过时，先修正方案再扩大范围，不带着已知缺口做全量迁移。
常见问题
审计要求覆盖的时间范围还没确认，历史数据应该先迁还是先留？
在审计口径明确前，对边界模糊的历史数据宜先保留在原系统或归档库，暂不做删除判断。审计追溯属于外部硬约束，覆盖范围可能比内部预估更长，先按“保留”处理，待合规或内审确认时间范围和对象后，再决定哪些迁入活跃库、哪些继续归档。
这段时间可以并行推进其他准备工作，例如盘点源系统字段、确认目标系统承载方式，不必等审计结论出来才启动。
已结项多年的项目，数据量很大但偶尔还会被查到，怎么处理比较合适？
这类数据适合归档保留，判断关键不是数据量，而是它是否仍被活跃流程读取、是否处于审计覆盖期、引用链是否还会被打开。如果只是偶尔查阅，归档并保证可检索、可导出即可，不必全部迁入活跃库占用日常检索空间。
需要确认的是归档后的检索入口是否覆盖这批数据，以及保留期限是否与审计要求对齐。若审计要求覆盖这些年份，归档可以替代迁入活跃库，但不能替代保留本身。
三个判断需求出现冲突时，有没有固定的优先级？
常见冲突是业务上已不再使用、但审计要求保留。处理顺序是先满足审计追溯的硬性要求，再评估业务连续性的实际影响，最后处理协作引用的可达性。审计要求来自外部约束，不能靠内部评估豁免；业务连续性和协作引用则可以通过归档加检索的方式折中，不必全部迁入活跃库。
如果审计范围本身尚未确认，应把这类数据先按保留处理，避免在口径明确前做出不可逆的删除决定。
试点应该选哪些数据，验证到什么程度才算通过？
试点样本宜覆盖三类数据：一个仍在维护的活跃项目、一个已结项的旧项目、一批处于审计范围内的记录，分别对应业务连续性、归档检索和审计追溯三条判断线。
验证三个问题：从新项目的需求或缺陷出发能否沿关联找到迁移后的提交、变更与评审记录；用项目名、时间、关键词能否检索到归档数据并导出；按审计要求的时间范围和对象查询能否还原变更与审批过程。三个问题都能给出肯定答案，且抽样核对未发现影响使用的字段缺失，才算通过。未通过时先修正方案，再扩大迁移范围。
决定迁移后，源系统字段缺失严重怎么办？
先区分对象处理：字段完整的活跃项目和审计范围内记录优先迁移，缺失严重的部分单独评估是补录、归档还是暂留原系统，避免把不完整数据整体搬入新系统后影响追溯。
盘点阶段应把状态变更历史、评论、附件、关联关系这类容易缺失的内容列入清单，作为映射确认的输入。若缺失集中在某类对象上，也可以据此调整该类数据的取舍结论，把“必须迁移”降级为“归档保留”。
