迁移前是否要清理研发数据，取决于源系统的冗余程度、迁移成本口径和合规约束是否清楚。面对重复项目、僵尸任务和过期附件，更稳妥的做法是先建立分类标准，把对象分为保留迁移、归档留存、删除三类，再决定清理范围；存在争议的对象先归档，不直接删除。
要点总览（TL;DR）
- 迁移前清理值得做的前提是源系统确有重复项目、僵尸任务、过期附件等冗余，且迁移成本与数据量或对象数相关；数据量小、合规与引用关系未摸清时可先按原样迁移。
- 分类标准按四个维度建立：合规保留期与引用关系决定能否删，业务价值与迁移成本决定保留迁移还是归档留存，冲突时合规与引用约束优先。
- 删除需同时满足无合规保留义务、无下游引用、迁移成本高于留存价值三个条件；存在争议的对象一律先归档，不直接删除。
- 执行清理需要导出对象清单与引用关系、业务负责人与法务/合规及迁移负责人三方分工、留出判定复核时间，并保留导出备份或先归档观察作为回退安排。
- 合规保留期未确认、引用关系无法完整导出、业务负责人缺位或迁移窗口紧张时应暂缓或缩小清理范围，可先在有代表性的项目群试点验证标准。
迁移前清理值不值得做：先给条件式结论
迁移前清理值得做，前提是源系统确实积累了可识别的冗余，并且迁移成本与数据量或对象数相关。比如运行多年的项目管理系统中存在多个名称相近的重复项目、长期无人更新的僵尸任务、挂在已结束项目下的过期附件，而迁移按对象数量计费或需要逐项核对，清理就能直接减少迁移对象数和后续核对工作量。
以下情形不必把清理放在迁移之前优先处理：源系统数据量小、迁移成本低，逐项迁移和逐项清理的投入相差不大；合规保留期和引用关系尚未摸清，此时清理的判断成本高于收益；迁移窗口本身很紧，清理与迁移并行会放大误删和返工风险。这些情况下可以先按原样迁移，迁移完成后再在目标系统中做归并和归档。
无论哪种情形，结论都应落到保留迁移、归档留存、删除三分法，而不是只做删除。三分法保留了“暂时判断不了”的中间状态，让清理可以在信息不完整时继续推进，同时避免把有潜在价值的对象直接丢掉。
清理要解决什么问题：冗余数据在迁移中的代价
冗余数据在迁移中的代价，主要体现在迁移后的使用和核对环节，而不只是迁移当次的工作量。重复项目迁移后会变成同一业务对象的多份副本，接收方需要重新判断哪一份是有效版本，再手工合并任务、附件和评审记录。副本越多，合并时的对照成本越高，也越容易把旧版本的内容误当成最新状态。
僵尸任务和过期附件抬高的是迁移工作量与存储占用。每个任务都要经过导出、转换、校验，附件还要处理存储路径和权限继承；这些对象迁移过去后很少被检索，却会占用目标系统的空间，并在搜索、报表和列表视图中形成干扰。迁移后团队查找有效任务时，需要在大量已停用对象中筛选，检索效率随之下降。
引用关系断裂是更隐蔽的代价。任务关联的附件、评审记录关联的任务、文档关联的项目，如果在清理时只删除了其中一端，迁移后就会出现指向空对象的记录。这类问题往往在迁移完成后才被发现，修复时需要回到源系统比对，成本高于迁移前一次性理清。因此清理的价值机制可以表述为：减少迁移对象数、降低迁移后的核对与合并工作量、保持引用链完整，具体收益随源系统冗余程度而变化，不宜事先承诺量化比例。
保留、归档还是删除：四维分类标准
分类标准围绕四个维度建立：业务价值、合规保留期、引用关系、迁移成本。判断顺序建议先看合规与引用约束，这两项决定对象“能不能删”；再看业务价值与迁移成本，决定对象“保留迁移还是归档留存”。下表给出每个维度的判断问题和典型取值。
| 维度 | 判断问题 | 典型取值 | 对分类的影响 |
|---|---|---|---|
| 合规保留期 | 该对象是否属于合同、审计、监管要求保留的研发记录？保留期是否已届满？ | 保留期内、保留期已满、无明确要求 | 保留期内不得删除，只能保留迁移或归档 |
| 引用关系 | 是否有其他任务、文档、外部系统引用该对象？引用方是否也在迁移范围内？ | 被迁移范围内对象引用、仅被外部系统引用、无引用 | 存在有效引用时不得单独删除，需连同引用方一起处理 |
| 业务价值 | 该对象是否仍在被查阅、复用或作为当前工作的依据？ | 活跃使用、历史参考、无使用痕迹 | 活跃使用保留迁移，历史参考倾向归档 |
| 迁移成本 | 迁移该对象需要多少转换、校验和存储投入？留存价值是否高于迁移成本？ | 成本高且价值低、成本与价值相当、成本低 | 成本明显高于留存价值时，在合规与引用允许的前提下可删除 |
三分法的判定规则可以按以下顺序执行：
- 保留迁移：仍在活跃使用，或处于合规保留期内且需要随业务继续可查的对象。重复项目中应只保留一份有效版本，其余副本按归档或删除处理。
- 归档留存：有历史参考价值但不再活跃、合规保留期未满但业务已结束、引用关系暂未理清的对象。归档意味着移出日常迁移范围，但保留可检索、可恢复的状态。
- 删除：同时满足无合规保留义务、无下游引用、迁移成本高于留存价值三个条件的对象。过期附件和确认无用的僵尸任务通常落在此类。
维度之间出现冲突时，合规与引用约束优先于成本考量。一个对象即使迁移成本很高，只要仍在保留期内或被有效引用，就不能以“节省迁移量”为由删除；反过来，成本很低的对象也不因为便宜就一律保留，仍要经过价值判断。存在争议的对象一律先归档，等争议解决后再决定是否删除。
哪些团队和数据适合按此标准清理
这套标准适合源系统运行多年、项目与任务数量大、已经出现明显重复项目和停用对象的团队。典型状态是：同一业务被建了多个项目、任务长期停留在未完成状态、附件挂在已关闭项目下无人清理。数据量越大、迁移按对象数或数据量计费时，清理对迁移范围的控制作用越明显。
有明确合规或审计保留要求的研发数据也适合按此标准处理，因为四维标准把合规保留期放在判断顺序的前端，能在清理阶段就区分“可删”和“必须留”，避免迁移后才发现记录缺失。迁移预算或窗口有限、需要主动缩小迁移范围的团队同样适用。
执行这套标准需要两个团队前提：有业务负责人能够判定对象是否仍有价值，有法务或合规角色能够确认保留期和审计要求。缺少任一角色时，分类判断会退化为按时间或按名称的机械规则，误判风险上升。团队规模、行业和预算不影响标准本身，但会影响清理能投入的人力和时间。
投入与前提：清理需要哪些准备
清理的第一项准备是导出对象清单与引用关系。清单至少包含项目、任务、附件的标识、创建与更新时间、所属项目、当前状态；引用关系要能看出任务与附件、任务与任务、文档与项目之间的指向。没有这份底稿，删除判断只能凭印象，无法复核。
第二项准备是角色分工。业务负责人负责判定业务价值，法务或合规负责确认保留期与审计要求，迁移负责人负责评估迁移成本并执行导出、归档和删除动作。三方对同一批对象给出结论后，再由迁移负责人汇总成分类结果，争议对象提交业务负责人和合规角色共同确认。
第三项准备是时间。清理包含清单整理、逐类判定、争议复核和结果确认，属于需要留出判定与复核周期的项目工作，无法靠一次性脚本完成。迁移排期时应把这段时间单独列出，避免压缩到迁移切换前的最后几天。
第四项准备是可回退安排。删除前保留完整导出备份，或先把对象置为归档状态观察一段时间，确认没有业务方提出恢复需求后再执行删除。归档观察期长度由团队根据业务节奏确定，关键是让删除动作有可追溯、可恢复的路径。
在工具层面，清理依赖对项目、任务、附件和引用关系的集中查看与状态管理。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 迁移可将空间、页面、附件和权限结构迁入 ONES Wiki，迁移前需要确认数据范围、功能匹配和系统适配。团队可以借助迁移前对源系统对象清单的梳理，把保留、归档、删除的判定结果对应到实际迁移范围，再进入正式迁移。
什么情况下应暂缓清理
合规保留期未确认、审计要求不明时，应暂缓删除类操作。此时可以继续做清单整理和归档，但不执行删除；等法务或合规给出明确口径后，再对暂存对象重新判定。把“不确定”当作“可以删”，是清理阶段最常见的风险来源。
引用关系无法完整导出，或对象被外部系统引用时，也应暂缓。外部系统不在本次迁移范围内，其引用关系无法通过源系统清单完整呈现，单独删除可能造成外部系统指向空记录。这类对象先归档，待外部系统负责人确认后再处理。
业务负责人缺位、无人能判定对象价值时暂缓清理。仅凭创建时间或最后更新时间判断僵尸任务，容易把低频但关键的记录误判为无用；缺少业务判断时，清理范围应收缩到明显重复的项目副本和确认过期的附件。
迁移窗口紧张、清理与迁移并行风险高时，先缩小清理范围。可以只处理重复项目和明确过期的附件，把僵尸任务的判定留到迁移完成后在目标系统中进行。缩小范围的目标是保证迁移按期完成，同时不放弃对高风险冗余的处理。
试点判断：先小范围验证分类标准
全量清理前，先选取一个有代表性的项目群或一段时间范围做试点。代表性指该项目群覆盖了主要业务类型、包含重复项目、僵尸任务和过期附件三类对象，并且有业务负责人愿意参与判定。试点范围不宜过大，以能在计划时间内完成全部判定和复核为准。
试点过程中记录三类判定的争议点：哪些对象在“保留还是归档”之间反复、哪些对象因引用关系不清无法定论、哪些删除判断被业务方推翻。这些争议点用于回补分类标准，比如补充某类附件的默认归档规则，或明确某类任务的引用检查范围。
试点通过的判断标准有三条：试点对象全部有明确归类，没有悬而未决的对象；执行归档和删除后没有出现引用断裂；业务方对分类结果认可。三条同时满足，说明标准可执行，可以按同样方法扩大范围；任一条不满足，先调整标准再扩大，避免把试点中的争议带到全量清理。
常见问题
迁移前清理和迁移完成后再清理，应该选哪个？
取决于迁移成本口径和合规约束是否清楚。如果迁移按对象数或数据量计费、源系统冗余明显，迁移前清理能直接缩小迁移范围，减少接收方合并副本和核对记录的工作量。如果源数据量小、迁移成本低，或合规保留期与引用关系尚未摸清，可以先按原样迁移，迁移完成后再在目标系统中做归并和归档。两种顺序的共同前提是保留引用链完整，避免只删一端造成指向空对象的记录。
僵尸任务如何判断，能否只按最后更新时间删除？
不建议只按最后更新时间判断。低频但关键的记录，例如年度审计用的评审记录或长期维护项目的基线任务，更新时间可能很久远但仍有价值。更稳妥的做法是结合业务负责人确认：先由业务负责人判定该任务是否仍被查阅或作为工作依据，再检查是否存在引用关系，最后才评估迁移成本。无法确认价值的任务先归档，等业务方提出恢复需求时再处理。
归档和删除在迁移中有什么区别，归档对象还要不要迁移？
归档意味着移出日常迁移范围，但保留可检索、可恢复的状态；删除则是对象不再保留。归档对象通常不进入本次正式迁移的数据范围，或只迁移索引与元数据，具体取决于团队对历史可查性的要求。执行时应先把对象置为归档状态观察一段时间，确认没有业务方提出恢复需求后再决定是否删除，让删除动作有可追溯、可恢复的路径。
重复项目应该保留哪一份，其余副本怎么处理？
保留仍在活跃使用、或处于合规保留期内且需要随业务继续可查的那一份，其余副本按归档或删除处理。判断哪一份有效时，可以对照任务完成情况、附件更新时间和业务负责人的确认，避免仅凭创建时间选择。副本中如果包含独有附件或评审记录，应先合并到保留版本再处理副本，防止内容随副本一起丢失。
清理需要哪些角色参与，缺少法务或合规角色怎么办？
常规分工是业务负责人判定业务价值，法务或合规确认保留期与审计要求，迁移负责人评估迁移成本并执行导出、归档和删除动作。缺少法务或合规角色时，应暂缓删除类操作，只做清单整理和归档；等合规口径明确后再对暂存对象重新判定。缺少业务负责人时，清理范围收缩到明显重复的项目副本和确认过期的附件，僵尸任务的判定留到迁移完成后进行。
