迁移验证要回答三个问题：该迁的是否都迁到了，迁过去的内容是否可用，业务能否照常运转。做法是先划定来源、目标和对象范围，做一轮小范围试迁移并记录基线，再按对象类型核对数量、字段、附件与权限，组织真实角色验收，必要时并行运行一个周期，最后在切换窗口内完成正式迁移并保留可回退的旧环境。验证结论以证据为准，未确认项按待验证处理。验证过程中产生的差异记录、验收用例和遗留项，可以放在ONES的工作项与文档中跟踪。
要点总览（TL;DR）
- 迁移验证要证明三件事：该迁的都迁到了、迁过去的内容可用、业务能照常运转；结论以证据为准，未确认项按待验证处理。
- 先写一页验证范围表，锁定来源与目标环境、对象类型、排除项和数量基线，再由迁移负责人与业务负责人共同确认。
- 试迁移按基础数据、业务对象、关联与历史的顺序执行，逐项核对数量、字段、附件、状态与权限，差异登记后复检关闭。
- 技术校验通过后组织真实角色做业务验收，必要时并行运行一个业务周期，验收结论以确认记录留存。
- 切换窗口内完成正式迁移和首轮最小校验，事先写明停止与回退条件，并保留旧环境可读可用作为回退基础。
迁移验证要验证什么：来源、目标与范围先定清
验证范围与迁移范围错位，是迁移项目里最常见的返工来源。迁移脚本按A口径导出，验证却按B口径统计，数量永远对不上。开始验证前，先把“验什么”写成一张表，让迁移执行人和验证人对同一份范围达成一致。
范围表至少包含四类信息。第一是环境信息：来源系统的产品与版本、目标系统的产品与版本、各自所处的环境（生产、测试或独立项目空间）。版本差异会影响字段可用性和权限模型，需要在表里写明，后续校验时据此解释差异。第二是对象类型清单，逐项列出本次纳入验证的数据：工作项、需求、缺陷、测试用例、文档、附件、评论、状态与流转记录、用户与权限。第三是排除项及原因，例如历史归档项目、已停用的自定义字段、外部系统同步而来的只读数据，写明“不纳入”比含糊带过更有利于验收时对齐预期。第四是每类对象的数量基线与抽样规则，基线来自来源侧导出，抽样规则说明全量核对还是按比例抽查、按什么维度分层。
下表是一页范围表的参考结构，可直接填写使用。
| 对象类型 | 来源数量 | 目标预期数量 | 抽样比例 | 责任人 | 备注 |
|---|---|---|---|---|---|
| 工作项（含需求、缺陷、任务） | 按来源导出填写 | 等于来源数量减去排除项 | 全量核对总量，按项目分层抽10%–20%核对字段 | 迁移执行人 | 注明是否含已关闭、已删除项 |
| 测试用例 | 同上 | 同上 | 按测试计划分层抽样 | 测试负责人 | 注明用例步骤与预期结果的保留要求 |
| 文档与附件 | 按文件清单计数 | 同上 | 按大小区间分层抽样 | 迁移执行人 | 大文件单独列出 |
| 评论与操作历史 | 按对象计数 | 同上 | 抽取高频协作对象 | 业务代表 | 注明历史是否要求完整保留 |
| 用户与权限 | 按账号与角色计数 | 同上 | 全量核对角色映射 | 系统管理员 | 注明离职账号、外部协作者的处理 |
范围表确定后由迁移负责人和业务负责人共同确认。此后新增或缩减验证对象，走变更登记，避免验证过程中范围悄悄扩大或缩小。
验证前的输入与依赖：基线、账号与清洗规则
验证开始前需要把输入备齐，边迁边补会让差异无法归因。必备输入分四组：来源侧基线、目标侧环境、清洗与映射结果、写入冻结约定。
来源侧基线包括：按对象类型导出的数量统计、字段清单（字段名、类型、是否必填、枚举取值）、附件与文件清单（文件名、大小、所属对象）。基线要在冻结写入之后导出，否则导出后来源侧的新增数据会让数量核对失真。
目标侧环境包括：用于试迁移的测试环境或独立项目空间、验证专用账号及其权限、与生产一致的字段配置。验证账号应覆盖管理员、项目成员、只读访客等典型角色，权限校验才有意义。
清洗与字段映射结果指已经确认的映射表和清洗规则输出，例如哪些字段合并、哪些枚举值做了转换、哪些脏数据被剔除。映射方案本身如何设计不在本文展开，验证阶段只核对映射执行结果是否符合已确认的映射表。
冻结写入约定要写明时间点和变更登记方式：从某日某时起来源系统停止新增和修改业务数据，确需变更的走登记，记录变更对象、时间和操作人，验证时把这些变更从差异中剔除。冻结窗口的长度取决于数据量和业务节奏，通常覆盖试迁移、校验到正式切换的整段过程。
试迁移与逐项校验：数量、字段、附件与状态怎么核
试迁移的目的是用最小代价暴露问题。样本选择遵循两条原则：覆盖所有对象类型，覆盖所有字段映射规则。可以先迁一个项目或一个团队的数据，再补一批包含特殊情况的样本，例如含大附件的文档、含多级流转记录的工作项、含外部协作者的权限配置。执行顺序上先迁基础数据（用户、组织、字典），再迁业务对象，最后迁关联关系与历史记录，这样每一步的差异都能定位到具体环节。
数量核对分三层：总量、按类型、按项目或团队分组。总量对不上时，分组统计能快速定位是某类对象整体缺失还是某个项目漏迁。核对口径要统一，例如“已删除项是否计入”在来源和目标两侧必须一致。
字段核对关注四类问题：必填项是否为空、枚举值是否落在目标系统的合法取值内、日期字段是否发生时区偏移、人员归属是否指向正确的账号。抽样时优先选字段最多的对象和使用了自定义字段的对象。
附件与富文本的核对包括文件数量、文件大小、能否正常打开，以及正文中的图片和链接是否可访问。链接指向来源系统内部地址的，要确认目标环境中是否有对应处理。
状态与流转记录、评论与操作历史，按业务要求核对保留程度。有些团队要求完整保留审批轨迹，有些只要求保留当前状态和关键评论，范围表里应已写明，校验时按同一口径判定。
差异记录表建议包含：差异编号、对象类型、对象标识、差异描述、期望值与实际值、严重程度、责任人、处理状态、复检结果。复检在修复后针对同一对象重新核对，复检通过才关闭差异。下表给出校验项与判定口径的对照。
| 校验项 | 核对方法 | 通过判定 | 常见差异原因 |
|---|---|---|---|
| 数量 | 来源导出与目标导出按类型、项目分组比对 | 差异为零，或差异项均有登记且已确认 | 排除项口径不一致、冻结后新增数据 |
| 字段 | 抽样对象逐字段比对 | 必填项无空值，枚举值合法，日期与人员正确 | 映射表遗漏、枚举值未转换、时区设置 |
| 附件 | 文件数量与大小比对，抽样打开 | 数量一致，抽样文件可正常打开 | 大文件超限、文件名特殊字符 |
| 状态与历史 | 抽样对象比对状态值与流转记录 | 符合范围表约定的保留程度 | 状态机不一致、历史记录未随对象迁移 |
| 权限 | 用不同角色账号访问抽样对象 | 可见性与操作权限符合预期 | 角色映射错误、项目成员未同步 |
业务验收与并行运行：让真实角色确认可用
技术校验通过只说明数据搬过去了，业务验收要回答“搬过去之后能不能干活”。验收角色从日常使用频率最高的岗位中选：项目经理、开发负责人、测试负责人、文档维护人，每个角色至少一人。验收场景按日常高频操作设计，覆盖新建、查询、流转、关联、报表或看板查看这几类动作。
验收用例写成可执行的形式：前置条件、操作步骤、预期结果、实际结果、判定。例如“以项目成员身份登录，打开指定需求，将其状态从‘开发中’流转到‘待测试’，确认状态变更记录出现在活动日志中，且关联的测试用例仍保持关联”。用例数量不必多，覆盖每个角色的核心路径即可。
并行运行指新旧系统同时可用一段时间，同一批业务操作在两侧比对结果。并行周期取决于业务节奏，通常覆盖一个完整的迭代或一个结算周期。比对方式可以是抽取并行期内新建或变更的对象，核对两侧的字段、状态和关联是否一致。并行期发现的问题按三类处理：阻断问题（关键对象缺失、附件不可用、权限错配，必须修复后重新验收）、可接受差异（已登记且业务确认不影响使用）、待确认（需要业务或技术进一步判断）。
验收结论以签字或确认记录形式留存，记录验收人、验收日期、通过的用例和未通过的用例及处理意见。未通过的用例不能以“后续再看”关闭，要么修复复验，要么转为遗留项并明确责任人和关闭时点。
切换窗口与回退条件：什么情况下停、什么情况下退
切换窗口是正式迁移的执行时间段，安排时考虑业务低峰和人员可用性。窗口内继续冻结来源系统写入，冻结约定与验证阶段一致。切换执行按检查单推进，每一步完成后打勾并记录时间。
切换后的首轮校验取最小集合：关键对象数量、抽样对象的字段与附件、核心角色的登录与权限、关键业务流程能否走通。最小集合在窗口内完成，发现问题时还有时间处置。
停止与回退的判定条件要事先写清，避免现场争论。典型触发条件包括：关键对象类型出现大面积缺失且短时间无法补齐、附件批量不可用、权限错配导致业务角色无法访问其负责的项目、核心流程在目标系统无法完成。判定由迁移负责人和业务负责人共同做出，触发后按预案执行。
回退到旧环境的处理包括：确认旧环境数据在冻结期内未被破坏、恢复来源系统的写入、通知相关用户切换回旧系统、登记回退原因和已完成的迁移动作。回退不是失败，而是控制损失的手段，前提是旧环境在切换后一段时间内保持可读可用。
切换后设观察期，通常覆盖一到两个业务周期。观察期内收集用户反馈，遗留差异按台账跟踪，到期未关闭的差异升级处理。观察期结束且遗留项清零或经业务确认可接受，迁移才算收尾。
验证证据怎么留：记录、报告与遗留项跟踪
验证结论要能被第三方复核，证据就得可追溯。证据类型包括：数量比对的导出文件或截图（注明导出时间和口径）、抽样明细（对象标识与逐字段比对结果）、验收用例记录、差异处理记录、切换检查单和回退判定记录。截图要带时间和环境信息，导出文件保留原始格式。
验证报告建议包含以下字段：迁移范围与排除项、来源与目标环境版本、各对象类型的基线与实际数量、抽样比例与抽样结果、差异总数与分类统计、业务验收结论、并行运行结论、切换执行情况、遗留项清单、总体结论与签字。总体结论按证据表述，例如“数量核对通过，附件抽样全部可打开，两项字段差异已登记待修复”，避免写成笼统的“迁移成功”。
遗留项台账记录每项差异的描述、影响范围、责任人、计划关闭时点和当前状态。复验触发条件包括：差异修复后、映射规则调整后、目标环境配置变更后。每次复验更新台账并保留复验记录，直到遗留项关闭。
这些记录分散在表格、文档和聊天工具里容易丢失。把差异登记为工作项、把验收用例和验证报告放进项目文档，可以让责任人、状态和关闭时点在同一处可见，复验时直接按台账逐项核对。ONES支持工作项状态流转与文档协作，适合承载这类验证过程的跟踪，具体配置按团队实际流程设置。
常见问题
试迁移要迁多少数据才够判断问题？
样本量取决于对象类型和映射规则的覆盖度，不取决于数据总量。可行的做法是先迁一个项目或一个团队的数据，再补一批包含特殊情况的样本，例如含大附件的文档、含多级流转记录的工作项、含外部协作者的权限配置。判断标准是每条字段映射规则和每类对象都至少被样本覆盖一次。样本太小会漏掉边界情况，样本太大则修复和复检的成本上升。
数量核对时来源和目标两侧口径不一致怎么办？
先统一口径再比对，否则差异无法归因。需要事先约定的口径包括：已删除项是否计入、已关闭项是否计入、排除项如何扣减、冻结后新增数据如何处理。口径写进范围表，两侧导出使用同一时间点和同一筛选条件。如果差异来自冻结期内的变更登记，把对应对象从差异中剔除并注明依据；如果差异来自口径本身，先修正口径再重新导出比对。
并行运行必须做吗，周期多长合适？
并行运行适用于业务连续性要求高、切换后难以快速回退的场景，例如核心研发流程依赖的系统。周期通常覆盖一个完整迭代或一个结算周期，让高频操作和周期性操作都能被比对到。并行期要指定比对方式，例如抽取并行期内新建或变更的对象，核对两侧字段、状态和关联是否一致。业务量小、回退成本低的迁移，可以用试迁移加业务验收替代并行，但要在验证报告里写明这一取舍。
切换后发现差异，应该立即回退还是先修复？
按事先写好的判定条件处理，避免现场临时决定。触发回退的典型情况是关键对象类型大面积缺失且短时间无法补齐、附件批量不可用、权限错配导致业务角色无法访问其负责的项目、核心流程在目标系统无法完成。属于个别对象的字段差异或少量附件问题，通常登记为遗留项并在观察期内修复，不必整体回退。判定由迁移负责人和业务负责人共同做出，回退后要恢复来源系统写入并通知用户。
验证报告写到什么程度算可复核？
标准是第三方拿着报告和附件能重现结论。报告需要包含迁移范围与排除项、来源与目标环境版本、各对象类型的基线与实际数量、抽样比例与抽样结果、差异总数与分类统计、业务验收与并行运行结论、切换执行情况、遗留项清单和签字。数量比对保留导出文件或带时间和环境信息的截图，抽样明细保留对象标识与逐字段比对结果。总体结论按证据表述，例如“数量核对通过，附件抽样全部可打开，两项字段差异已登记待修复”，不写笼统的“迁移成功”。
