迁移数据清理要解决的是“哪些数据值得带走、带过去以后怎么解释”这两个问题。它发生在正式迁移之前，核心工作包括圈定对象范围、按业务含义建立字段映射、在样本上试清理并核对数量与关键字段，同时保留清理日志和回退点。范围、映射、核验、回退四件事做到位，进入目标系统的数据才可解释、可追溯。
要点总览（TL;DR）
- 迁移数据清理先圈定系统边界、对象类型和保留排除条件，形成一份可执行的对象范围清单，作为映射与核验的基准。
- 字段映射按业务含义对应，不按字段名直接连线；枚举值、状态值单独建对照表，空值与无法映射值分类处置并计数。
- 清理结果用数量对账、关键字段抽样比对和异常清单三类证据核验，配合清理日志与审批记录形成证据链。
- 关键字段映射未获业务确认、丢弃比例超出预设范围、导出不完整或目标约束变更时，应暂停并回到上一批基线重跑。
- 清理规则、映射确认与核验记录需要多人评审时，可用ONES的工作项与文档承载，具体配置按团队实际情况确定。
清理哪些数据：来源、目标与对象范围
清理范围的第一层是系统边界：源系统是什么、目标系统是什么、各自处于什么版本。版本信息直接影响字段清单和取值约束，例如源系统某个状态字段在旧版本中只有三种取值，升级后扩展到五种，清理规则就要按实际导出的版本编写。范围清单中应写明源系统名称与版本、目标系统名称与版本，以及本次迁移对应的环境（测试环境或生产环境）。
第二层是对象类型。研发工具中的数据通常分布在多个对象上：需求、缺陷、任务、用例、附件、评论、历史变更记录等。不同对象的清理难度差异很大——工作项主体字段结构清晰，评论和附件则涉及富文本、文件大小和权限继承。建议在范围清单中逐类列出对象类型，并标注“纳入清理”“仅迁移不清理”“暂不迁移”三种处置，避免清理阶段对评论、附件这类对象反复拉扯。
第三层是保留与排除边界。常见划定维度包括时间（如只迁移近三年数据）、项目（如只迁移在用项目，归档项目单独处理）、状态（如已关闭且无关联的缺陷是否保留）。这些条件需要业务方确认，不能由实施人员单方面决定。边界一旦确定，应写成可执行的判断条件，例如“项目状态为进行中，且最近一次更新时间在约定日期之后”。
还需要划清清理与迁移、验证的边界。清理阶段只负责数据内容层面的取舍、去重、映射和无效对象剔除；工作流与插件行为的迁移、迁移完成后的切换与验收，属于相邻阶段的工作，不在本文展开。把边界写进范围清单，可以避免清理阶段被临时追加需求拖长。
本节的交付物是一份对象范围清单，至少包含五列：对象类型、来源系统与版本、目标系统与版本、保留条件、排除条件。清单经业务方和实施方共同确认后，作为后续映射和核验的基准。
清理前需要准备什么：输入与依赖
清理工作最怕在信息不全时动手。开始之前，需要把输入材料和责任人固定下来，形成一份输入清单与责任人对照表，逐项确认“谁提供、谁确认、什么时候到位”。
第一类输入是源系统数据导出与字段清单。导出应覆盖范围清单中所有纳入清理的对象类型，并记录导出时间、导出方式和记录总数。字段清单要包含字段名称、字段类型、是否必填、取值范围，以及该字段在源系统中的业务含义说明。仅有字段名不足以支撑映射，尤其是自定义字段，往往需要业务方解释其实际用途。
第二类输入是业务方对字段含义的确认人。每个关键字段应指定一名确认人，负责回答“这个字段在业务上代表什么”“哪些取值属于有效状态”。确认人最好来自长期使用源系统的业务团队，而不是仅由IT人员推断。
第三类输入是目标系统的字段、必填项与取值约束。目标系统对字段长度、枚举范围、必填要求都有自己的规定，清理规则必须与这些约束对齐，否则映射完成的数据在导入时仍会失败。目标系统的约束清单应在清理开始前取得，而不是等到试迁移时才发现冲突。
第四类输入是清理规则的责任人与审批方式。每条清理规则（去重规则、空值处理规则、枚举转换规则）都应有明确的提出人和审批人，审批记录保留在协作工具中。规则变更时走同样的审批路径，避免清理执行到一半规则被口头修改。
| 输入项 | 提供方 | 确认方 | 用途 |
|---|---|---|---|
| 源系统数据导出包 | 系统管理员 | 迁移负责人 | 清理与核验的原始底稿 |
| 源系统字段清单及业务含义 | 系统管理员、业务确认人 | 业务负责人 | 建立字段映射表 |
| 目标系统字段与取值约束 | 目标系统管理员 | 迁移负责人 | 校验映射可行性 |
| 保留与排除条件 | 业务负责人 | 项目决策人 | 圈定清理对象 |
| 清理规则及审批记录 | 清理执行人 | 业务负责人 | 规则留痕与变更追溯 |
这些材料齐备后，清理才有可执行的依据。缺少字段业务含义确认时，映射只能靠字段名猜测，这正是后续同名不同义问题的根源。
同名字段含义不同怎么映射：清理与映射方法
字段映射的第一原则是按业务含义对应，而不是按字段名直接连线。源系统的“优先级”和目标系统的“优先级”可能都叫同一个名字，但一个表示业务紧急程度、另一个表示处理顺序，直接对应会把数据语义带偏。正确做法是先为每个源字段写一句业务含义描述，再在目标系统中寻找含义最接近的字段；找不到对应字段时，记录为“无目标字段”，由业务方决定丢弃、合并到备注还是保留在扩展字段中。
枚举值与状态值的转换需要单独建对照表。源系统的状态可能有“待处理、处理中、已解决、已关闭、重新打开”，目标系统的状态集合未必一一对应。对照表应逐值列出源取值、目标取值、转换说明，对无法直接对应的值给出处置方式，例如“重新打开”映射为目标系统的“待处理”并附加标签。状态之外，优先级、严重程度、问题类型等枚举字段同样需要对照表。
重复记录的识别与合并要事先定义规则。常见判据包括：同一项目内标题高度相似、同一外部单号、创建人与创建时间接近。合并规则应说明保留哪条记录、其余记录如何处理（合并评论与附件、标记为重复并关联主记录）。合并动作必须留痕，记录被合并记录的原始标识，便于回溯。
空值、默认值与无法映射值需要分类处置。空值可以按目标系统必填要求填充默认值，也可以保留为空并在核验清单中标注；无法映射的值不能静默丢弃，应进入异常清单，写明源记录标识、字段、原值和无法映射的原因。丢弃记录的比例是后续停止条件的重要输入，因此每一类处置都要有计数。
清理动作留痕是方法的一部分。建议为每条规则记录：规则编号、适用对象、判断条件、执行结果数量、异常数量、执行人和执行时间。规则执行结果可以与字段映射表放在同一份文档中，按对象类型分表维护。规则、映射确认和核验记录需要在团队间评审时，可以借助ONES的工作项与文档承载：把每条清理规则作为工作项跟踪状态，把映射表和核验记录放在文档中评审，评审意见与规则版本一并留存。具体承载方式按团队实际配置确定。
| 源字段 | 源业务含义 | 目标字段 | 转换规则 | 异常处置 |
|---|---|---|---|---|
| 优先级 | 业务紧急程度 | 优先级 | 按枚举对照表转换 | 无对应值时置为默认并标注 |
| 状态 | 处理阶段 | 工作项状态 | 逐值对照，重新打开归入待处理 | 无法对应值进入异常清单 |
| 自定义字段A | 业务方确认的实际用途 | 无直接对应 | 合并至描述或扩展字段 | 由业务方逐条确认 |
| 评论 | 讨论记录 | 评论 | 保留正文，标注原作者 | 富文本格式丢失时记录 |
怎么确认清理结果可用：核验与证据
清理结果是否可用，要用数量和内容两方面证据来判断。总量与分类数量对账是第一道检查：源系统导出的记录总数，应等于保留记录数、排除记录数、合并记录数、丢弃记录数之和；按对象类型分别对账，避免总量吻合但分类错位。对账结果写成表格，每一类给出源数量、清理后数量、差异及差异原因。
关键字段抽样比对是第二道检查。从清理后的数据中按对象类型抽取样本，逐条比对源记录与清理结果在关键字段上的一致性，包括状态、优先级、负责人、关联关系等。抽样应覆盖正常记录、边界记录（如空值、超长文本）和异常记录。发现的差异要记录在抽样差异表中，说明是规则设计问题还是执行错误，并决定修正后重跑还是接受差异。
无法映射与丢弃记录的清单是第三道检查。清单应逐条列出记录标识、对象类型、涉及的字段与原值、处置方式和原因。业务方需要审阅这份清单，确认丢弃范围在可接受之内。清单本身也是后续停止条件的判断依据。
清理日志与审批记录构成证据链。日志记录每条规则的执行时间、执行人、影响记录数和异常数；审批记录证明规则和丢弃清单经过业务确认。两者结合，可以在迁移出现问题时快速定位是清理规则的问题还是迁移执行的问题。核验记录建议与范围清单、映射表放在同一处管理，形成从范围到映射再到核验的完整文档序列。
核验通过的标志是：对账无未解释差异、抽样差异已处理或经业务接受、异常清单已审阅、日志与审批记录齐全。四项齐备后，清理结果才具备进入正式迁移的条件。
哪些情况应暂停或回退：停止条件与回退点
清理阶段需要预设停止条件，遇到以下情况应暂停推进，而不是带着问题继续迁移。
- 关键字段映射无法达成业务确认。例如状态字段的转换规则业务方始终无法认可，继续执行只会把语义偏差带入目标系统。
- 丢弃记录比例超出可接受范围。可接受比例应在清理开始前由业务方设定，超出时说明保留条件过严或源数据质量问题严重，需要重新界定范围。
- 源数据导出不完整或版本不一致。导出记录数与源系统统计不符、字段清单与实际导出字段对不上，都意味着清理底稿不可靠，应重新导出后再执行。
- 目标系统约束发生变更。目标字段或必填要求调整后，原有映射表可能失效，需要重新校验后再继续。
回退点的设置应与清理批次对应。每轮清理执行前保留源数据导出包和上一版映射表、规则表，作为回退基线；清理结果按批次单独存放，不覆盖上一批结果。需要回退时，恢复到基线版本，修正规则后重跑清理，并重新执行对账与抽样核验。回退操作本身也要记录：回退原因、回退到的版本、重跑时间与重跑后的核验结果。
把停止条件和回退方式写进清理方案，并在启动会上与业务方确认，可以避免问题出现时临时决策。清理阶段的目标是让进入迁移的数据可解释、可追溯，宁可暂停一轮，也不要把未确认的映射带入正式迁移。
常见问题
清理阶段发现某类对象既不属于保留范围，也不在排除清单里，怎么处理？
这类边界模糊的对象不要在执行中临时决定。先把对象类型、记录数量和典型样例补充到范围清单，标注为“待确认”，由业务负责人给出保留或排除的判断条件，再纳入清理批次。如果确认时间较长，可以把这类对象单独拆成一个后续批次，先推进已确认部分，避免整轮清理被个别对象卡住。补充确认的结果同样要写入范围清单并保留版本记录。
源系统字段的业务含义只有个别老员工清楚，确认人不到位怎么办？
可以先用现有文档、字段取值分布和实际记录样例整理一份“字段含义初稿”，把每个字段的推测含义、依据和不确定点列出来，再请熟悉业务的同事逐条确认或修正。对于确实无人能确认的字段，按“无目标字段”处理，记录在异常清单中，由业务方决定丢弃或合并到描述字段。不要用字段名猜测含义后直接映射，这类偏差在核验阶段很难被发现。
清理后记录数量对得上，但抽样发现状态值转换错了，需要整批重跑吗？
先判断错误范围。如果只是某一条枚举转换规则写错，且该规则影响的记录可以按规则编号精确定位，可以只对受影响记录修正后重跑，并重新执行这部分的对账与抽样；如果错误涉及多条规则交叉影响、无法清晰界定影响面，建议回到上一批基线整体重跑。无论哪种方式，都要在核验记录中写明错误原因、影响记录数和修正后的复核结果。
业务方对丢弃记录比例的可接受范围迟迟定不下来，清理能先开始吗？
可以先做不涉及丢弃的清理动作，例如字段映射、枚举转换和重复记录识别，这些工作不改变记录总量。丢弃类规则（无效对象剔除、无法映射值处置）先以试算方式统计影响数量，形成“若执行将丢弃多少条、涉及哪些对象”的预估清单，供业务方据此设定可接受比例。比例确认后再正式执行丢弃规则，避免先删后议。
清理规则和映射表在评审中反复修改，怎么保证执行时用的是最终版本？
为规则表和映射表建立版本号，每次评审修改后生成新版本并记录变更内容与确认人，执行时在清理日志中注明所用版本号。评审意见与规则版本一并留存，回退时按版本号恢复对应基线。把规则作为工作项跟踪状态、把映射表放在文档中评审，可以让修改过程和确认记录集中在一处，减少口头传达造成的版本混乱。
