迁移数据清单要作为受控台账来维护：先固定字段结构和唯一标识，再明确清单负责人与条目责任人，把新增、修改、冻结、作废纳入固定变更流程，并在准备、试迁移、切换前分别做一次全量复核。本文给出一套可直接套用的字段表、角色分工、变更步骤和完成检查标准，适用于研发工具迁移中的数据范围管理。
要点总览（TL;DR）
- 迁移数据清单按受控台账维护：先固定记录粒度、必填字段、唯一标识和版本号规则，让每次修改都落在同一条可识别记录上。
- 清单负责人维护结构与版本，条目责任人确认本条数据的范围与数量，业务与系统侧确认人在准备阶段和切换前分别参与确认。
- 单次变更走固定路径：变更提出、影响评估、修改与复核、版本发布与通知，变更记录写明原因、影响范围和确认人。
- 在准备、试迁移、切换前三个节点各做一次全量复核，用源系统抽样比对和迁移结果回填校验清单准确性，切换前冻结清单。
- 整份清单可交付的标准是必填项无空缺、每条数据有责任人并已确认、变更可追溯、冻结版本与试迁移结果一致、豁免与作废条目有说明。
清单先定结构：一条数据记录要写清哪些字段
清单的更新之所以容易失控，通常源于记录单元不统一：有人按系统记一行，有人按项目记一行，后续合并时口径对不上。建议先确定记录粒度，再固定字段，让每一次修改都落在同一条可识别的记录上。
记录粒度按迁移对象类型分层：项目、工作项、字段配置、附件、用户与用户组、知识页面等各设一类记录；同一类下数量大、迁移方式可能不同的数据，再拆到批次或项目维度。粒度确定后不再随意调整，新增对象类型走变更流程。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 唯一标识 | 对象类型缩写加序号，全清单不重复 | ISS-012 |
| 数据对象 | 具体到对象类型与范围描述 | 订单项目的工作项及属性值 |
| 来源系统 | 系统名称与实例 | Jira 生产实例 |
| 目标系统 | 接收系统与空间/项目 | ONES Project 订单项目 |
| 数量或范围 | 可核对的数字或明确筛选条件 | 约 1.2 万条，2022 年后创建 |
| 责任人 | 能确认本条数据范围的人 | 业务侧张工 |
| 迁移批次 | 对应试迁移或正式切换批次 | 批次二（试迁移） |
| 状态 | 从固定取值中选择 | 已确认 |
| 版本号 | 本条记录最近一次变更后的版本 | v3 |
| 备注 | 豁免原因、依赖关系等说明 | 依赖附件迁移先行 |
状态取值建议统一为：待确认、已确认、迁移中、已迁移、豁免、作废。状态只能按流程向前流转，回退需在变更记录中写明原因。版本号按条目独立递增，整份清单另设发布版本号，两者配合使用，既能追溯单条变化，也能定位某次发布的整体快照。
谁负责更新：清单负责人与条目责任人的分工
清单无人更新和多头修改是同一问题的两面，解决办法是把“维护结构”和“确认内容”拆给不同角色。清单负责人对整份台账负责，条目责任人对本条数据的准确性负责，两者都不替代业务与系统侧的最终确认。
| 角色 | 主要职责 | 关键动作 |
|---|---|---|
| 清单负责人 | 维护字段结构与版本 | 汇总变更申请、审核修改、发布新版本、通知相关方 |
| 条目责任人 | 确认本条数据范围与数量 | 核对筛选条件、确认迁移方式、在变更中签字确认 |
| 业务确认人 | 确认业务口径 | 在准备阶段和切换前确认范围是否符合业务预期 |
| 系统侧确认人 | 确认技术可行性 | 评估字段映射、附件与权限等依赖，参与影响评估 |
参与时点要写进流程：条目责任人从清单建立时即介入，业务确认人在准备阶段复核和切换前冻结时各确认一次，系统侧确认人在影响评估环节给出技术意见。变更申请由提出人提交给清单负责人登记，再转交条目责任人确认，确认结果回到清单负责人处统一修改和发布，避免提出人直接改表造成版本混乱。人员交接时，原责任人需在变更记录中注明接替人及交接范围，新责任人确认后才算完成交接。
更新与维护的操作步骤：从变更提出到版本发布
单次变更走同一条路径，步骤固定后，清单的每次修改都有输入、动作、输出和可判断的完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 变更提出 | 发现范围偏差、新增对象或数据变化 | 填写变更原因、涉及条目和期望结果 | 变更申请单 | 清单负责人已登记编号 |
| 影响评估 | 变更申请单 | 关联受影响批次、依赖数据和迁移脚本，判断是否影响已完成的试迁移 | 影响范围说明 | 系统侧确认人给出意见 |
| 修改与复核 | 影响范围说明 | 条目责任人核对数量与范围，清单负责人审核字段填写 | 修改后的条目 | 条目责任人确认，清单负责人审核通过 |
| 版本发布 | 审核通过的条目 | 更新条目版本号与清单发布版本号，写入变更记录 | 新版本清单与变更记录 | 变更记录含原因、影响范围和确认人，已通知相关方 |
版本发布要同时给出生效时间，涉及试迁移批次的变更需说明是否重跑。定期维护节奏按迁移阶段设定：准备阶段每周汇总一次变更，试迁移期间每轮迁移后核对一次，临近切换改为每日检查待确认和迁移中状态的条目。频率服务于发现偏差的速度，阶段推进后及时调整。
当清单条目多、参与方分散时，变更记录本身也需要一个稳定的承载位置。ONES 可作为承载条目、责任人与变更记录的协作空间，把条目状态和确认过程留在同一处，减少多份表格并行带来的口径差异；具体字段模板与流程仍需按本文方法自行设定。
三个节点各做一次复核：准备、试迁移、切换前
日常变更解决单条记录的准确性，全量复核解决整份清单与源系统的一致性。三个节点的复核重点不同，方法都以源系统抽样比对和迁移结果回填为主。
准备阶段检查字段完整性与责任人确认情况：必填项是否有空缺，每条记录是否已指定责任人并完成首次确认，状态为待确认的条目是否都有明确的确认计划。这一阶段可用源系统按对象类型导出数量，与清单填写的数量做初步比对。
试迁移阶段用抽样比对校验数量与范围描述：从源系统按清单筛选条件抽取样本，核对实际条数与清单数量是否在可解释的偏差内；对已迁移部分，用迁移结果回填清单的“已迁移”状态和实际条数，偏差条目回到变更流程处理。
切换前冻结清单，确认豁免与作废条目均有说明和确认人，冻结版本与最近一轮试迁移结果一致。冻结后新增变更需走加急审批，并在切换记录中单独列出。
复核记录留痕方式：每轮复核形成一份复核记录，写明复核时间、复核人、抽样方法和结论，与对应清单版本号关联保存。复核发现的问题逐条登记处理结果，未关闭的问题不带入下一节点。
示例：一张订单数据条目的清单更新记录
以下为演示情景，用于说明一条记录如何被修改、复核并留下版本痕迹。
初始条目：唯一标识 ISS-012，数据对象为订单项目的工作项及属性值，来源系统为 Jira 生产实例，目标系统为 ONES Project 订单项目，数量约 1.2 万条（2022 年后创建），责任人为业务侧张工，迁移批次为批次二，状态为已确认，版本 v1。
一次范围调整：试迁移抽样发现 2021 年创建的历史工单仍被业务引用，条目责任人提出将范围扩大到 2021 年后创建，预计增加约 3000 条。变更原因记为“业务追溯需要”，影响评估确认该调整涉及批次二的范围和一条字段映射脚本，不影响已完成的其他批次。
复核与确认：条目责任人核对源系统筛选结果，确认新增数量为 2860 条；系统侧确认人确认字段映射无需调整；清单负责人审核后更新数量与范围描述，条目版本升至 v2，清单发布版本同步更新，变更记录写明原因、影响范围和两位确认人。
更新后的条目在试迁移回填时记录实际迁移条数，与清单数量比对一致后状态改为已迁移。整条记录从 v1 到 v2 的变化、确认人和依据均可追溯，后续复核以此版本为基准。
完成检查：清单可以交付迁移执行的标准
整份清单是否达到可交付状态，按以下条目逐项核对，全部满足才进入下一阶段。
- 必填字段无空缺，唯一标识无重复，状态取值均在约定范围内。
- 每条数据均有明确责任人，且已完成确认，待确认条目为零或有明确处理计划。
- 变更记录可追溯到原因、影响范围和确认人，条目版本号与变更次数一致。
- 冻结版本与最近一轮试迁移结果一致，偏差条目已处理或登记。
- 豁免与作废条目均有原因说明和确认人，未混入待迁移范围。
- 复核记录与对应清单版本关联保存，未关闭问题已列出并约定处理时点。
这份检查清单针对整份台账的交付状态，单次变更的完成标志在变更流程中判断，两者配合使用，可让清单在迁移执行期间保持可信。
常见问题
迁移数据清单的条目粒度定好后，中途发现需要新增一类数据对象怎么办？
新增对象类型属于结构性变更，按变更流程处理：由提出人说明新增原因和涉及范围，清单负责人评估对字段结构的影响，确认新类型是否需要补充字段或调整唯一标识前缀，再统一发布新版本。已有条目保持原标识不变，新增类型从新序号开始编号，避免与历史记录混淆。
条目责任人离职或换岗，清单里的确认记录还有效吗？
原责任人已完成的确认记录保留，作为历史依据；交接时原责任人在变更记录中注明接替人和交接范围，新责任人复核本条数据的范围与数量并确认后，才算完成交接。切换前冻结复核时，应重点检查近期发生责任人变更的条目，确认新责任人已完成确认。
试迁移后发现清单数量与源系统实际条数有偏差，应该改清单还是改迁移脚本？
先判断偏差来源。若源系统筛选条件本身写错或范围描述不准确，修改清单条目并走变更流程；若清单描述正确而迁移过程漏数，问题在迁移执行侧，清单数量保持不变，把偏差登记为待处理问题并跟踪脚本修正。两种情况都要在复核记录中写明抽样方法、偏差数量和结论，避免下一轮复核重复排查。
清单冻结后，切换前又发现遗漏的数据范围，还能改吗？
可以改，但要走加急审批：说明遗漏原因、影响的数据条目和批次，由条目责任人和系统侧确认人快速确认，清单负责人发布冻结后的补充版本，并在切换记录中单独列出。补充条目应明确是否纳入本次切换，未纳入的登记为后续批次处理，避免冻结版本与执行范围脱节。
清单条目很多时，用什么方式承载条目、责任人和变更记录比较合适？
关键是让条目状态、责任人和确认过程留在同一处，减少多份表格并行造成的口径差异。ONES 可作为承载条目、责任人与变更记录的协作空间，其 Jira 迁移方案覆盖项目、工作项、字段配置、附件和历史记录等数据对象，Confluence 迁移覆盖空间、页面、附件和权限结构，可作为清单中数据对象分类的参照。具体字段模板和变更流程仍需按本文方法自行设定。
