从既有研发工具迁出时，历史数据往往横跨多年项目，全部随迁会推高清洗、映射和校验成本，全部留在旧系统又可能让在维护版本和审计追溯断链。判断哪些研发历史数据必须迁移、哪些可以归档，核心看三条：业务连续性、审计追溯、协作引用。划分单位是数据对象而非整个项目，本文按这一口径给出分类清单、适用条件与试点验证方法，并说明ONES在承载工作项、文档与关联关系时的相关能力。
要点总览（TL;DR）
- 判断研发历史数据是否必须迁移，核心看三条：业务连续性、审计追溯、协作引用；满足任一类即应随迁并保持关联。
- 已结项、无合规保留义务、引用频率极低的历史项目可归档留存，保留可检索的摘要与索引，明细留在归档存储。
- 划分单位是数据对象而非整个项目，用“对象+时间窗+状态”三要素界定范围，同一项目内不同对象可分别处置。
- 适合历史项目跨度多年、需承接在维护版本、存在审计或合同追溯要求、且能界定时间窗与状态口径的场景；保留期限未确认或关联无法还原时应暂缓或缩小范围。
- 用跨年历史项目与在维护项目各一个做对照试点，检验关联完整性、检索可用性与审计举证，再据结果调整口径。
先给判断：三类数据必须迁，其余可归档
研发历史数据的迁移范围，建议用“对象+时间窗+状态”三要素来界定，而不是按项目整体一刀切。一个五年前立项、至今仍在维护的项目，其早期结项模块的工单流水可以归档，但在维护版本的缺陷、发布记录和接口文档必须随迁。按项目整体决策，容易把该迁的和该留的绑在一起。
必须迁移的数据，通常同时满足以下三类判据中的至少一类：
- 业务连续性：未完结项目、活跃缺陷、在维护版本的任务，迁出后团队仍要在此基础上继续工作，旧系统关停后这些数据必须在新系统中可用。
- 审计追溯：合规要求、合同约定或质量追溯体系要求保留原始记录，且需要能按需求、缺陷、发布逐级举证。
- 协作引用：需求、代码提交、测试用例、发布记录之间仍被检索和关联，断链会导致排查和变更评估失去依据。
可归档的数据，典型特征是已结项、无合规保留义务、引用频率极低。归档不等于删除，建议保留可检索的摘要与索引，原始明细留在归档存储中，需要时可按索引调取。
| 判断维度 | 必须迁移 | 可归档留存 |
|---|---|---|
| 项目状态 | 未完结、在维护 | 已结项且无后续维护 |
| 数据状态 | 活跃缺陷、待办需求、进行中任务 | 已关闭且长期无变更的工单 |
| 合规要求 | 合同或审计要求保留原始记录 | 无明确保留义务，或已过保留期 |
| 引用频率 | 仍被检索、关联、引用 | 近一两年几乎无访问 |
| 处置方式 | 随迁并保持对象间关联 | 留存摘要与索引，明细归档 |
这张表是判断口径，不是绝对规则。同一项目内不同对象可能落在不同列，实际执行时以对象为单位逐项判定，并对边界模糊的对象保留迁移倾向，避免追溯断链。
为什么按这三条判据划分：迁移与归档各自解决什么问题
迁移解决的是新系统中的可用性与关联完整性。数据迁过去之后，团队要能直接在新系统里查需求、提缺陷、看发布记录，并且需求与提交、测试、发布之间的关联仍然成立。这意味着迁移不只是搬字段，还要把对象之间的关系一起还原，否则数据在、链路断，协作引用这条判据就落空了。
归档解决的是存储成本与合规留存的平衡。多年历史项目的完整工单流水、过期讨论、临时附件体量大、访问少，全部迁入新系统会占用存储、拖慢检索，也增加迁移期间的清洗和校验工作量。把它们留在归档存储中，保留摘要与索引，既满足留存要求，也控制成本。
两类错误各有代价。全量迁移的代价集中在迁移期：数据量越大，字段清洗、映射设计、抽样校验的工作量越大，迁移窗口越长，业务中断风险也越高。全量归档的代价则滞后显现：当审计需要举证某个历史缺陷的处理过程，或维护版本要回溯某次变更的来龙去脉时，发现记录已不在可检索范围内，追溯断链、举证困难，补救成本远高于当初多迁一部分数据。
因此三条判据的作用，是把“可能有用”收窄为“确有必要”，让迁移范围有据可依，也让归档决策经得起事后检验。
逐类数据对象的迁移与归档建议
把判据落到具体对象上，可以形成如下分类清单。清单中的“迁移”指随迁入新系统并保持关联，“归档”指留存摘要与索引、明细留在归档存储。
| 数据对象 | 建议处置 | 判断依据 |
|---|---|---|
| 未完结需求、活跃缺陷、在维护版本任务 | 必须迁移 | 业务连续性，迁出后仍需继续处理 |
| 与在维护版本相关的代码提交记录、合并请求 | 必须迁移并保留关联 | 协作引用，变更追溯依赖提交与工作项的关联 |
| 活跃测试用例、近期执行记录及缺陷关联 | 必须迁移 | 业务连续性与协作引用，回归测试需要历史执行结果 |
| 仍被引用的设计文档、接口文档 | 必须迁移 | 协作引用，文档是当前开发与维护的输入 |
| 在维护版本的发布记录 | 必须迁移 | 业务连续性与审计追溯，发布历史是问题定位的起点 |
| 已结项项目的完整工单流水 | 可归档 | 已结项、引用频率低，保留摘要与索引即可 |
| 过期讨论、临时附件 | 可归档 | 无持续引用价值，留存索引备查 |
| 已下线版本的旧文档 | 可归档 | 无合规义务时归档，有义务则按期限留存 |
几类边界情况需要单独说明。跨版本长期存在的缺陷，即使当前状态为关闭，只要所属版本仍在维护，建议随迁，因为同类问题复现时需要回溯处理记录。测试执行记录建议按时间窗截取，例如保留最近若干个发布周期内的执行明细，更早的只留汇总。文档的处置要看引用关系，被当前需求或接口引用的文档随迁，仅作历史存档的文档归档。
在工具承载层面，ONES的迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，问题数据包括属性和属性值、附件、评论等信息；知识资产方面可将空间、页面、附件和权限结构迁入ONES Wiki，并保留原有知识组织方式。这与上述“对象+关联”的划分思路一致：迁移时按对象范围界定，关联关系随对象一起还原。需要说明的是，迁移后需求—提交—测试—发布关联的具体还原程度，应在方案设计阶段与实施方逐项确认，再据此最终确定迁移范围。
什么条件下值得按此方案执行
这套划分方法适合以下情形，可以逐项核对：
- 历史项目跨度多年，且企业明确存在归档诉求，希望控制新系统的数据体量与检索负担。
- 新系统需要承接在维护版本与未完结工作，迁出后团队要能无缝继续协作。
- 存在审计、合同或质量追溯要求，需要明确哪些记录必须可举证、保留多久。
- 能够界定清晰的时间窗与状态口径，例如以某个日期为界、以版本维护状态为界。
四项中满足前三项、并能给出第四项的口径，按对象划分迁移与归档范围通常比全量迁移更可控。若历史数据量很小、项目数量有限，全量迁移的管理成本可能更低，此时划分的收益不明显，可以直接全量迁移。
投入与前提：迁移前需要准备什么
按对象划分范围，前期投入主要集中在盘点与设计，低估这部分会直接导致迁移期返工。
- 数据盘点与对象清单：梳理旧系统中的项目、工作项、文档、附件数量与分布，形成对象级清单，标注每个对象的项目状态、最后活跃时间和引用情况。这项工作需要业务方参与，单靠IT部门难以判断引用价值。
- 字段映射与关联关系设计：确定旧系统字段到新系统的映射规则，重点设计需求、提交、测试、发布之间的关联如何还原。关联还原方案应在迁移前定稿，迁移中再补设计往往代价更高。
- 归档存储与检索索引方案：明确归档数据存在哪里、以什么形式保留摘要与索引、由谁负责调取。归档方案要保证审计时能按项目、时间、对象类型检索到记录位置。
- 保留期限的确认：由业务方与合规方共同确认各类数据的保留期限，形成书面口径。保留期限未确认前，归档决策应暂缓。
此外，若旧系统存在插件或定制场景，迁移前需要逐项评估，避免假设所有定制逻辑都能一一对应。ONES方案将数据完整、业务连续和系统稳定作为迁移目标，并支持国产化、私有化以及安全合规相关要求，具体合规与部署要求仍需结合企业实际核验。
什么情况下应暂缓或缩小迁移范围
以下触发条件出现时，建议先暂停或缩小范围，而不是按原计划推进：
- 保留义务与期限尚未确认：合规方未给出明确口径时，暂缓归档决策，相关数据先按迁移处理或原地保留，避免归档后无法满足举证要求。
- 关联关系无法在新系统还原：如果需求与提交、测试、发布之间的关联在目标系统中难以建立，先缩小迁移范围，优先迁移关联链路清晰的数据，其余暂留旧系统。
- 在维护版本边界不清：哪些版本仍在维护、哪些已停止支持没有明确结论时，先冻结范围定义，再启动迁移，避免迁到一半发现范围需要重划。
- 预算与人力不足：资源受限时优先保障业务连续性数据，审计追溯类数据按保留期限分批处理，归档类数据整体后置。
暂缓不等于放弃。上述条件多数可以通过补充确认解决，暂缓的价值在于把不确定性挡在迁移窗口之外，减少迁移中途变更范围带来的返工。
如何用小范围试点验证划分是否合理
划分口径是否成立，用一次小范围试点就能检验，成本远低于全量迁移后发现问题。
试点对象建议选两个：一个跨年历史项目，覆盖多个已结项模块和少量仍在维护的内容；一个当前在维护项目，包含活跃缺陷、近期发布和关联文档。前者检验归档边界，后者检验迁移后的可用性。
验证要点包括：
- 关联完整性：迁移后抽查需求与提交、测试用例与缺陷、发布记录与工作项之间的关联是否成立，断链比例是否可接受。
- 检索可用性：在新系统中按项目、时间、状态检索迁移数据，确认常用查询路径可用；对归档数据，确认能通过索引定位到记录并调取明细。
- 审计举证：模拟一次追溯场景，例如从某个发布记录回溯到相关缺陷和处理过程，检验归档数据是否仍能满足举证要求。
- 口径调整：根据试点结果调整时间窗与状态口径，例如把“近两年”改为“近三个发布周期”，或把某类文档从归档移回迁移清单。
试点完成后，把验证结论固化为范围定义文档，作为全量迁移的执行依据。ONES在迁移中按项目、工作项、文档等对象承载数据与关联，试点阶段可以借助这一结构逐项核对对象是否齐全、关联是否成立，再决定全量迁移的最终范围。
常见问题
已结项项目的缺陷记录，只要状态是关闭就可以直接归档吗？
不一定。关闭状态只说明当前没有待处理动作，是否归档还要看所属版本是否仍在维护、是否存在合规保留义务。跨版本长期存在的缺陷，即使已关闭，只要相关版本仍在维护，建议随迁，因为同类问题复现时需要回溯当时的处理记录。判断时把状态、版本维护情况和保留义务放在一起看，比单看状态更稳妥。
归档后的数据还能满足审计举证吗？
取决于归档方案是否保留了可检索的摘要与索引。归档不等于删除，建议保留项目、时间、对象类型等维度的索引，审计时能据此定位到记录并调取明细。如果归档只做冷存储、没有索引，举证时难以快速定位，追溯效率会明显下降。保留期限与调取责任方最好在归档前书面确认。
迁移后需求、提交、测试、发布之间的关联还原不了，该怎么调整范围？
先缩小迁移范围，优先迁移关联链路清晰的数据，其余暂留旧系统，等关联还原方案明确后再处理。ONES的迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，问题数据包括属性和属性值、附件、评论等信息；知识资产可将空间、页面、附件和权限结构迁入ONES Wiki。关联还原的具体程度建议在方案设计阶段与实施方逐项确认，再据此最终确定范围。
历史数据量不大时，还有必要做迁移与归档的划分吗？
收益可能不明显。若历史项目数量有限、数据体量小，全量迁移的管理成本往往低于逐项盘点和分类的成本，此时直接全量迁移更省事。划分方法的价值主要体现在多年跨度、数据量大、存在明确归档诉求的场景，用三条判据把迁移范围收窄，控制清洗、映射和校验的投入。
试点应该选什么样的项目，验证到什么程度算通过？
建议选两个对照对象：一个跨年历史项目，覆盖多个已结项模块和少量仍在维护的内容，用来检验归档边界；一个当前在维护项目，包含活跃缺陷、近期发布和关联文档，用来检验迁移后的可用性。验证通过的标准可以设为：抽查的关联链路断链比例在可接受范围内、常用检索路径可用、模拟追溯场景能完成举证。达不到时调整时间窗与状态口径后重新验证。
