迁移数据清理是在正式迁移前，对源系统中的工作项、字段、附件、链接和用户身份做盘点、判定与处理，形成可执行的清理与映射清单。核心做法是先划定迁移范围，再按“保留、转换、合并、归档、丢弃”分类处理数据，随后建立字段与身份映射表，最后用小批量试迁移验证清理结果，并保留回退点。本文聚焦数据内容本身，流程与插件行为迁移、迁移结果验收不在讨论范围内。
要点总览（TL;DR）
- 迁移数据清理先划定源系统、目标系统与五类数据对象（工作项、字段、附件、链接、用户身份），流程与插件行为、结果验收另行处理。
- 盘点时按项目、时间、状态划定活跃数据，把每条数据归入保留、转换、合并、归档、丢弃五类处置，并记录判定依据与确认人。
- 字段映射表至少包含源字段、目标字段、转换规则、责任人四列；同名字段先核对定义和取值分布，枚举值列出完整对照表。
- 用户身份以邮箱、工号或登录名比对匹配，无法匹配的人员单列清单并指定处理人，避免迁移时静默丢失。
- 清理前保留源数据只读快照作为回退点，用1–2个代表性项目做小批量试迁移，映射错误率或差异超阈值时暂停修正。
迁移数据清理要处理哪些对象与范围
迁移数据清理的第一步是把“迁什么、从哪迁、迁到哪”写清楚。源系统与目标系统的名称、版本、部署方式（云端或本地）需要记录在案，因为不同版本导出的字段结构、附件存储方式和用户标识格式可能不同，清理规则要据此调整。范围清单建议由迁移负责人、源系统管理员和目标系统管理员共同确认，避免后期因理解不一致返工。
纳入清理的数据对象通常包括五类：工作项（含标题、描述、状态、属性值）、字段（系统字段与自定义字段）、附件（含历史版本）、链接与关联关系（父子、依赖、关联事项）、用户身份（账号、用户组、组织归属）。这五类对象在迁移中相互牵连，例如工作项的负责人字段依赖用户身份映射，附件挂在具体工作项下，链接关系决定迁移后能否还原上下文。
需要明确的是，本文讨论的是数据内容的清理与映射，流程配置、插件行为、迁移结果验收与切换管理属于相邻主题，另行处理。范围清单可以按以下结构填写：
| 项目 | 填写内容 | 确认人 |
|---|---|---|
| 源系统及版本 | 系统名称、版本号、部署方式 | 源系统管理员 |
| 目标系统及版本 | 系统名称、版本号、部署方式 | 目标系统管理员 |
| 纳入对象 | 工作项、字段、附件、链接、用户身份 | 迁移负责人 |
| 数据时间范围 | 起止日期，是否含历史归档数据 | 业务负责人 |
| 排除项 | 流程配置、插件行为、验收切换 | 迁移负责人 |
清理前需要准备哪些输入与依赖
清理工作依赖四类输入：源数据导出、字段清单、用户名单和目标系统约束。缺少任何一项，判定规则都难以落地。准备工作应在清理启动前完成，并由责任人签字确认。
源系统数据导出建议生成只读快照，包含工作项全量数据、附件文件包和关联关系表。快照的作用是提供稳定的比对基准，清理过程中所有判定都以快照为准，避免源系统持续变更导致口径漂移。导出时记录导出时间、导出人、数据条数，作为后续核对的依据。
字段字典与自定义字段清单需要覆盖字段名称、字段类型、枚举取值、是否必填、使用范围。自定义字段往往是清理难点，名称相似但含义不同的情况在自建字段较多的系统中很常见。用户与组织身份名单应包含账号、姓名、邮箱、用户组、在职状态，用于后续身份匹配。
目标系统的字段容量与命名约束同样要提前确认，包括字段数量上限、名称长度限制、枚举值规范、必填字段要求。这些约束直接决定哪些源字段可以原样保留、哪些需要转换或合并。责任人分工建议按对象划分：工作项与字段由数据负责人牵头，附件由系统管理员牵头，用户身份由 HR 或 IT 管理员牵头，映射复核由迁移负责人统一把关。
| 输入项 | 内容要求 | 责任人 | 完成标志 |
|---|---|---|---|
| 源数据只读快照 | 工作项、附件、关联关系全量导出 | 源系统管理员 | 快照生成并记录条数 |
| 字段字典 | 系统字段与自定义字段清单 | 数据负责人 | 字段清单评审通过 |
| 用户身份名单 | 账号、姓名、用户组、在职状态 | IT/HR 管理员 | 名单与源系统一致 |
| 目标系统约束 | 字段容量、命名规则、必填要求 | 目标系统管理员 | 约束文档确认 |
如何盘点并判定数据的保留与清理
盘点的目标是把源数据逐类归入五种处置：保留、转换、合并、归档、丢弃。判定规则应事先约定并写入处置判定表，执行时按规则操作，减少逐条临时决策。
划定活跃数据是盘点的起点。可以按项目、时间、状态三个维度组合筛选：近两年有更新的项目、处于进行中或近期关闭状态的工作项优先纳入保留范围；长期无更新且已结项的项目数据可以考虑归档。重复数据的识别可以比对标题、描述相似度和创建时间，同一问题被多次录入的情况在手工登记较多的团队中较常见。测试数据通常带有明显的命名特征（如“test”“测试”“demo”前缀）或集中在特定项目下，识别后列入丢弃清单，丢弃前需业务负责人确认。
附件与历史版本的取舍需要结合业务价值判断：合同、设计稿、验收报告类附件建议保留最新版本并归档历史版本；过程性截图、临时文件可以丢弃。链接与关联关系的保留判断依据迁移后是否仍能还原上下文，跨项目依赖、父子关系、阻塞关系建议保留，指向已废弃工作项的链接可以随工作项一并归档。
| 处置类别 | 适用情形 | 处理动作 |
|---|---|---|
| 保留 | 活跃项目、有效工作项、必要附件 | 原样迁入目标系统 |
| 转换 | 字段类型或枚举值需调整 | 按映射规则转换后迁入 |
| 合并 | 重复录入的工作项或同义字段 | 合并为一条记录后迁入 |
| 归档 | 已结项、低频访问的历史数据 | 迁入归档区或单独存储 |
| 丢弃 | 测试数据、临时文件、无效记录 | 确认后不迁入，保留丢弃清单 |
处置判定表应逐条记录数据对象、判定依据、处置类别、确认人，作为后续试迁移和审计的依据。
同名字段与用户身份如何建立映射
字段映射不能只看名称。同名字段在源系统和目标系统中含义不同是常见情况，例如源系统的“优先级”用数字 1–5 表示，目标系统用“高、中、低”三档枚举；源系统的“状态”包含自定义状态，目标系统只有标准状态集。处理方法是先核对字段定义和取值分布，再决定原样映射、转换映射还是合并映射。
字段映射表建议包含四列：源字段、目标字段、转换规则、责任人。转换规则要写清楚枚举对应关系、空值处理方式、超长文本截断规则。枚举值与状态映射需要列出完整对照表，未覆盖的取值单独标注并指定处理人，避免迁移时出现无法识别的值。
| 源字段 | 目标字段 | 转换规则 | 责任人 |
|---|---|---|---|
| 优先级（1–5） | 优先级（高/中/低） | 1–2→高，3→中，4–5→低 | 数据负责人 |
| 自定义状态“待评审” | 标准状态“待处理” | 按状态对照表转换 | 业务负责人 |
| 负责人（账号） | 负责人（目标账号） | 按身份映射表匹配 | IT 管理员 |
用户身份匹配以源系统用户名单与目标系统账号目录比对为基础，匹配依据可以是邮箱、工号或登录名。无法匹配的人员应单列清单，注明原因（离职、账号变更、外部协作人员），由责任人决定是创建新账号、映射到公共账号还是标记为未分配。映射结果需要复核：字段映射由数据负责人复核，身份映射由 IT 管理员复核，复核记录与映射表一并留存。
在目标系统侧，ONES 的工作项与字段管理可以承载映射后的字段结构和用户归属。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、附件和历史记录，并包括用户、用户组和系统配置的迁移，字段配置与权限配置也在迁移范围内。这些能力说明映射结果有对应的承载位置，具体映射冲突的处理方式需在迁移前与实施方确认。
用小批量试迁移验证清理与映射结果
试迁移的目的是在正式迁移前暴露清理判定和映射规则中的问题。样本量建议覆盖主要项目类型、全部自定义字段和各类处置类别，通常选取 1–2 个代表性项目、数百条工作项即可发现大部分结构性问题。样本应包含边界情况：空值字段、超长描述、多版本附件、无法匹配的用户。
试迁移执行步骤可以按以下顺序进行：从只读快照中抽取样本数据，按处置判定表执行清理，按字段映射表和身份映射表转换，导入目标系统测试环境，逐项比对。比对项包括字段值是否一致、附件是否完整可打开、链接关系是否还原、人员归属是否正确。
差异记录要可追溯到具体数据对象，记录源对象标识、差异类型、期望值、实际值、处理责任人。差异分为两类：映射规则错误需要修正映射表后重新试迁移；数据本身问题需要回到处置判定环节调整。证据留存方式建议包括试迁移前后的数据截图、比对记录表、修正清单，统一存放在迁移项目文档中，供正式迁移前复查。
清理阶段的回退点与停止条件
清理过程中需要设置明确的回退点和停止条件，防止错误扩散到正式迁移。回退点首先是清理前的源数据只读快照，快照生成后不再修改，任何清理操作都在副本上进行。第二个回退点是试迁移前的映射表版本，映射表每次修改保留版本记录，便于回退到上一版规则。
停止条件应事先约定并量化。常见触发条件包括：试迁移比对中映射错误率超过预设阈值（例如字段值不一致比例超过 5%）、无法匹配的用户身份数量超过可接受范围、附件缺失或损坏数量异常。触发停止条件后，暂停后续清理和迁移步骤，由迁移负责人组织分析原因，修正映射规则或补充数据后重新试迁移。
无法匹配身份或字段的处理路径需要提前明确：身份无法匹配时，先由 IT 管理员核实账号状态，确认无法匹配的走人工指定或公共账号方案；字段无法映射时，由数据负责人评估是否新增目标字段、合并到现有字段或归档处理。回退操作执行后需做恢复确认，核对快照数据条数、附件数量和映射表版本，确认恢复到预期状态后再继续。
| 回退点/停止条件 | 触发时机 | 处理动作 | 确认人 |
|---|---|---|---|
| 源数据只读快照 | 清理启动前 | 快照生成并锁定 | 源系统管理员 |
| 映射表版本记录 | 每次映射修改 | 保留版本，可回退 | 数据负责人 |
| 映射错误率超阈值 | 试迁移比对后 | 暂停，修正规则后重试 | 迁移负责人 |
| 身份无法匹配超范围 | 身份映射复核时 | 单列清单，人工处理 | IT 管理员 |
回退与停止机制的价值在于把问题控制在清理阶段，正式迁移启动前所有差异都应有明确的处理结论和责任人签字。
常见问题
源系统在清理期间仍在更新，快照和实际数据对不上怎么办？
清理期间以只读快照为唯一判定基准，所有处置判定、映射核对和试迁移都基于快照执行。源系统的持续更新不进入本次清理范围，可在正式迁移前再做一次增量比对，把快照之后新增或变更的数据单独列出，按同一套处置规则补判。快照的导出时间、导出人和数据条数要记录在案，作为后续核对的依据。
测试数据和重复数据可以直接丢弃吗？
丢弃前需要业务负责人逐项确认。测试数据通常有命名特征或集中在特定项目下，重复数据可通过标题、描述相似度和创建时间比对识别，但两类数据都可能混有真实记录，例如测试项目中沉淀的验收结论。建议把拟丢弃清单连同识别依据一并提交确认，确认后保留清单备查，不迁入目标系统。
同名字段含义不同，是改目标字段还是转换源数据？
先核对两边的字段定义和取值分布，再决定路径。目标系统字段容量和命名约束允许时，可以为含义不同的源字段新建目标字段，保留原始语义；目标字段数量受限或语义接近时，用转换规则把源取值映射到目标枚举，并列出完整对照表。两种方式都要写进字段映射表，注明转换规则和责任人，未覆盖的取值单独标注处理人。
无法匹配的用户身份，迁移后会变成什么状态？
无法匹配的人员应单列清单，注明原因（离职、账号变更、外部协作人员），由IT管理员决定创建新账号、映射到公共账号还是标记为未分配。这一步要在试迁移前完成，避免试迁移比对时把身份问题误判为字段问题。ONES 的 Jira 迁移方案包括用户、用户组和系统配置的迁移，具体匹配失败的处理方式需在迁移前与实施方确认。
试迁移发现差异后，应该改映射表还是改清理判定？
按差异类型分流：字段值转换错误、枚举对应错误属于映射规则问题，修正映射表后重新试迁移；数据本身不该迁入或应归入其他处置类别，属于清理判定问题，回到处置判定表调整。两类修正都要更新版本记录，并在比对记录中写明源对象标识、期望值、实际值和责任人，便于正式迁移前复查。
清理阶段暂停后，如何确认已经恢复到预期状态？
回退操作执行后做恢复确认：核对快照数据条数、附件数量与映射表版本，确认与回退点一致，再继续后续步骤。映射表每次修改保留版本记录，可回退到上一版规则；源数据只读快照生成后不再修改，清理操作都在副本上进行。恢复确认的结果由迁移负责人签字，作为重新启动清理的前提。
