迁移数据清单应在迁移项目立项、完成初步范围确认后立即开始建立，通常落在迁移准备阶段的前段，与现状盘点同步启动，并在数据映射阶段持续细化。它的作用是把“要迁什么、迁到什么程度、由谁确认”提前变成可核对的对象清单。是否值得在早期投入，取决于迁移范围是否跨系统、数据量是否可观、是否存在多团队共用的历史数据；小范围试点或几乎不带历史数据时，可以先用简化清单，随范围扩大再补齐。
要点总览（TL;DR）
- 迁移数据清单应在项目立项、完成初步范围确认后立即建立，与现状盘点同步启动，并在数据映射阶段持续细化。
- 清单的价值在于把迁移对象、范围边界、字段与附件缺口、责任人确认提前变成可逐行核对的条目，为试迁移和验收提供对照依据。
- 跨系统或跨团队迁移、历史数据量大且关联复杂、存在多人共用数据、有合规或审计留痕要求的项目，适合早建清单。
- 小范围试点、数据不带历史、源系统结构简单的项目可先用最小字段的简化清单，随范围扩大再补齐。
- 用一类对象做小样本试迁，核对清单能否记录实际缺口，据此确定正式迁移前的清单基线。
先给结论：清单从哪个阶段开始
迁移数据清单的建立时点，应放在项目立项与初步范围确认之后、现状盘点启动之时。这个位置对应迁移项目的准备阶段前段：此时迁移目标已经明确，源系统和目标系统的大致边界已经划定，但字段映射、数据清洗和试迁移尚未展开。清单在这个时点建立，能够承接范围确认的结论，又能在后续映射工作中持续补充。
把清单与现状盘点同步启动，是为了让盘点有记录载体。盘点过程中发现的每个项目、每类工作项、每批附件、每组权限关系，都可以直接落到清单行上，避免盘点结论停留在会议记录或个人笔记里。进入数据映射阶段后，清单继续细化：补充源字段与目标字段的对应关系、转换规则、责任人确认状态，直到形成可执行的迁移对象台账。
不同迁移规模下，启动时点可以有所差异，但差异体现在清单颗粒度，而非是否建立。下表给出对照：
| 迁移情形 | 清单启动时点 | 清单颗粒度 | 更新节奏 |
|---|---|---|---|
| 跨系统、多团队共用数据 | 立项与范围确认后立即启动 | 按对象类型细分到字段、附件、关联关系与权限 | 盘点期每周更新，映射期随评审更新 |
| 单系统内迁移、对象类型有限 | 范围确认后、盘点开始时启动 | 按对象类型列出范围、数量与责任人 | 盘点结束前完成首版，映射期补充 |
| 小范围试点、几乎不带历史数据 | 试迁移前建立最小清单 | 只列对象类型、样本范围与验收人 | 试点结束后按结果补齐 |
需要说明的是，清单建立时点早于详细映射，并不意味着清单一开始就要写全。首版清单的任务是圈定对象和范围，字段映射、转换规则等内容在映射阶段逐步填入，这样既保证早期有可核对的范围基线，也避免在信息不足时做过度设计。
清单解决什么问题：迁移中的价值机制
迁移项目最常见的返工，来自范围认知不一致：业务方以为某批历史项目会迁，实施方按当前活跃项目估算工作量，试迁移时才发现附件缺失、字段对不上、某些数据无人认领。清单的价值在于把这些分歧提前变成可逐行核对的条目，让范围、缺口和责任在正式迁移前暴露。
具体来看，清单承担四类动作：
- 明确迁移对象与范围边界。清单按对象类型列出迁移内容，例如项目、工作项、状态、字段、流程、附件和历史记录，并标注哪些在范围内、哪些明确不迁。范围边界写清楚，后续工作量估算和验收口径才有共同基础。
- 暴露字段、附件、关联关系的缺口。盘点时逐项核对源系统中的字段是否有目标端承接位置、附件是否完整可读、工作项之间的关联关系是否需要保留。缺口在清单上标记出来，才能在映射阶段安排转换规则或与业务方确认取舍。
- 形成责任人与确认记录。每一类数据指定归属人，由其确认数据范围、清洗规则和验收标准。确认记录留在清单上，后续出现争议时有据可查，也便于交接。
- 为试迁移和验收提供对照依据。试迁移选取的样本、核对的结果、发现的问题，都可以回写到清单，形成“计划—试迁—修正”的闭环。正式迁移验收时，清单就是逐项核对的底稿。
这些动作共同指向一个结果：迁移项目从依赖个人经验推进，转为依赖可核对的对象台账推进。清单本身不解决技术映射问题，但它让技术映射有明确的输入和验收对象。
哪些项目适合早建清单
早建清单需要投入业务方和数据归属人的时间，因此适合在以下条件同时或部分成立时采用。条件越多，早期投入的回报越明显。
- 跨系统或跨团队迁移。数据从多个源系统汇入，或迁移涉及多个业务团队的共用数据时，范围分歧的概率高，清单是统一口径的必要工具。
- 历史数据量大、关联复杂。项目、工作项、附件、评论、权限之间存在多层关联，靠口头盘点难以覆盖，需要清单逐类登记并核对关联完整性。
- 存在多人共用的项目与知识数据。共用数据往往归属不清，迁移时容易出现“谁都以为别人负责”的情况，清单上的责任人字段可以提前锁定确认人。
- 有合规或审计留痕要求。迁移范围、数据取舍、确认过程需要留痕时，清单本身就是可追溯的记录载体。
如果项目只涉及单一系统、对象类型少、数据归属清晰，早建完整清单的边际价值有限，可以按下一节的简化方式处理。判断的关键不是项目大小，而是范围分歧和数据关联复杂度是否足以让“先盘点、再迁移”成为必要步骤。
早建清单要投入什么
清单是一份需要持续维护的工作文档，早期投入主要包括人员、信息和方法三个方面。把这些投入提前纳入计划，清单才不会变成立项时建、映射时荒废的形式文件。
人员投入。需要业务方参与范围确认，需要各类数据归属人确认自己负责的数据范围和清洗规则，还需要一名清单维护责任人负责汇总、更新和推动确认。维护责任人通常由迁移项目的协调角色担任，职责是保持清单状态与实际进展一致。
信息前提。建立清单前需要先摸清源系统的对象结构：有哪些对象类型、各自的关键字段、附件和关联关系的存储方式、权限模型的大致形态。对象结构不清楚时，清单只能列出粗粒度范围，细化工作要等盘点推进后再补。
方法约定。清单需要固定字段，例如对象类型、数据范围、数量估算、源端位置、目标端承接、责任人、确认状态、备注。字段固定后，更新节奏也要约定：盘点期按周更新，映射期随评审更新，试迁移后集中回写。缺少固定字段和节奏，清单很快会因口径不一而失去核对价值。
这些投入在项目早期看起来增加了工作量，实际是把后续试迁移和验收阶段的核对成本前移。投入规模应与迁移范围匹配，范围越大、关联越复杂，越需要完整的字段和稳定的维护机制。
什么情况下可以暂缓或简化
早建完整清单并非所有迁移项目的必要动作。以下情形可以暂缓细化，先用简化清单控制范围，待条件成熟再补齐。
- 小范围试点、数据不带历史。只迁移少量活跃项目、不涉及历史记录时，清单可以只列对象类型、样本范围和验收人，试迁移后再决定是否扩展。
- 源系统结构简单、对象类型少。对象类型有限、字段对应关系直观时，盘点工作量小，清单可以合并为一张范围表，不必按对象类型分表维护。
- 迁移范围尚未确定。范围仍在讨论时，先建立最小字段的清单，记录已确认的对象和待定事项，避免在范围未定时投入大量细化工作。范围确认后，再按正式字段补齐。
暂缓细化不等于不建清单。即使是最简形式，也应保留对象类型、范围边界、责任人和确认状态这几个最小字段，否则试迁移阶段仍会回到范围不清的老问题。简化的判断标准是：当前清单能否支撑试迁移选样和验收核对，能支撑即可暂不扩展。
用一次试点验证清单是否够用
清单字段和颗粒度是否合适，靠讨论难以定论，用一次小样本试迁移验证更直接。试点验证的目标是确认清单能否覆盖实际迁移中出现的缺口，并据此调整正式迁移前的清单基线。
可按以下步骤执行：
- 选一类对象做小样本试迁。选择关联关系较有代表性的一类对象，例如带附件和评论的工作项，抽取少量样本执行迁移。样本应包含正常数据和边界数据，例如字段为空、附件较大、关联跨项目的情况。
- 核对清单字段是否覆盖实际缺口。试迁过程中记录每个问题：字段无承接位置、附件缺失、关联关系断裂、权限未对应。逐条对照清单，检查现有字段能否记录和跟踪这类问题。
- 根据试迁结果调整颗粒度。如果问题集中在字段映射，清单需要增加源字段与目标字段的对应列；如果问题集中在附件和关联，清单需要按对象细分附件与关联的核对项；如果问题集中在责任确认，清单需要强化确认状态和确认人字段。
- 确定正式迁移前的清单基线。试迁结束后，把调整后的字段、对象范围和确认状态固化为基线版本，作为正式迁移的执行依据。基线确定后，后续变更走确认流程，避免范围在迁移过程中反复漂移。
试点的判断标准可以归纳为三条：试迁中发现的问题能否在清单上找到对应记录位置；清单上的确认状态能否反映真实进度；验收时能否按清单逐项核对。三条都满足，说明清单颗粒度足以支撑正式迁移；有任一条不满足，应在正式迁移前补齐字段或调整范围划分。
在清单的日常维护中，如果迁移项目涉及多团队协作、需要跟踪每类数据的确认状态和责任人，可以把清单转为结构化的工作项或表格记录，在项目管理工具中分配责任人、设置状态和更新提醒。ONES 的项目与工作项管理可以承载这类清单的登记、分派和状态跟踪，让盘点、映射、试迁移各阶段的确认记录留在同一处，便于交接和验收核对。工具承载的是管理动作，清单字段和颗粒度仍需按本文的试点方法结合项目实际确定。
常见问题
迁移范围还没最终确定，清单要不要先建？
可以先建一份最小清单，记录已确认的对象类型、范围边界、责任人和确认状态，把待定事项单独标注。范围确认后再按正式字段补齐，这样既保留可核对的范围基线，也避免在信息不足时做大量细化工作。
清单由谁维护比较合适？
通常由迁移项目的协调角色担任清单维护责任人，负责汇总更新、推动各类数据归属人确认。业务方确认范围与取舍，数据归属人确认自己负责的数据范围和清洗规则。维护人选的判断标准是能跨团队推动确认，并保持清单状态与实际进展一致。
清单建好后，范围在迁移过程中发生变化怎么办？
试迁结束后固化的清单基线作为正式迁移的执行依据，后续变更走确认流程，由责任人和业务方共同确认后再更新清单。变更记录留在清单上，避免范围在迁移过程中反复漂移，也便于验收时追溯取舍依据。
清单字段要细到什么程度才算够用？
可以用三条标准判断：试迁中发现的问题能否在清单上找到对应记录位置；清单上的确认状态能否反映真实进度；验收时能否按清单逐项核对。三条都满足，说明颗粒度足以支撑正式迁移；有任一条不满足，应在正式迁移前补齐字段或调整范围划分。
清单和迁移方案文档是什么关系？
清单是迁移方案的范围与对象底稿，方案中的迁移步骤、映射规则和验收标准以清单列出的对象和缺口为输入。两者可以分开维护，但清单更新后应同步反映到方案中，避免方案描述的范围与实际核对的对象不一致。
