迁移业务验收要回答的问题，是迁移后的系统能否按原有业务方式正常运转。做法可以拆成一条连贯路径：先定验收范围和通过标准，再用代表性样本做试迁移并核对数量、字段、状态和附件，接着组织业务角色按真实场景逐条走查，安排一段并行运行对比新旧结果，最后在切换窗口内完成正式迁移、抽检和回退预案确认。每一步都留下输入、动作、输出和完成标志，验收结论以证据记录为准。
要点总览（TL;DR）
- 迁移业务验收先把“迁移成功”翻译成可量化条目：按项目、需求、任务、缺陷、文档、附件、历史状态划定范围，为每类对象写明数量一致率、字段一致率、状态映射正确率和附件可打开率，并指定判定人。
- 试迁移用代表性样本暴露问题，样本要覆盖附件多、状态流转复杂、跨项目关联的记录；核对数量、字段、状态和关联关系，校验附件可打开与内容完整，通过后再做全量预演估算切换窗口时长。
- 业务验收由业务负责人主导、数据负责人和工具管理员配合，按真实场景从高频到低频逐条走查，记录预期结果、实际结果、结论和证据位置，问题分级后安排回归复验。
- 并行运行至少覆盖一个完整业务周期，每周固定比对同一批业务在新旧系统的结果，差异逐条归因或由接受人签字；切换窗口按冻结、正式迁移、抽检、开放使用四段安排，抽检清单逐项打勾才算完成。
- 回退预案在切换前写好并确认可执行，触发条件明确为关键数据缺失、核心流程不可用、附件大面积不可读三类；验收关闭前按完成检查清单逐项核对，每项都有通过标准和证据位置。
先定验收范围和通过标准
验收开始前先做一件事：把“迁移成功”翻译成可检查的条目。范围按业务对象划定，标准按检查项量化，判定人提前指定。这样后续试迁移、走查和切换才有统一口径，避免验收会上各说各话。
验收范围建议覆盖以下对象，逐类列入表格：项目（含项目基本信息与成员关系）、需求、任务、缺陷、文档、附件、历史状态与流转记录。范围之外的内容要写明，例如本次不校验报表自定义样式、不校验历史通知消息。范围一旦确认，后续试迁移样本和走查场景都从这份清单里取。
通过标准要写成可量化的形式，并注明判定人和判定时点。常见写法如下：
| 业务对象 | 检查项 | 通过标准示例 | 判定人 |
|---|---|---|---|
| 项目 | 项目数量与关键字段 | 项目总数一致率100%，名称、负责人、状态字段一致率≥99.5% | 数据负责人 |
| 需求/任务/缺陷 | 记录数量、字段值、状态 | 数量一致率100%；标题、经办人、优先级字段一致率≥99.5%；状态映射正确率100% | 数据负责人 |
| 文档 | 页面数量与层级 | 页面数量一致率100%，目录层级与原文一致 | 业务负责人 |
| 附件 | 可打开与内容完整 | 抽样附件可打开率100%，文件大小与源端一致 | 工具管理员 |
| 历史状态 | 流转记录可追溯 | 抽样记录的状态变更时间线与源系统一致 | 业务负责人 |
标准里要同时写清“不通过怎么办”。建议约定三级判定：单项不达标但可修复的，记入问题清单并安排修复后复验；关键对象（如核心项目、核心流程状态）不达标的，暂停进入下一阶段；差异属于源数据本身问题或业务已确认可接受的，由判定人签字记录接受理由。判定路径写进同一张表，验收过程中直接按表执行。
数据映射设计（字段如何对应、状态如何转换）属于迁移方案设计环节，本文不展开；验收环节只核对映射结果是否符合预期。
试迁移怎么做：从抽样到全量预演
试迁移的目的是用较小成本暴露问题。输入是已确认的验收范围与标准、源系统只读访问权限、目标环境；输出是试迁移记录与异常清单；完成标志是样本校验全部达到标准，或剩余差异已有明确处理结论。
第一步，选取代表性样本。样本不宜只挑结构简单的记录，应主动覆盖容易出问题的类型：附件数量多或单附件体积大的记录、状态流转复杂（多次驳回、重新打开）的记录、跨项目关联的需求与任务、含特殊字符或长文本描述的记录、权限结构较深的文档空间。样本量按对象类型各取若干条，并在记录中写明选取理由，便于后续判断结论的适用范围。
第二步，执行试迁移并留痕。迁移过程中保留迁移日志，逐条记录开始时间、处理条数、失败条数和错误信息。异常不要只记“失败”，要记到对象标识和失败原因，例如某条记录的附件下载超时、某字段值超出目标字段长度。日志和异常清单合并为一份试迁移记录。
第三步，做数据层核对。核对内容包括：记录总数与源端一致；关键字段逐条比对，抽样记录做全字段比对；状态值与目标系统的状态映射逐一对应，重点检查终态和异常态；关联关系（父子任务、需求与任务关联、跨项目链接）在目标系统中可正确跳转。核对结果按验收标准表逐项填写一致率。
第四步，校验附件与文档完整性。附件核对建议同时看三个维度：数量（附件条数与源端一致）、可打开（逐一下载并打开，确认格式可识别）、内容（文件大小一致，抽查正文或图片内容无截断）。文档核对看页面数量、层级结构和正文内容，含表格、代码块、内嵌图片的页面要单独抽查。
第五步，试迁移通过后做全量预演。全量预演使用与正式迁移相同的流程和配置，在独立环境中跑一遍完整数据，重点观察迁移耗时、失败集中出现的对象类型和系统资源占用。预演结果用于确定正式切换窗口的时长估算和人力安排。预演不通过时回到异常清单逐项处理，处理完再重跑，不在预演未通过的情况下进入业务走查。
业务验收怎么组织：角色分工与走查步骤
数据核对通过只说明“搬过去了”，业务验收要确认“能按原样跑起来”。这一步由业务角色主导，数据负责人和工具管理员配合，产出业务走查记录表与问题清单。
角色分工建议如下：业务负责人从各业务线指定熟悉日常操作的人员，负责按真实场景走查并给出业务结论；数据负责人负责数据层核对结果、差异归因和修复验证；工具管理员负责环境、权限、账号和迁移配置，处理走查中暴露的配置类问题。三类角色各有一名总协调人，负责汇总结论和对外沟通。
走查按真实业务场景逐条执行，顺序建议从高频到低频：新建一条需求或任务并走完审批流转；执行查询与筛选，确认常用视图和看板显示正常；打开报表或统计页面，核对数字口径；下载附件、打开文档并确认可编辑；检查历史记录的评论与操作日志是否可读。每条场景执行前写明预期结果，执行后记录实际结果。
走查记录表建议包含这些字段：场景编号、场景描述、执行人、执行时间、预期结果、实际结果、结论（通过/不通过/有条件通过）、证据位置（截图或记录链接）、问题编号。证据要能指向具体记录，便于复验时直接回看。
走查发现的问题按影响分级：阻断级（核心流程无法完成、关键数据缺失）当天上报并暂停相关场景；重要级（字段显示错误、附件个别不可读）进入问题清单限期修复；一般级（界面文案、排序差异）记录后统一处理。修复完成后安排回归复验，复验只针对问题项和受影响场景，复验通过后在记录表中更新结论并保留原记录。
走查任务的分派、问题状态跟踪和结论归档需要有承载位置。ONES 的项目与工作项可以按场景建立走查任务，把问题作为独立工作项指派给责任人并记录处理状态，验收结论和相关文档沉淀在 Wiki 中，便于复验和归档时按同一处查证。
并行运行与切换窗口怎么安排
并行运行的目的是用同一批真实业务在新旧系统中各跑一遍，比对结果是否一致。时长没有统一标准，通常按业务周期确定：至少覆盖一个完整的业务周期（如一个迭代或一个月度结算周期），业务节奏快、流程分支多的团队可适当延长。并行期间新业务在旧系统照常执行，同时在新系统录入或同步，形成可比对的两份结果。
对比口径要提前约定：比对哪些业务对象、比对哪些字段、由谁比对、多久比对一次。建议每周固定一次比对，形成并行运行对比记录，逐条记录差异现象、涉及对象、初步归因（数据问题、配置问题、操作差异、业务规则差异）和处理结论。无法归因的差异要指定接受人签字确认，不能留在记录里悬空。
切换窗口的安排取决于全量预演的耗时和业务低峰时段。前置条件包括：试迁移与全量预演通过、业务走查阻断级问题清零、并行差异已归因或已接受、回退预案已确认可执行、切换通知已发出。时间安排上，把窗口划分为冻结、正式迁移、抽检、开放使用四段，冻结规则明确为：窗口开始前停止旧系统的新建和修改操作，只读访问保留；冻结期间如有紧急业务，走事先约定的应急通道并记录。
切换当天的抽检动作要提前列成清单：核对迁移后各对象总数；抽查核心项目的关键字段和状态；抽查附件下载与文档打开；用核心账号走一遍最高频的业务流程；确认权限和账号可用。抽检全部通过后宣布切换完成，完成标志是抽检清单逐项打勾并有执行人签字，同时通知业务方恢复使用。
回退条件与回退预案
回退预案要在切换前写好并确认可执行，而不是等出问题再讨论。触发条件建议明确为三类：关键数据缺失或数量差异超出验收标准且短时间无法修复；核心业务流程在目标系统不可用（如无法新建、无法流转、无法查询）；附件或文档大面积不可读，影响日常业务开展。触发后由总协调人召集判定，决定回退还是继续修复，判定过程和结论记录在案。
回退前要准备两样东西：一是切换前的数据快照，包括旧系统数据库或应用层备份、附件存储备份，并确认快照可恢复；二是旧系统的可用性确认，包括账号、权限、许可证和访问入口在切换窗口内保持可用。快照的存放位置、恢复方式和责任人写入预案。
回退执行步骤按顺序写清：停止新系统写入；通知业务方暂停操作；按预案恢复旧系统数据快照；验证旧系统核心流程可用；恢复业务使用；记录回退时间点和影响范围。每一步指定责任人和预计耗时，回退过程中保持单一指挥，避免多人同时操作。
回退完成后做验证与复盘：验证项包括关键数据是否完整、核心流程是否恢复、附件是否可访问；复盘记录回退原因、发现时点、处理过程和后续改进项。回退不等于验收失败，但复盘结论要明确下一次切换前必须解决的问题。
一个完整的验收示例
以下为演示情景，用于说明步骤如何串联，数据为示意。
某研发团队将旧工具中的项目数据迁移到新系统，验收范围定为：12个项目、约1.8万条需求与任务、约6000条缺陷、约900篇文档、约2.4万个附件。通过标准沿用前文的量化口径，判定人为数据负责人和两位业务负责人。
试迁移阶段选取样本80条，覆盖附件超过20个的记录、经历三次以上状态回退的记录、跨项目关联的任务和含复杂表格的文档。核对结果：记录数量一致；字段一致率99.7%，差异集中在两个自定义字段的长度截断；状态映射全部正确；附件可打开率100%，其中1个附件因源文件损坏无法打开，记为源数据问题。异常清单共5项，修复后复验通过4项，1项由业务负责人签字接受。
业务走查由两位业务负责人各带一名骨干执行，共走查18个场景。发现阻断级问题1项：某核心项目的看板视图无法按原状态分组；重要级问题3项，包括附件预览格式不支持、历史评论时间显示时区偏差。阻断级问题当天修复并复验通过，重要级问题在并行运行开始前全部关闭。
并行运行持续三周，每周比对一次，共记录差异7条，归因结果为配置差异4条、操作习惯差异2条、业务规则差异1条，全部由对应负责人确认接受。全量预演耗时4小时20分，据此将切换窗口定为周六凌晨0点至6点。切换当天抽检清单12项全部通过，验收结论记录为：数据层核对通过、业务走查通过、并行差异已归因、回退预案已确认，验收关闭。
完成检查：验收通过前逐项确认
验收关闭前按下表逐项核对，每项都要有通过标准和证据位置，缺一项不关闭。
| 检查类别 | 检查项 | 通过标准 | 证据位置 |
|---|---|---|---|
| 数据完整性 | 各业务对象数量核对 | 与源端一致率100%，差异已归因并接受 | 试迁移记录、全量预演报告 |
| 数据完整性 | 关键字段与状态映射 | 字段一致率、状态映射正确率达到验收标准 | 字段核对表 |
| 附件与文档 | 附件可打开与内容完整 | 抽样可打开率100%，大小一致 | 附件校验记录 |
| 附件与文档 | 文档层级与正文 | 页面数量一致，复杂页面抽查通过 | 文档核对记录 |
| 业务流程 | 核心场景走查 | 阻断级问题清零，重要级问题已关闭或已接受 | 业务走查记录表 |
| 并行运行 | 新旧结果差异 | 差异全部归因或有接受人签字 | 并行运行对比记录 |
| 回退准备 | 回退预案可执行 | 触发条件、快照、步骤、责任人齐全并演练确认 | 回退预案文档 |
| 归档 | 验收记录与签字 | 各角色判定人签字，记录归档可查 | 验收结论页 |
清单核对完成后，由总协调人汇总验收结论，写明通过范围、遗留事项和后续跟进责任人，签字归档。遗留事项即使不影响本次关闭，也要有明确的处理时限，避免在切换后的日常使用中反复出现。
常见问题
试迁移样本应该选多少条，怎么判断样本够不够有代表性？
样本量没有统一数字，判断标准是覆盖风险类型而非凑数量。建议按业务对象各取若干条，并主动纳入容易出问题的记录：附件数量多或单附件体积大的、状态流转复杂（多次驳回、重新打开）的、跨项目关联的需求与任务、含特殊字符或长文本的、权限结构较深的文档空间。
判断代表性是否足够，可以看试迁移暴露的问题是否集中在少数几类。如果异常清单里的问题类型在样本中反复出现，说明样本已经触到主要风险；如果异常很少且样本全是结构简单的记录，应补充复杂样本再跑一轮。样本选取理由要写进试迁移记录，便于后续判断结论的适用范围。
业务走查发现的问题，什么情况下应该暂停切换而不是带问题上线？
按问题影响分级判断。阻断级问题应当暂停相关场景并当天上报，包括核心流程无法完成（如无法新建、无法流转、无法查询）、关键数据缺失、核心项目状态显示错误。这类问题直接影响业务能否按原样运转，带问题切换会让并行运行失去对比基础。
重要级问题（字段显示错误、个别附件不可读）可以进入问题清单限期修复，在并行运行开始前关闭；一般级问题（界面文案、排序差异）记录后统一处理。是否暂停由总协调人召集判定，判定过程和结论记录在案，避免口头决定事后无法追溯。
并行运行期间新旧系统结果不一致，怎么区分是迁移问题还是业务操作差异？
先按差异现象做初步归因，常见四类：数据问题（字段值、数量与源端不符）、配置问题（视图、状态分组、权限设置不同）、操作差异（两边录入时间或操作人不一致）、业务规则差异（新旧系统对同一流程的处理逻辑不同）。
归因时回到具体对象逐条比对，而不是只看汇总数字。数据问题由数据负责人核查迁移日志和源记录；配置问题由工具管理员对照配置项；操作差异核对操作时间和操作人；业务规则差异需要业务负责人确认是否可接受。无法归因的差异指定接受人签字确认，不能留在记录里悬空。并行对比记录逐条写明差异现象、涉及对象、初步归因和处理结论。
切换窗口的时长怎么估算，冻结期间有紧急业务怎么办？
窗口时长以全量预演的实际耗时为基准，再留出抽检和应急处理的余量。预演使用与正式迁移相同的流程和配置，记录完整迁移耗时、失败集中出现的对象类型和系统资源占用，据此划分冻结、正式迁移、抽检、开放使用四段的时间。
冻结规则明确为窗口开始前停止旧系统的新建和修改操作，只读访问保留。冻结期间如有紧急业务，走事先约定的应急通道并记录，应急通道的处理方式和责任人要在切换通知里写清。抽检清单全部通过、执行人签字后宣布切换完成，再通知业务方恢复使用。
回退之后，这次验收算失败吗，后续怎么继续？
回退不等于验收失败，它说明切换前必须解决的问题还没有清零。回退完成后要做两件事：验证旧系统关键数据完整、核心流程恢复、附件可访问；复盘记录回退原因、发现时点、处理过程和后续改进项。
复盘结论要明确下一次切换前必须解决的问题和责任人，问题关闭后重新走试迁移校验、业务走查和并行对比，再安排新的切换窗口。回退过程中的时间点和影响范围一并归档，作为验收记录的一部分。
