迁移验收清单的价值在于持续维护，而非一次性填完。把清单交给明确负责人，在每个阶段更新条目，为每项绑定可核验的证据与通过标准，并记录版本和阻断项状态，才能让清单在准备、试迁移、切换和观察期真正约束迁移质量。下文给出一套可直接使用的检查表和维护机制。
要点总览（TL;DR）
- 清单Owner负责版本与条目结构，数据、测试、业务验收各域负责人负责本域条目内容与证据，四类角色在清单上承担不同的勾选与签字责任。
- 在迁移方案定稿、试迁移结束、正式切换前、切换后观察期结束四个时点更新条目，每次更新记录变更人、时间、原因和影响条目。
- 每个检查项绑定可观察的通过标准与证据形式，证据按阶段、条目编号和日期命名，统一存放在迁移项目的指定位置。
- 阻断项未关闭不得进入下一阶段；整体完成条件是全部阻断项关闭、非阻断项有明确处理计划、观察期遗留问题已登记。
- 迁移结束后清单转为常规检查表，按季度或系统重大变更触发复核，并与迁移复盘和问题台账联动更新条目。
谁在什么时点更新这份清单
清单要有人负责、有人使用、有固定更新时点，否则条目会停留在方案定稿时的状态，无法反映试迁移暴露的问题和切换前的实际风险。建议在迁移启动会上就确定清单Owner，并把各域条目的维护责任分到对应负责人。
清单的使用对象包括迁移负责人、数据负责人、测试负责人和业务验收人。迁移负责人关注整体进度与阻断项；数据负责人核对对象、字段、附件和历史记录的完整性；测试负责人验证功能与流程；业务验收人从业务可用角度确认关键场景。四类角色在清单上承担不同的勾选与签字责任。
维护角色分两层：清单Owner负责版本管理、条目增删和整体结构，确保清单不臃肿、不遗漏；各域负责人负责本域条目的内容准确性和证据提交。条目内容由域负责人起草，清单Owner审核后纳入正式版本，避免多人同时改同一份清单造成冲突。
| 更新时点 | 触发条件 | 主要更新动作 | 责任人 |
|---|---|---|---|
| 迁移方案定稿 | 迁移范围、对象清单、切换方式确认 | 建立初版清单，冻结检查项结构 | 清单Owner |
| 试迁移结束 | 样本迁移完成并完成差异核对 | 补充试迁移发现的问题条目，调整通过标准 | 各域负责人 |
| 正式切换前 | 切换窗口、回退方案、通知安排确定 | 确认阻断项状态，锁定切换检查项 | 迁移负责人与清单Owner |
| 切换后观察期结束 | 观察期问题登记完成 | 登记遗留问题，形成归档版本 | 清单Owner |
每次更新都要留下记录：谁在什么时间改了哪些条目、为什么改。记录方式可以是清单内的变更记录表，也可以放在迁移项目的工作项或文档评审记录中。触发条件出现而未更新，本身就是清单维护的异常，应在迁移例会上提出。
分阶段检查项：从准备到切换后观察
检查项按迁移推进顺序分为四个阶段，每个阶段有明确的进入条件和退出条件。条目写成可勾选的动作或结果，避免“评估是否充分”这类无法判断的表述。
准备阶段
- 迁移范围已书面确认，包含纳入迁移的项目、空间或业务对象，以及明确排除的内容。
- 字段与对象清单已冻结，字段类型、必填关系、选项值和历史数据范围有对应说明。
- 回退方案已就绪，包含回退触发条件、回退操作步骤和回退责任人。
- 迁移环境、账号权限和网络条件已确认可用。
- 定制场景与插件替代已逐项评估，评估结论纳入清单。
试迁移阶段
- 按约定比例抽取样本数据完成迁移，样本覆盖主要业务对象类型。
- 样本数据逐项核对，记录数量、字段值、附件和权限的差异。
- 差异报告已提交，差异原因分类为迁移工具问题、配置问题或源数据问题。
- 试迁移发现的问题已闭环，未闭环项有责任人和计划完成时间。
正式切换阶段
- 切换窗口已确认，包含开始时间、预计时长和业务影响范围。
- 源系统冻结写入的安排已通知到相关用户，冻结起止时间明确。
- 增量同步完成并核对，切换前最后一批变更已进入目标系统。
- 切换通知已发送，包含新系统入口、登录方式和问题反馈渠道。
- 回退方案处于可执行状态，回退决策人已到位。
切换后观察阶段
- 关键业务对象按清单抽查，抽查结果与源系统记录一致。
- 用户反馈渠道畅通，反馈问题已登记并分类。
- 遗留问题登记完成，每项有责任人和处理时限。
- 观察期结束结论已形成，明确是否关闭迁移项目。
每项怎么判断通过：通过标准与证据
检查项只有配上可观察的通过标准和可提交的证据，才能被不同角色一致判断。通过标准写结果、数量或状态，例如“样本工作项数量与源系统一致，差异为0条”或“回退脚本在演练环境中执行成功并记录耗时”，避免“基本一致”“确认无误”这类主观描述。
证据形式根据条目性质选择：数据核对用核对记录或差异报告，配置确认用截图或配置导出，业务确认用签字记录，切换通知用发送记录。证据要能对应到具体条目和具体时间，不能用一个笼统的“迁移完成报告”覆盖所有条目。
| 检查项示例 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 样本工作项迁移核对 | 抽样数量达到约定值，字段值与源系统一致，差异条目全部有原因说明 | 核对记录表、差异报告 | 数据负责人 |
| 附件迁移完整性 | 抽样附件可下载打开，文件数量与源系统一致 | 附件清单比对记录、抽查截图 | 数据负责人 |
| 权限结构迁移 | 关键角色在目标系统的可见范围与源系统一致 | 权限对照表、业务验收人签字 | 业务验收人 |
| 回退方案可用 | 回退步骤在演练中执行成功，耗时在切换窗口可接受范围内 | 演练记录、回退责任人确认 | 迁移负责人 |
| 切换通知到位 | 通知覆盖约定用户群体，发送时间早于切换窗口 | 通知发送记录 | 迁移负责人 |
证据统一存放在迁移项目的指定位置，命名规则建议包含阶段、条目编号和日期，例如“试迁移-数据核对-20250610”。条目未满足通过标准时，处理路径是：记录差异、判定影响、指定责任人和完成时间，必要时升级为阻断项。未关闭的差异不能以“后续处理”直接勾选通过。
阻断项与完成条件
阻断项是未通过就必须停止推进的条目。常见类型包括核心数据缺失或大量不一致、回退方案不可用、关键业务对象核对未通过、切换窗口内无法完成必要操作。阻断项的判定应在清单中提前标注，避免切换当天临时争论。
阻断项的关闭需要满足两个条件：差异已修复并有复核记录，或差异经审批人书面接受并说明补偿措施。审批人通常是迁移负责人和业务验收人共同确认，涉及数据安全的还需对应管理角色参与。关闭记录写入清单，保留审批时间和结论。
整体清单的完成条件是：全部阻断项关闭；非阻断项要么通过，要么有明确处理计划，包含责任人和完成时间；观察期遗留问题已登记。满足条件后清单归档，作为迁移项目的验收依据。归档版本不再修改，后续调整进入新的维护版本。
清单的版本更新与定期维护机制
清单在迁移期间是高频更新的工作文档，迁移结束后应转为常规检查表继续使用。版本记录至少包含版本号、日期、变更人、变更原因和影响条目，条目增删需经清单Owner评审，涉及阻断项定义变更的还需迁移负责人确认。
| 版本 | 日期 | 变更人 | 变更原因 | 影响条目 |
|---|---|---|---|---|
| V0.1 | 方案定稿日 | 清单Owner | 建立初版清单 | 全部 |
| V0.2 | 试迁移结束日 | 数据负责人 | 补充试迁移发现的差异核对条目 | 试迁移阶段条目 |
| V1.0 | 切换前确认日 | 清单Owner | 锁定切换检查项，标注阻断项 | 正式切换阶段条目 |
| V1.1 | 观察期结束日 | 清单Owner | 登记遗留问题，形成归档版本 | 观察阶段条目 |
迁移结束后，清单转为常规检查表的维护周期建议按季度或按系统重大变更触发复核：检查条目是否仍对应现有系统结构，通过标准是否仍可核验，阻断项定义是否仍适用。与迁移复盘的联动方式是：复盘发现的问题反哺为清单条目或通过标准；与问题台账的联动方式是：台账中重复出现的问题类型，评估是否应升级为阻断项或新增检查项。
在工具层面，清单条目、证据附件和阻断项状态需要有承载位置。ONES 的迁移方案把数据完整、业务连续和系统稳定作为迁移目标，并建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。对于 Jira 与 Confluence 替换场景，ONES 的迁移范围可覆盖项目、工作项、状态、字段、流程、附件和历史记录，以及空间、页面、附件和权限结构。清单中的核对条目、差异记录和评审结论可以对应到迁移项目的工作项与文档中，让条目状态、证据和审批记录随迁移阶段同步更新，减少清单与实际情况脱节。
常见问题
迁移验收清单的条目在试迁移后需要大改，初版结构还有意义吗？
有意义，但要把“结构冻结”和“内容更新”分开看。初版清单在方案定稿时冻结的是检查项结构，即有哪些阶段、每阶段覆盖哪些检查维度；试迁移结束后调整的是条目内容和通过标准，例如补充差异核对条目、把某条通过标准从“基本一致”改为具体数量要求。
如果试迁移暴露出初版结构遗漏了整类检查维度，例如附件迁移或权限结构，这属于结构变更，应由清单Owner评审后升版本，并在变更记录中写明原因。结构频繁变动说明准备阶段的评估不够充分，可在迁移例会上复盘。
清单Owner和各域负责人意见不一致时，条目以谁为准？
按条目性质区分。条目内容是否准确、证据是否充分，以域负责人意见为主，因为其掌握本域的实际核对情况；条目是否纳入清单、通过标准是否可核验、是否升级为阻断项，由清单Owner裁定，涉及阻断项定义的还需迁移负责人确认。
分歧无法在清单内解决时，提交迁移例会决策，并把结论写入变更记录。避免在清单里保留两种说法，否则不同角色会按各自理解勾选，清单失去约束力。
切换窗口很紧，部分非阻断项来不及核对，能否先切换再补？
可以，但前提是该条目在清单中未被标注为阻断项，且补做安排已写入清单：明确补做内容、责任人、完成时间和补做期间的补偿措施，例如对未抽查的业务对象先由业务验收人做可用性确认。
核心数据缺失或大量不一致、回退方案不可用、关键业务对象核对未通过这几类属于阻断项，未关闭不应进入切换。若确需带风险切换，应由迁移负责人和业务验收人书面接受差异并说明补偿措施，记录保留在清单中。
迁移结束后清单转为常规检查表，多久复核一次比较合适？
建议按季度复核，并在系统发生重大变更时额外触发一次，例如升级、流程调整、组织与权限结构变化。复核内容包括：条目是否仍对应现有系统结构，通过标准是否仍可核验，阻断项定义是否仍适用。
复核不必每次全量重写，可只更新受影响条目并记录版本。若连续多个周期无变更，可适当拉长周期，但需在清单中注明下次复核时间。
清单条目、证据和阻断项状态放在哪里维护比较合适？
关键是让条目状态、证据附件和审批记录有固定承载位置，并能随迁移阶段同步更新。常见做法是把检查项作为工作项管理状态与负责人，把差异报告、核对记录和签字确认作为附件或文档关联到对应条目，阻断项单独标记并在例会上跟踪。
ONES 的迁移方案把数据完整、业务连续和系统稳定作为迁移目标，建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配；对 Jira 与 Confluence 替换场景，迁移范围可覆盖项目、工作项、状态、字段、流程、附件和历史记录，以及空间、页面、附件和权限结构。清单条目与评审结论可以对应到迁移项目的工作项与文档中，具体承载方式需结合团队现有工具评估。
