历史项目跨度多年，从既有研发工具迁出时，把所有数据一次性搬进新系统往往既费钱又制造噪音，全部留在旧系统又会让在研项目断链。取舍的依据来自三类需求的叠加判断：业务连续性、审计追溯与协作引用。本文给出必须迁移、归档保留、不再迁移三类处置的条件框架，并说明投入前提、暂缓情形与试点验证方法。
要点总览（TL;DR）
- 判断顺序固定为三步：先看业务连续性，再看审计追溯，最后看协作引用；任一环节命中，数据就进入迁移或可检索归档范围。
- 在研、交付或运维支持期项目，以及保留期内需举证的合同验收记录、被新项目持续引用的历史需求与缺陷，属于必须迁移范围。
- 已结项且无后续承诺、超出审计年限、无外部引用的数据可以归档；归档需保留可检索入口、基本元数据与原始记录完整性。
- 迁移范围决定成本结构，数据量、附件体积与字段映射复杂度是主要变量；引用关系、审计年限、字段模型未确认时宜缩小首批范围。
- 用在研项目与已结项项目做对照试点，验证引用链接、字段关联与归档可查性，再调整分类边界后推广。
先给结论：历史数据分三类处置
历史项目数据可以按处置方式分为三类：必须迁移、归档保留、不再迁移。判断顺序固定为三步——先看业务连续性，再看审计追溯，最后看协作引用。任一环节命中，数据就进入迁移或可检索归档范围；三类都不满足，才考虑不再迁移。
| 处置类别 | 定义 | 典型对象 |
|---|---|---|
| 必须迁移 | 迁入新工具后仍需保持字段关联、状态可读、链接可用的数据 | 在研或运维期项目的需求、缺陷、任务、迭代记录、相关文档与附件 |
| 归档保留 | 不进入新工具日常协作，但需在保留期内可检索、可举证的数据 | 已结项项目的合同与验收材料、变更记录、缺陷处理记录、结项文档 |
| 不再迁移 | 既无连续性需求，也超出追溯年限、无任何引用的数据 | 早期试验性项目、已废弃分支的临时记录、重复导出的中间文件 |
判断顺序的意义在于避免两种极端：先按业务连续性筛一遍，能快速圈出真正在用的数据；再按审计追溯补上合规要求；最后用协作引用兜底，把被新项目反复引用的历史记录捞回来。同一项目内不同数据可以分属不同类别——在研项目的当前迭代必须迁移，而它多年前的结项附件可能只需归档。
取舍要解决什么问题：连续性、追溯与引用
取舍的本质是在迁移成本与业务风险之间找平衡点。全量迁移和全量归档各自解决一部分问题，也各自带来新的问题。
全量迁移的成本与噪音问题。迁移工作量主要由数据量、附件体积和字段映射复杂度决定。多年积累的历史附件、评论和状态变更记录会显著拉长迁移周期；迁入后，新工具的项目列表、搜索和报表被大量已结束项目占据，团队日常查找在研内容的效率下降。迁移不是一次性动作，迁入数据的字段映射、权限对应和链接修复都需要逐项核对。
全量归档导致在研项目断链的风险。如果按项目结项时间一刀切，把跨年度的项目整体归档，正在被新项目引用的需求编号、缺陷记录和设计文档会失去上下文。开发人员在新工具里查不到旧缺陷的复现过程，只能凭记忆重写，问题定位时间被拉长。
审计追溯对记录完整性的要求。合同、验收、变更审批和客诉处理记录在可查年限内需要保持完整链条：谁在什么时间改了什么、依据是什么。这类记录一旦只保留结论而丢失过程，审计时无法自证。
协作引用对链接与上下文可用性的要求。被新项目需求、缺陷、文档或工单持续引用的历史数据，其价值在于“能被找到并看懂”。迁移或归档时若只保留标题、丢失字段关联和附件，引用就变成死链，协作方仍需回旧系统翻查。
必须迁移的适用条件
满足以下任一条件的数据，应纳入必须迁移范围。条件之间是“或”的关系，命中一条即成立。
- 项目仍在迭代、交付或运维支持期。当前有排期中的需求、待修复缺陷或运维工单，数据迁移后团队要直接在新工具里继续工作。
- 存在合同、验收、合规或客诉追溯要求。保留期内的合同履约记录、验收材料、变更审批和客诉处理过程，需要在新系统中可查、可导出、可举证。
- 被新项目需求、缺陷、文档或工单持续引用。历史需求编号、缺陷单、设计文档被当前工作项链接引用，迁移后这些链接需要保持可解析。
- 迁移后仍需保持字段关联与状态可读。工作项的类型、状态、优先级、关联关系、评论和附件在迁入后要能还原业务含义，而不只是文本搬运。
以从 Jira 迁出的场景为例，ONES 的 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并可迁移问题数据中的属性、属性值、附件与评论，目的是保持研发过程连续。这一范围与“必须迁移”的判定条件相对应：在研项目的状态流转和字段关联是迁移后继续协作的基础。具体迁移范围仍需在正式迁移前逐项确认。
可以归档或不再迁移的条件
同时满足以下条件的历史数据，可以归档保存或不再迁入新工具：项目已结项且无后续迭代与运维承诺；超出审计追溯年限且无合规要求；无外部引用、无协作方持续查询。三个条件需要同时成立，缺一项就应回到上一节的判定。
归档不等于丢弃。归档方案至少要保留三类内容：
- 可检索入口。按项目名称、编号、时间、负责人等基本维度能定位到归档数据，而不是只能整包解压查找。
- 基本元数据。项目起止时间、参与人、关键交付物清单、结项状态，用于判断该批数据是否与当前问题相关。
- 原始记录的完整性。归档包内的附件、评论和状态变更记录保持原样，确保日后审计或引用时能还原过程。
不再迁移的数据也应保留删除或清理的审批记录，说明判断依据和确认人，避免日后出现“数据去哪了”的争议。
投入与前提：迁移范围决定成本结构
取舍结论直接决定投入规模。迁移范围越大，工作量越集中在三个变量上：数据量、附件体积与字段映射复杂度。数据量影响迁移批次和耗时；附件体积影响存储与传输；字段映射复杂度影响核对与返工，旧系统的自定义字段越多、状态流转越复杂，映射规则的设计和验证成本越高。
做出取舍前，需要提前确认以下输入：
| 输入项 | 用途 | 缺失时的后果 |
|---|---|---|
| 项目清单与结项状态 | 划分在研、结项、废弃项目 | 无法确定迁移边界，容易全量迁移 |
| 审计追溯年限与合规要求 | 确定归档保留期与必须迁移的记录范围 | 归档过早，审计时无法举证 |
| 引用关系清单 | 识别被新项目持续引用的历史数据 | 迁移后出现死链，协作方回旧系统翻查 |
| 目标工具字段模型 | 设计字段映射与状态对应规则 | 映射反复调整，迁移返工 |
归档方案本身也需要存储与检索能力支撑：归档数据的存放位置、检索方式、保留期限和访问权限要提前定好，否则归档会退化成“打包压缩后无人能找到”。取舍结论建议由业务、法务与研发共同确认——业务判断连续性，法务确认追溯年限，研发评估映射与实施可行性。ONES 在迁移实践中建议在正式迁移前确认数据范围、功能匹配和系统适配，并将迁移工具、原厂服务与分阶段切换结合，这一做法同样适用于先定取舍、再定实施节奏。
暂缓迁移的情形
以下情形出现时，宜暂缓迁移或先缩小首批范围，而不是按原计划全量推进：
- 引用关系尚未梳理清楚。无法判断哪些历史数据被当前项目引用时，贸然归档可能切断在研工作的上下文。
- 审计追溯年限尚未确认。法务或合规口径未定，归档保留期就没有依据，此时迁移或清理都可能返工。
- 目标工具字段模型尚未定稿。字段映射规则还在调整，迁移后的数据可能需要二次搬迁。
- 归档检索方案未落地。归档数据的存放、检索和权限方案没有确定时，不宜直接丢弃或清理数据。
暂缓不等于停滞。可以先迁移边界清晰的部分，例如在研项目的当前迭代和明确在保留期内的合同验收记录，把引用关系复杂、年限待定的部分留在旧系统只读保存，待信息补齐后再处理。
用试点验证取舍结论
取舍框架是否成立，可以用一个小范围试点来检验。选取一个在研项目和一个已结项项目做对照：在研项目按“必须迁移”处理，已结项项目按“归档保留”处理，观察两类处置的实际效果。
试点需要观察的项包括：
- 迁移后，历史需求、缺陷与文档之间的引用链接是否仍可打开，字段关联和状态是否保持业务含义。
- 在新工具中按项目、时间、负责人检索迁移数据，能否在合理步骤内定位到目标记录。
- 归档数据的检索入口是否可用，基本元数据是否完整，能否支撑一次模拟的审计查询。
- 迁移过程中字段映射的返工次数和附件处理的耗时，用于校准后续批次的成本预估。
试点结束后，根据观察结果调整分类边界：如果发现某类已结项项目仍被频繁引用，就把它从归档类移入迁移类；如果某类在研数据迁移后无人访问，可以重新评估其必要性。取舍结论经过一轮对照验证后再推广到全量范围，比一次性全量迁移更可控。
取舍确定之后，迁移与归档数据还需要有承载日常协作的地方。ONES 的项目、工作项与文档管理能力可以承接迁入的在研数据，让迁移后的需求、缺陷和文档继续被引用和检索；从 Confluence 迁出的空间、页面、附件和权限结构可进入 ONES Wiki，保留原有知识组织方式。归档数据的保留期限与检索能力属于选型阶段需要向厂商确认的事项，宜在试点中一并验证。
常见问题
同一项目里既有在研迭代又有多年以前的结项附件，需要整体迁移吗？
不需要整体迁移。同一项目内不同数据可以分属不同处置类别：当前迭代的需求、缺陷和任务属于必须迁移范围，迁移后团队要直接在新工具里继续工作；多年前的结项附件如果已超出审计追溯年限、无外部引用，可以归档保留。判断时按数据对象逐项过一遍三步顺序，而不是按项目整体一刀切。
归档保存的历史数据，日后被审计或客诉追溯时还能用吗？
可以，前提是归档方案保留了可检索入口、基本元数据和原始记录的完整性。按项目名称、编号、时间、负责人等维度能定位到归档数据，归档包内的附件、评论和状态变更记录保持原样，就能支撑审计查询和客诉追溯。如果归档只是打包压缩后无人能找到，追溯时仍需回旧系统翻查，归档就失去了意义。
审计追溯年限还没和法务确认，能先按计划全量迁移吗？
建议暂缓或先缩小首批范围。审计年限未确认时，归档保留期没有依据，迁移或清理都可能返工。可以先迁移边界清晰的部分，例如在研项目的当前迭代和明确在保留期内的合同验收记录，把年限待定的部分留在旧系统只读保存，待法务口径明确后再处理。
从 Jira 迁出时，历史问题数据里的评论和附件能一起迁走吗？
ONES 的 Jira 数据迁移可迁移问题数据，包括属性和属性值、附件、评论等信息，迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行，目的是保持研发过程连续。具体迁移范围仍需在正式迁移前逐项确认，尤其是自定义字段和复杂状态流转的映射规则。
试点验证要跑多久、看哪些指标才算取舍结论成立？
试点周期取决于项目规模，关键是选一个在研项目和一个已结项项目做对照。观察项包括：迁移后历史需求、缺陷与文档之间的引用链接是否仍可打开，字段关联和状态是否保持业务含义；在新工具中按项目、时间、负责人检索能否快速定位；归档数据的检索入口和元数据能否支撑一次模拟审计查询；字段映射返工次数和附件处理耗时。根据结果调整分类边界后再推广到全量范围。
