迁移数据清单应在迁移项目立项或启动阶段就开始建立，最迟不晚于迁移范围确认之前。清单在启动阶段是粗粒度的范围清单，随调研和映射设计逐步细化到字段级。如果等到映射设计或试迁移时才补建，范围反复和返工的概率会明显上升。下面按阶段说明清单该建到什么程度，以及哪些项目可以简化。
要点总览（TL;DR）
- 迁移数据清单应在立项或启动阶段建立初版，最迟不晚于迁移范围确认之前；启动阶段允许粗粒度，但需覆盖全部候选对象。
- 清单随阶段逐步细化：启动阶段列对象类别，范围确认前形成对象级基线，映射设计阶段细化到字段级，试迁移前形成可核对的完整版本。
- 涉及多系统多团队、历史数据量大、含附件评论等非结构化内容、有合规留痕要求或迁移窗口紧的项目，提前建清单回报明确。
- 单一项目、数据量小、仅迁少量标准字段或源系统即将停用的场景，可先用最小记录推进，试迁移后再补全。
- 清单是否够用可通过一个代表性项目的小样本试迁移验证，按实际暴露的缺失条目回补，再决定细化程度。
先给结论：清单从启动阶段开始，随阶段逐步细化
迁移数据清单的建立时机与迁移项目的阶段划分直接对应。合理的做法是在立项或启动会上就把清单作为交付物之一确定下来，由业务方和工具管理员共同维护，之后每个阶段只做细化，不重新起盘。
各阶段的清单粒度可以按下面的时间线推进：
| 阶段 | 清单粒度 | 主要产出 | 责任角色 |
|---|---|---|---|
| 立项/启动 | 迁移对象类别，如项目、工作项、文档空间、附件、用户与权限 | 初版范围清单，标注迁与不迁 | 项目负责人、业务方代表 |
| 范围确认前 | 对象级清单，明确每个系统、每个项目、每类数据的迁移归属 | 可评审的范围基线 | 业务方、工具管理员 |
| 映射设计 | 字段级清单，含源字段、目标字段、转换规则、必填与可选 | 映射表与差异说明 | 工具管理员、实施人员 |
| 试迁移前 | 可核对的完整版本，含数量口径、异常类型、验收标准 | 迁移核对表 | 项目负责人、验证人员 |
需要说明的是，清单不是一次成型再冻结的文档。启动阶段的清单允许粗，但必须覆盖全部候选对象，让“迁什么”这件事有讨论基础；后续细化是在这个基础上增加字段、规则和数量口径。反过来，如果启动阶段只列了几个明显的大系统，遗漏的对象往往要到试迁移才暴露，此时调整范围会牵动排期和人力。
清单要解决什么问题：把迁移范围变成可核对的对象
清单的核心作用是把口头共识变成可逐项核对的条目。迁移项目最常见的争议集中在三处：某个项目到底迁不迁、某个字段迁过去怎么处理、迁移完成以什么为准。清单在启动阶段就把这三类问题摆到台面上，后续讨论有共同参照。
具体来说，清单承担四项功能：
- 界定迁移对象与不迁对象。清单同时记录“迁”和“不迁”两类条目，并写明不迁的原因，例如历史项目已归档、数据无保留价值、目标系统无对应载体。只列迁移项而不列排除项，后期容易出现“当时说好不迁”的口头争议。
- 支撑工作量与人力估算。对象数量、字段数量、附件体量是估算迁移工时的基础输入。启动阶段有了对象级清单，才能判断需要投入几名实施人员、是否需要分批切换。
- 作为映射设计和验收的共同依据。映射设计以清单中的对象和字段为输入，验收以清单中的条目为核对范围。两者共用一份清单，可以避免设计与验收各说各话。
- 减少后期范围争议与返工。范围变更在迁移项目中难以完全避免，但有清单时，每次变更都能定位到具体条目，评估影响后再决定是否纳入，而不是整体推倒重来。
从管理动作看，清单本身是一组需要持续维护的工作项或文档条目。ONES 的项目与工作项管理可以承载这类清单：把每个迁移对象建成条目，标注负责人、状态和核对结果，范围变更时更新条目状态即可留痕。这一衔接适用于需要多人协同维护清单的迁移项目，规模很小的迁移用表格也能完成。
什么情况下值得在启动阶段就投入建清单
提前建清单需要投入业务方和工具管理员的时间，并非所有迁移都值得按完整流程推进。出现以下一种或多种情况时，启动阶段投入建清单的回报比较明确：
- 涉及多系统、多团队的数据迁移。例如同时从项目管理工具和知识库工具迁移，或多个事业部各自维护项目空间。对象分散在多个来源时，没有统一清单就无法判断覆盖是否完整。
- 历史数据量大、结构复杂。项目数量多、字段自定义程度高、状态流转规则各异，意味着映射关系复杂。清单越早建立，字段级差异越早暴露。
- 存在附件、评论、状态历史等非结构化内容。这类内容的迁移判断比结构化字段更依赖逐项确认，例如哪些附件需要保留、评论是否随工作项迁移、状态历史是否保留。清单需要为这些内容单列条目。
- 有合规或审计要求需留痕。迁移范围、数据处置方式、验收结论需要可追溯时，清单本身就是留痕材料，应在启动阶段纳入项目文档体系。
- 迁移窗口紧、返工代价高。切换时间固定、停机窗口有限的项目，试迁移阶段才发现范围遗漏往往来不及补救，前期清单投入相当于提前排雷。
可以用一个简单判断：如果迁移对象需要两个以上角色分别确认，或者迁移结果需要向业务方逐项交代，就值得在启动阶段建立清单。
投入与前提：建清单需要哪些人和信息
清单的质量取决于输入是否齐全。启动阶段建清单不需要等到所有细节清楚，但以下几项前提需要具备，否则清单容易流于形式。
| 投入项 | 具体内容 | 缺失时的后果 |
|---|---|---|
| 参与角色 | 业务方代表负责确认对象归属与保留价值；IT 或工具管理员负责提供系统信息与导出能力 | 清单只反映单方视角，范围确认时反复 |
| 源系统信息 | 可导出的对象类型、字段清单、附件与评论的存储方式、数据量级 | 无法判断迁移可行性与工作量 |
| 目标系统与范围边界 | 迁移到哪个系统、哪些模块承接、哪些能力暂不覆盖 | 清单缺少对照基准，映射设计阶段才发现无对应载体 |
| 维护机制 | 指定清单责任人，约定更新节奏，例如每周同步一次或每个阶段评审前更新 | 清单建立后无人维护，逐渐与实际脱节 |
其中维护机制最容易被忽略。清单的价值来自持续更新，启动阶段指定一名责任人或一个小组负责汇总变更，比清单初始版本有多详细更重要。更新节奏可以与项目例会绑定，每次范围有调整时同步更新条目，并在评审时以清单版本作为讨论依据。
如果源系统仍在活跃使用，清单还需要记录一个时间口径：以哪个时间点的数据为准。迁移期间新增的数据是随迁、补迁还是留在原系统，应在清单中标注处理方式，避免切换后出现数据缺口。
哪些情况可以暂缓或简化清单
清单投入应与迁移风险匹配。以下情况可以暂缓完整清单，或先用简化版本推进：
- 单一项目、数据量很小的迁移。例如一个团队从表格工具迁移到新系统，对象数量有限，用一页表格列出项目和字段即可，不必建立分阶段的完整清单体系。
- 仅迁移少量结构化字段。迁移范围限于标题、负责人、状态等标准字段，且目标系统有直接对应关系时，映射关系简单，清单可以合并到映射表中一并维护。
- 源系统即将停用、以快速切换为主。时间压力大于精细化需求时，可以先确定必须保留的最小数据集，快速完成切换，历史数据另行归档，不纳入在线迁移范围。
- 可先做小样本试迁移再补全清单。数据来源清晰、异常类型可预期时，用一个小样本跑通流程，再根据实际暴露的问题补全清单，比前期全面盘点更经济。
简化不等于不建清单。即使暂缓完整版本，也应保留一份最小记录：迁移哪些对象、不迁哪些对象、验收由谁确认。这份最小记录可以在试迁移后扩展为完整清单。判断标准可以归纳为：迁移失败或遗漏造成的业务影响是否可接受。影响有限且可快速补救的，简化处理；影响涉及合规、对外交付或大量历史数据的，按完整清单推进。
试点判断：用小样本验证清单是否够用
清单是否完整，靠评审讨论难以完全确认，用一次小样本试迁移验证更可靠。试点选在映射设计基本完成、正式迁移尚未启动的时间点，目的是检验清单能否支撑实际操作。
试点可以按以下步骤推进：
- 选取一个代表性项目做样本迁移。样本应包含典型字段、至少一个附件、若干评论和状态历史，覆盖清单中标注的主要对象类型。避免只选结构最简单的项目，那样验证不出问题。
- 按清单逐项核对实际数据。迁移完成后，对照清单检查每个对象是否到位、字段值是否正确、附件与评论是否完整。核对过程本身就在检验清单条目是否可操作。
- 记录缺失字段与异常类型并回补清单。试点中发现的未列条目、口径不清的字段、无法迁移的内容，逐条补入清单，并标注处理结论：纳入迁移、改为归档或确认放弃。
- 以试点结果决定清单细化程度。如果试点暴露的问题集中在少数对象类型，清单在这些类型上继续细化到字段级；如果整体覆盖良好，清单可以停留在对象级，把字段细节交给映射表管理。
试点结束后，清单应形成一份可核对的完整版本，作为正式迁移和验收的依据。此后清单进入变更管理：新增条目需要说明原因和影响，删除条目需要记录处置方式。这样清单在项目全程保持有效，而不是启动时建一份、验收时再对不上。
ONES 的迁移实践也强调在正式迁移前确认数据范围、功能匹配和系统适配，这与用试点验证清单完整性的思路一致。对于从 Jira 或 Confluence 迁移的场景，ONES 的迁移范围覆盖项目、工作项、状态、字段、附件、评论、页面与权限结构等对象，清单可以把这些对象类型作为核对维度的起点，再结合自身系统的实际情况增补条目。
常见问题
迁移数据清单和映射表是什么关系，需要各维护一份吗？
两者是不同粒度的东西，可以衔接使用。清单回答“迁什么、不迁什么”，以对象为条目；映射表回答“字段怎么对应、怎么转换”，以字段为条目。启动阶段先建清单，映射设计阶段以清单中的对象为输入展开字段映射。规模较小的迁移可以把两者合并到一张表里维护，对象多、字段复杂时分开更清晰，清单作为范围基线，映射表作为设计文档。
项目已经进入映射设计阶段，现在补建清单还来得及吗？
来得及，但需要调整做法。此时不必从零重走启动阶段流程，可以先用现有映射表反推对象级清单，补齐“迁与不迁”的条目和排除原因，再对照源系统导出信息检查是否有遗漏对象。补建的重点是范围覆盖是否完整，而非重新细化字段。补建完成后应尽快安排一次小样本试迁移，验证清单能否支撑核对，避免带着范围缺口进入正式迁移。
清单建好后由谁维护，更新频率怎么定？
建议指定一名清单责任人负责汇总变更，业务方代表确认对象归属与保留价值，工具管理员提供系统信息。更新节奏可以绑定项目例会：每次范围有调整时同步更新条目，每个阶段评审前以清单当前版本作为讨论依据。清单的价值来自持续维护，初始版本多详细是次要的。若源系统仍在活跃使用，还需在清单中标注数据截止时间口径，明确迁移期间新增数据的处理方式。
清单需要记录“不迁移”的对象吗？
需要。只列迁移项而不列排除项，后期容易出现“当时说好不迁”的口头争议。清单应同时记录不迁对象及原因，例如历史项目已归档、数据无保留价值、目标系统无对应载体。排除条目同样是范围基线的一部分，验收时据此说明哪些内容不在本次迁移范围内。范围变更时，新增或删除条目都应记录原因和处置方式。
从 Jira 或 Confluence 迁移时，清单可以按哪些对象类型起步？
可以把迁移方案覆盖的对象类型作为核对维度的起点。据 ONES 官方资料，Jira 迁移涉及项目、工作项、状态、字段、流程、附件、评论与历史记录，以及用户、用户组和权限配置等；Confluence 迁移涉及空间、页面、附件、图片、常用宏、批注与权限结构。清单可先按这些类型列出条目，再结合自身系统的实际使用情况增补，例如自定义字段、插件相关内容和归档数据。具体迁移范围以实际方案确认为准。
