迁移数据清理可以按“划范围—备输入—定规则—分批执行—核验—设停止条件”六步推进。第一步先确定源系统、目标系统和纳入清理的对象，把范围收敛成一份可管理的清单；随后为每条数据判定保留、清洗、合并、丢弃或暂缓，并在试迁移前用数量对账和抽样比对证明清理按规则执行。清理动作要留下判定依据和责任人，避免在正式切换前临时删改。
要点总览（TL;DR）
- 清理范围先收敛成清单：写清源系统与目标系统版本、纳入对象类型、时间/项目/状态/负责人边界，以及排除项和原因。
- 每条数据只给一个处置结论：保留、清洗、合并、丢弃或暂缓，规则表写明判定条件、处置动作、责任人和依据。
- 执行顺序先主数据后业务对象：用户与组织、项目先行，再处理工作项、文档、附件和评论，按批次记录处理量与处置分布。
- 清理与字段映射要能互相追溯：清洗记录标明适用的映射规则，映射表标注受影响的清理批次，修改前后值留痕。
- 核验用三层证据：数量对账、必填字段完整率与格式检查、按对象抽样比对；发现误判或源系统无备份时暂停并回退。
清理范围怎么划：哪些数据进入迁移清单
清理范围决定后续工作量，也决定哪些数据允许被改动。范围清单要同时写清源系统与目标系统、各自版本、纳入对象类型和边界条件，让参与清理的人对“清理什么”有一致理解。
先记录迁移方向：从哪个源系统、哪个版本迁往哪个目标系统、哪个版本。版本信息影响字段清单的获取方式和导出方式，也影响后续核验时对字段含义的判断。接着列出纳入清理的对象类型，研发数据迁移通常涉及工作项、需求、缺陷、用例、文档、附件、评论、用户与组织等。对象类型不必一次求全，但一旦列入清单，就要对应到具体的导出范围和判定规则。
对象类型确定后，用边界条件把数据量收敛到可管理规模。常用边界包括时间范围（如近三年创建或更新的数据）、项目范围（如纳入迁移的项目清单）、状态范围（如已关闭且长期无更新的数据是否纳入）、负责人范围（如离职人员名下数据的归属处理）。边界条件要写成可判断的条件，例如“2022年1月1日之后创建且所属项目在迁移清单内的工作项”，避免“较新的数据”“重要项目”这类无法执行的描述。
排除项同样要进清单并记录原因。常见排除项包括临时测试项目、已废弃且无审计要求的历史项目、与本次迁移目标无关的附件库、重复导出的中间文件。排除不等于删除，排除项应在源系统中保持原状，只是在本次迁移中不处理。把排除原因写清楚，后续有人质疑“为什么这个项目没迁”时可以直接对照。
| 清单字段 | 填写示例 | 作用 |
|---|---|---|
| 源系统与版本 | 源系统A，版本号待确认 | 确定导出方式与字段口径 |
| 目标系统与版本 | 目标系统B，当前使用版本 | 确定字段承接能力 |
| 纳入对象类型 | 工作项、需求、缺陷、文档、附件、评论、用户、组织 | 确定清理与映射的工作面 |
| 边界条件 | 时间、项目、状态、负责人 | 控制数据量与判定口径 |
| 排除项及原因 | 测试项目、废弃项目、无关附件库 | 留痕，避免重复讨论 |
清理前要准备哪些输入与依赖
清理开始前需要备齐四类输入：字段清单、业务确认、访问权限和规则表模板。缺其中任何一项，清理都容易在中途返工。
字段清单分源端和目标端两份。源端字段清单从源系统的字段配置或导出模板中获取，记录字段名称、类型、是否必填、取值范围；目标端字段清单从目标系统的对应配置中获取。两份清单并排后，才能判断哪些字段可以直接承接、哪些需要清洗格式、哪些在目标端没有对应位置。字段清单的获取方式应写成操作步骤，例如由管理员导出字段配置、由项目负责人确认自定义字段含义，避免只凭记忆整理。
业务负责人对保留口径的确认是清理规则的前提。哪些项目必须完整迁移、哪些历史数据可以只保留摘要、哪些状态需要重新映射，这些判断属于业务决策，应由熟悉项目历史的负责人确认并留下记录。确认方式可以是评审会纪要、邮件回复或规则表上的签字栏，关键是能追溯到具体的人和时间。
导出与只读权限、备份或快照是清理的安全前提。执行清理的人应具备源系统的导出权限，清理过程中对源数据保持只读，改动发生在清理工作副本或目标系统中。源系统在清理前应有可恢复的备份或快照，并记录备份时间点。没有备份或快照时，清理应暂停，先补齐恢复手段。
清理规则表建议包含以下字段，每条规则一行，便于评审和执行：
- 对象：规则适用的对象类型，如工作项、用户、附件。
- 判定条件：可执行的判断语句，如“状态为已关闭且最后更新早于2021年”。
- 处置方式：保留、清洗、合并、丢弃、暂缓之一。
- 责任人：对该条规则判定结果负责的人。
- 依据：业务确认记录、字段清单条目或合规要求。
五类处置规则怎么定：保留、清洗、合并、丢弃、暂缓
五类规则的作用是让每条数据都有唯一结论。规则写法要落到判定条件和处置动作，避免只写方向性描述。下表给出各类规则的判定思路和动作示例，实际条件需结合项目情况调整。
| 处置方式 | 判定条件示例 | 处置动作 | 责任人 |
|---|---|---|---|
| 保留 | 所属项目在迁移清单内，且仍需在目标系统继续跟踪 | 按映射表迁入目标系统，保持字段与关联关系 | 项目负责人确认，迁移执行人操作 |
| 清洗 | 必填字段缺失、日期格式不一致、状态值与目标流程不匹配 | 按字段映射规则补值或转换格式，记录修改前后值 | 字段负责人制定规则，执行人批量处理 |
| 合并 | 同一工作项被重复创建、同一用户存在多个账号、同一项目重复建档 | 确定保留主记录，把关联数据挂到主记录，其余标记为已合并 | 业务负责人指定主记录，执行人操作 |
| 丢弃 | 测试数据、已废弃项目、无业务价值的临时附件 | 不迁入目标系统，在丢弃清单中登记对象标识与原因 | 业务负责人确认，执行人登记 |
| 暂缓 | 归属不清、涉及合规审计、负责人未确认 | 隔离存放，不迁入也不删除，待条件明确后重新判定 | 迁移负责人跟踪，业务负责人裁决 |
保留规则要回答“为什么这条数据还需要在目标系统继续使用”。仍在迭代的项目、有后续维护需求的需求与缺陷、需要留存的评审文档，通常属于保留范围。保留不等于原样复制，字段格式和状态值仍可能需要在映射阶段转换。
清洗规则针对字段层面的问题。常见情况包括必填字段为空、日期与人员字段格式不统一、状态值与目标系统流程不匹配、富文本中残留源系统链接。清洗要写明修正方式：是补默认值、按对照表转换，还是由负责人逐条补充。批量修正前先在小样本上验证，确认转换结果符合预期再扩大范围。
合并规则的关键是确定合并键和主记录。工作项可按“项目+标题+创建时间接近”识别重复，用户可按邮箱或工号识别重复账号，项目可按名称与负责人识别重复建档。主记录的选择标准要事先约定，例如保留创建时间最早、评论最多或业务确认的那条，其余记录标记为已合并并保留指向主记录的关联，便于回溯。
丢弃规则要限定在明确无业务价值的数据上，测试项目、临时验证用的工作项、与迁移目标无关的附件属于常见对象。丢弃清单必须逐条登记对象标识、名称和丢弃原因，不能只写“批量清理测试数据”。暂缓规则用于处理边界不清的情况，涉及合规审计、归属争议或负责人未确认的数据先隔离，等条件明确后再判定，避免在信息不足时做出不可逆决定。
清理怎么执行：分批处理与字段映射的衔接
执行顺序影响清理效率和可回溯性。建议先处理主数据，再处理业务对象：用户与组织先行，保证工作项、评论中的负责人和创建人能够正确对应；项目其次，保证工作项有明确的归属容器；最后处理工作项、文档、附件和评论等业务对象。主数据未稳定时处理业务对象，容易出现负责人找不到、项目归属为空的问题，后续还要返工。
按批次执行并记录批次信息。批次可以按项目、按对象类型或按时间切片划分，每批记录批次号、对象类型、处理量、处置分布（保留、清洗、合并、丢弃、暂缓各多少条）、执行人和执行时间。批次记录的作用是出现问题时能定位到具体范围，而不是全量重来。
清理与字段映射要建立对应关系。同名字段在源端和目标端含义不同时，先由字段负责人确认映射口径，再决定该字段是否需要清洗。例如源端的“优先级”取值为五级，目标端为三级，映射规则要写明哪些值合并、哪些值保留，清理时按同一规则转换。清理结果与映射表应能互相追溯：每条清洗记录标明适用的映射规则编号，映射表也标注该规则影响的清理批次。
执行过程中的变更要留痕。字段值修改、记录合并、状态转换都应记录修改前后值和操作时间，批量操作记录操作脚本或操作说明。留痕的目的不是增加文档负担，而是在核验和回退时能说清“这条数据经历了什么”。在ONES中，迁移准备阶段的清理规则、批次记录和核验结果可以放在项目工作项与文档中承载：规则表作为文档评审，批次执行记录作为工作项逐批更新状态，核验结论附在对应文档中，交接时按同一处记录查看，减少信息散落在个人表格里的情况。
清理结果怎么核验：数量、字段与抽样证据
核验要回答两个问题：清理是否按规则执行，以及有没有误删有效数据。核验证据应能脱离执行人个人记忆被复核。
数量对账是第一层核验。按对象类型统计清理前数量、各处置方式数量、清理后数量，检查“清理前=保留+清洗+合并+丢弃+暂缓”是否成立，合并与丢弃的对象是否在清单中逐条可查。数量差异要能解释到具体批次或具体规则，无法解释的差异暂停后续操作。
字段检查是第二层核验。对保留和清洗后的数据检查必填字段完整率、日期与人员字段格式合规率、状态值是否落在目标系统允许的取值范围内。完整率按对象类型分别统计，低于约定阈值的字段回到清洗规则中补处理。检查结果记录检查口径、样本范围和结果数值。
抽样比对是第三层核验。按对象类型抽取一定数量的记录，逐条比对源系统与目标系统的标题、描述、负责人、状态、附件数量和评论数量，确认内容一致或差异有明确原因。抽样应覆盖不同批次、不同处置方式和不同项目，避免只抽容易处理的数据。丢弃与暂缓清单要逐条复核，确认每条都有判定条件和责任人签字，暂缓项标明重新判定的条件。
核验完成后形成清理核验报告，包含对账表、字段检查结果、抽样记录和签字确认。签字确认由业务负责人和迁移负责人共同完成，确认范围与报告记录的范围一致。
哪些情况要暂停或回退清理
清理过程中出现以下情况应暂停，先处理风险再继续：发现规则误判导致有效数据被丢弃；源系统没有可用备份或快照；业务负责人尚未确认保留口径；数量对账出现无法解释的差异；抽样比对发现内容缺失且原因不明。
误判导致有效数据被丢弃时，立即停止后续批次，从备份或快照恢复受影响数据，或在目标系统中按丢弃清单反向找回并核对关联关系。恢复后重新审视对应规则，修正判定条件，并对同批次已处理数据进行复查。回退路径和责任人要在清理开始前写明：谁有权触发回退、从哪个时间点恢复、恢复后如何通知相关方。
源系统无备份或快照时，清理应暂停在只读盘点阶段，先完成备份再执行任何修改或丢弃动作。业务负责人未确认保留口径时，相关对象进入暂缓，不进入丢弃或合并流程。重新执行清理的前置条件包括：规则已修正并经业务负责人确认、备份可用、上一轮核验差异已解释清楚、回退路径已确认。满足条件后从暂停的批次继续，并在批次记录中注明暂停原因和恢复时间。
常见问题
清理规则由谁拍板，迁移执行人能否自行决定丢弃？
丢弃、合并这类不可逆或影响关联关系的处置，应由熟悉项目历史的业务负责人确认，迁移执行人负责按规则操作和登记。执行人可以提出规则建议，但不宜单方面决定哪些数据不再迁入目标系统。确认记录可以是评审纪要、邮件回复或规则表上的签字栏，关键是能追溯到具体的人和时间。
保留口径同样需要业务确认。哪些项目必须完整迁移、哪些历史数据只保留摘要，属于业务判断，迁移团队凭字段清单无法替代。
源系统还在使用，清理期间有人继续改数据怎么办？
清理期间应对源系统设定数据冻结窗口，或至少记录冻结时间点，后续导出和核验都以该时间点为准。冻结窗口内源系统保持只读，新增和修改延后处理，避免清理清单与源数据不一致。
如果无法完全冻结，需要在批次记录中标注每批数据的导出时间，核验时按同一时间口径对账。冻结窗口的长度和起止时间由迁移负责人与业务方共同确认，并在清理开始前通知相关团队。
暂缓的数据一直确认不下来，会不会拖住正式切换？
暂缓项应设定重新判定的条件和时限，例如“负责人确认归属后重新判定”或“合规评审结论出具后处理”。到达时限仍未明确的，由迁移负责人提交业务负责人裁决：继续暂缓、转为丢弃并登记原因，或缩小范围先行迁移。
暂缓数据隔离存放，不迁入也不删除，因此不阻塞其他批次推进。但正式切换前需要形成暂缓清单的处置结论，避免切换后仍有数据悬空、无人跟踪。
清洗时批量补默认值，怎么避免把错误值写进目标系统？
批量修正前先在小样本上验证转换结果，确认补值或格式转换符合字段负责人确认的口径，再扩大范围。每条清洗记录保留修改前后值，便于核验时抽查。
对含义依赖业务判断的字段，例如优先级、严重程度，不宜用统一默认值填充，应由字段负责人给出对照规则或由负责人逐条补充。数量对账和抽样比对时重点检查这类字段。
清理和字段映射是两件事，先后顺序怎么安排？
两者交替推进：先拿到源端与目标端字段清单，确认同名字段的含义差异，再据此制定清洗规则；清洗执行时按已确认的映射规则转换字段值，清洗记录标明适用的映射规则编号。
映射口径未确认的字段先不批量清洗，相关数据可进入暂缓，等字段负责人确认后再处理。这样清理结果与映射表能互相追溯，核验时也能解释每条数据的字段值来源。
