迁移业务验收要回答的是“业务在新系统里能不能按原来的方式正常跑完”。它先圈定关键业务场景和验收口径，用真实业务数据在目标环境跑通端到端流程，逐项核对数据完整性、流程正确性、权限可见性和历史可追溯性，再由业务负责人签字确认。验收通过才进入切换，切换窗口、回退条件和观察期需要同步定下来。
要点总览（TL;DR）
- 迁移业务验收的对象是业务场景能否在新系统跑通，先圈定核心场景和判定口径，再用真实数据在目标环境跑端到端流程。
- 检查维度固定为数据完整性、字段映射正确性、流程状态流转、权限与可见范围、附件与历史记录五类，判定统一写成通过、不通过、待确认三档并附证据。
- 业务负责人定标准并签字，迁移执行方准备样本和执行核对，系统管理员保环境与权限，问题跟踪责任人独立闭环，避免验收变成单方面自测。
- 核心场景全部通过或有书面豁免才进入切换，切换窗口、冻结期、回退触发条件和观察期检查项需在验收前确定。
- 签字前逐项确认遗留问题责任人、回退方案可执行、观察期检查已分配到人，任何未确认项都要在切换决策记录中写明风险接受人。
迁移业务验收的核心答案与操作步骤
验收对象是业务场景，数据条数只是其中一项证据。一个场景跑通，意味着从业务发起、流转、审批到归档的完整链路在目标环境中成立，参与人能看到该看的内容，历史记录能追溯。按这个标准，验收可以拆成六步推进，每一步都有明确的输入、动作和输出。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 圈定场景与口径 | 业务流程清单、系统功能清单、迁移范围说明 | 按业务重要性选出核心场景，为每个场景写明检查维度和判定标准 | 验收场景清单、判定口径表 | 业务负责人确认场景范围和判定标准 |
| 2. 准备样本数据 | 源系统真实业务数据、账号与权限清单 | 按场景挑选代表性样本，覆盖正常流程、异常分支和边界数据，明确全量核对与抽样的范围 | 样本清单、样本与源数据的对应关系 | 样本可追溯到源系统记录，抽样比例经业务确认 |
| 3. 目标环境端到端跑通 | 目标环境、测试账号、样本数据 | 由业务人员按真实操作路径走完每个场景，记录每一步的实际结果 | 场景执行记录、过程截图或操作留痕 | 每个核心场景至少完整跑通一次 |
| 4. 逐项核对 | 验收清单、源系统对照数据 | 按检查维度逐项比对，填写通过、不通过或待确认，附上证据 | 填写完成的验收清单、问题清单 | 所有检查项有结论，不通过项有记录 |
| 5. 业务签字 | 验收清单、问题处理结果 | 业务负责人复核结论，确认遗留问题的处理安排，签署验收意见 | 签字确认的验收记录 | 核心场景全部通过或有书面豁免 |
| 6. 切换与观察 | 验收结论、切换方案、回退方案 | 按切换窗口执行切换，观察期内按检查项逐日确认业务运行状态 | 切换记录、观察期检查记录 | 观察期结束且无阻断性问题 |
六步之间存在依赖关系：场景和口径没定，样本就无从选起；样本不具备代表性，端到端跑通只能证明个别数据可用；核对结论没有证据支撑，签字就失去依据。实际项目中可以把第3步和第4步合并执行，边跑边核对，但结论仍要分开记录，便于区分“流程走不通”和“数据对不上”两类问题。
验收场景与口径怎么定：字段与判定表
场景选取按业务重要性排序，优先覆盖那些一旦出错会直接影响交付、质量或合规的流程。研发管理类系统常见的核心场景包括需求到交付的完整链路、缺陷从提交到关闭的闭环、版本发布与上线记录、跨项目或跨团队的协作审批。每个场景再拆成若干检查项，落到具体字段和判定标准上。
检查维度建议固定为五类，保证不同场景之间的结论可以横向比较：
- 数据完整性：记录数量、必填字段、关联关系是否齐全，有无丢失或截断。
- 字段映射正确性：枚举值、日期、人员、多选字段的取值是否与源系统一致，特殊字符和长文本是否正常。
- 流程状态流转：状态名称、流转路径、审批节点和触发条件是否按预期工作。
- 权限与可见范围：不同角色看到的项目、工作项、附件和页面是否符合原权限设计。
- 附件与历史记录：附件可下载可预览，评论、变更历史、操作日志按时间顺序可查。
判定口径统一写成三档：通过、不通过、待确认。“待确认”用于证据不足或需要业务判断的情况，必须写明待确认的具体问题和确认人，避免它变成变相的通过。判定描述要可核验，例如“缺陷关闭后状态为已关闭，关闭人、关闭时间与源系统一致”，而不是“状态基本正常”。
| 场景 | 检查项 | 判定口径 | 样本 | 结果 | 证据 |
|---|---|---|---|---|---|
| 需求到交付 | 需求关联的任务、缺陷链路完整 | 关联数量与源系统一致，无孤立记录 | 全量核对核心项目 | 通过/不通过/待确认 | 导出比对表、页面截图 |
| 缺陷闭环 | 状态流转与关闭条件 | 按原流程可正常流转，关闭条件生效 | 抽样20条覆盖各状态 | 通过/不通过/待确认 | 操作录屏、状态截图 |
| 版本发布 | 发布记录与关联工作项 | 版本下的工作项清单与源系统一致 | 最近3个版本全量 | 通过/不通过/待确认 | 清单导出、页面链接 |
| 权限可见性 | 角色对项目与附件的访问 | 各角色可见范围与原权限设计一致 | 每个角色抽1个账号 | 通过/不通过/待确认 | 账号登录截图 |
样本量按风险分配。核心场景、核心字段和涉及金额、合规、对外交付的数据宜全量核对；长尾项目、历史久远的数据可以抽样，抽样比例和允许的差错范围在验收前书面约定。抽样要覆盖不同状态、不同创建时间和不同负责人，避免只抽最近的数据。
角色分工与交付物
验收最容易出现的问题是变成IT或迁移执行方的单方面自测。业务方不参与，验收结论就缺少业务判断；业务方只签字不核对，签字就流于形式。合理的分工是业务方定标准和结论，迁移执行方做执行和记录，系统管理员保环境和权限，问题跟踪由固定责任人闭环。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务负责人 | 确认核心场景和判定口径，组织业务人员参与核对，复核问题处理结果，最终签字 | 确认后的场景清单与判定口径、签字验收记录 |
| 迁移执行方 | 准备样本数据，执行迁移与核对，记录问题并附证据，配合复测 | 样本清单、验收清单填写结果、问题清单、复测记录 |
| 系统管理员 | 准备目标环境、账号和权限，保障验收期间环境稳定，处理环境类问题 | 环境与账号准备记录、权限配置说明 |
| 问题跟踪责任人 | 汇总问题、定级、分派、跟踪复测直至关闭，维护问题状态 | 问题跟踪表、关闭确认记录 |
| 项目经理或迁移负责人 | 协调各方节奏，裁定争议项，确认切换条件是否满足 | 验收计划、切换决策记录 |
角色可以兼任，但职责要分开写清楚。业务负责人和迁移执行方由同一人担任时，签字环节应增加一名业务侧复核人。问题跟踪责任人建议独立于执行方，保证问题不被自行关闭。
问题记录和复测闭环适合放在工作项里跟踪：每条问题作为一个工作项，带上场景、检查项、严重程度、证据附件和责任人，状态从待处理走到已修复、待复测、已关闭。验收清单、判定口径和签字记录则放在文档中归档，与问题工作项互相引用。ONES 的项目工作项和 Wiki 文档可以承载这类记录，迁移场景中工作项、状态、字段、附件和历史记录本身也是迁移与核对的对象，验收记录与业务数据在同一套系统里便于追溯。
示例：一次版本发布场景的验收记录
以下为演示情景，用于说明清单如何填写，数据为虚构。
场景描述：版本发布记录迁移。源系统中某产品线最近3个版本，每个版本关联若干需求、缺陷和发布说明。验收目标是版本记录、关联工作项和发布说明在目标系统中完整可查。
样本选择：最近3个版本全量核对，涉及工作项共86条，附件12个，发布说明3篇。
| 检查项 | 判定口径 | 结果 | 证据 |
|---|---|---|---|
| 版本记录数量 | 3个版本全部存在，名称与发布日期一致 | 通过 | 目标系统版本列表截图 |
| 关联工作项 | 86条工作项全部关联到对应版本，无遗漏无错挂 | 不通过 | 导出比对表，发现2条缺陷挂在错误版本下 |
| 发布说明 | 3篇说明内容完整，格式正常 | 通过 | 页面链接与源文档对照 |
| 附件 | 12个附件可下载，文件名与大小一致 | 待确认 | 1个附件可下载但预览失败，待确认是否影响使用 |
| 历史记录 | 版本变更记录按时间可查 | 通过 | 操作历史截图 |
发现的问题按影响定级：2条缺陷错挂版本属于数据关联错误，定为中等级，由迁移执行方修正关联关系后复测；附件预览失败定为低等级，由系统管理员确认是否为文件格式兼容问题。两条问题均登记为工作项，指定责任人和处理时限，复测通过后关闭。
验收结论写法示例：“版本发布场景共5个检查项，3项通过，1项不通过已修复并复测通过，1项待确认且已确认不影响业务使用。场景结论为通过，遗留事项为附件预览问题，由系统管理员在观察期内跟进。”结论要写明检查项总数、通过情况、遗留事项和处理安排，避免只写“基本通过”。
切换风险控制与回退条件
验收结论要直接决定能不能切。核心场景全部通过，或有书面豁免并明确补偿措施，才具备切换条件；存在阻断性问题的场景未解决，应推迟切换，而不是带着问题上线再补。
切换窗口安排在业务低峰期，并设置冻结期：冻结期内源系统停止新增和修改业务数据，只允许查询，避免切换过程中产生两边不一致的数据。冻结期的起止时间、通知范围和例外审批方式在切换前确定。
回退条件要写成可判断的触发项，例如：核心场景在观察期内出现无法在约定时限内修复的阻断问题；关键数据出现批量丢失或错乱；权限问题导致业务信息越权可见。回退范围要明确是整体回退还是按模块回退，回退时源系统在冻结期内保持可写还是需要恢复写入，都要提前确认。回退方案至少完成一次桌面推演或演练，确认数据可恢复、账号可用、通知路径畅通。
观察期按业务节奏设定，通常覆盖一个完整的业务周期，例如一个迭代或一个月结周期。观察期检查项包括：核心流程是否正常发起和流转、关键报表数据是否与预期一致、用户反馈的问题是否集中在某类数据、回退条件是否被触发。观察期结束后形成关闭记录，迁移项目才算收尾。
验收未通过时的处置路径：区分问题类型，数据类问题由迁移执行方修复后复测，功能类问题评估是否属于迁移范围并给出替代方案，权限类问题由系统管理员调整配置。修复后重新执行对应场景的核对，更新验收清单，再提交业务负责人确认。若问题无法在切换窗口前解决，由项目经理和业务负责人共同决定推迟切换或缩小切换范围。
完成检查：验收通过前必须确认的事项
以下清单用于签字前的最后核对，逐项确认后才进入切换。
- 核心场景全部通过，未通过项均有书面豁免记录，豁免原因、影响范围和补偿措施写明。
- 遗留问题已登记，每条有责任人、处理时限和复测安排，阻断性问题为零。
- 业务负责人已签字，验收清单、问题清单和证据材料已归档，归档位置可被后续审计查到。
- 回退方案已演练或至少完成桌面推演，回退触发条件、回退范围和决策人明确。
- 切换窗口和冻结期已通知到相关业务方，例外审批方式已确认。
- 观察期检查项已分配到人，检查频率和记录方式确定，观察期结束的关闭标准写明。
- 切换后的支持渠道已就绪，用户遇到问题知道找谁、通过什么方式提交。
这份清单的价值在于把验收结论和切换动作绑定起来。任何一项没有确认，都应在切换决策记录中写明原因和风险接受人，避免问题在切换后才暴露。
常见问题
验收时核心场景已经跑通，但长尾历史数据还没核对完，可以先切换吗？
可以按风险分层处理，前提是分层规则在验收前已经书面约定。核心场景、核心字段以及涉及对外交付、合规的数据宜全量核对；长尾历史数据可以抽样，抽样比例和允许的差错范围提前定好。若长尾数据尚未核对完，应在验收记录中写明未覆盖范围、抽样结论和后续补核计划，由业务负责人确认这部分风险可接受后再进入切换。未核对且未评估影响的数据范围，不宜直接视为通过。
业务负责人不熟悉系统操作，签字环节怎么保证结论可信？
签字依据是验收清单和证据，不依赖签字人亲自操作。可以由业务骨干按真实路径执行核对并留下截图、导出比对表或操作录屏，业务负责人复核检查项结论、问题处理结果和遗留事项安排后签署意见。若业务负责人同时兼任迁移执行方，建议增加一名业务侧复核人，把执行与确认的职责分开。签字记录中写明检查项总数、通过情况、豁免项和遗留问题，便于后续审计追溯。
观察期内发现的问题，什么情况下应该启动回退？
回退触发条件要在切换前写成可判断的条目，常见的有：核心场景出现无法在约定时限内修复的阻断问题；关键数据出现批量丢失或错乱；权限配置导致业务信息越权可见。触发后由事先指定的决策人判断是整体回退还是按模块回退，并确认源系统在冻结期内是否保持可写、恢复写入需要哪些操作。观察期内的一般性问题按问题跟踪流程处理，达到触发条件才启动回退，避免因个别低影响问题反复切换。
验收未通过但切换窗口已经排定，应该怎么处置？
先按问题类型分流：数据类问题由迁移执行方修复后复测对应场景，功能类问题评估是否属于迁移范围并给出替代方案，权限类问题由系统管理员调整配置。修复后更新验收清单，再提交业务负责人确认。若问题无法在切换窗口前解决，由项目经理和业务负责人共同决定推迟切换或缩小切换范围，并把决定、原因和风险接受人写入切换决策记录。带着阻断性问题上线再补，会让观察期的问题判断失去基准。
验收记录和问题跟踪放在哪里，后续审计才查得到？
建议把两类记录分开存放并互相引用：验收清单、判定口径、签字意见和证据材料放在文档中归档，按项目或批次建立固定目录；每条问题作为独立工作项跟踪，带上场景、检查项、严重程度、证据附件、责任人和状态，从待处理走到已修复、待复测、已关闭。ONES 的项目工作项和 Wiki 文档可以承载这类记录，迁移场景中工作项、状态、字段、附件和历史记录本身也是核对对象，验收记录与业务数据在同一套系统里便于追溯。归档位置和访问权限在验收前确定，保证后续审计能查到完整链路。
