迁移切换计划要回答三个问题：什么时候切、切到什么程度算通过、出问题怎么退。本文按切换范围、准入条件、试迁移校验、业务验收与并行、切换窗口执行、回退预案、切换后收尾的顺序展开，适用于从来源系统向目标系统迁移研发数据与协作记录的团队，帮助把切换从一次性动作变成有证据、有停止点的受控过程。
要点总览（TL;DR）
- 切换计划先固定“来源系统→目标系统”的方向，列清对象清单与不迁移边界，并给每个角色指定备份人。
- 试迁移校验分四层：总量比对、分层抽样逐字段核对、附件与富文本实际打开验证、状态与关联关系抽查，差异分级登记。
- 业务验收由业务方用典型流程用例确认可用，并行期明确唯一写入源与比对频率，三项判定标准同时满足才进入切换窗口。
- 切换当天按冻结写入→增量迁移→校验→开放访问→值守的顺序执行，每步设完成标志，未达成不进入下一步。
- 回退触发条件用可观察事实和阈值描述，预设决策人与时限，回退后保留目标系统数据并复盘，明确再次切换的前置条件。
来源、目标与本次切换范围
切换计划的第一页应当是一份范围说明，写清迁移方向、系统环境和对象边界。方向必须固定为“来源系统→目标系统”，并在全文统一使用这两个称呼，避免在后续步骤中出现“从新系统导回旧系统”这类方向颠倒的表述。来源系统与目标系统分别注明产品名称、版本号与所处环境（生产、预发或测试），因为版本差异会影响字段可用性和附件存储方式。
迁移对象清单按类型逐项列出，常见包括：工作项（需求、任务、缺陷）、迭代与版本、附件、评论、状态与工作流节点、自定义字段及其选项值。清单中每一项标注“本次迁移”“本次不迁移”或“迁移但需人工处理”，例如历史附件中体积超限的文件可归入第三类，由业务方在切换后按需补传。
边界部分要明确写出本次切换不包含的内容。字段映射规则与映射表设计属于迁移设计阶段的工作，本计划只引用其确认结果，不在此展开。同样，切换后的人员推广、使用规范治理也不在本次范围内。边界写得越具体，切换当天的争议越少。
责任人按角色列出，通常包括：迁移负责人（统筹计划与决策）、数据校验人（执行比对与记录差异）、业务验收人（确认流程可用）、系统管理员（账号权限与环境）、沟通负责人（通知与值守排班）。每个角色写明姓名与备份人，避免切换窗口内出现无人决策的空档。
交付物是一页式切换范围说明，包含四块内容：来源与目标（含版本环境）、对象清单及处理方式、不包含事项、角色与责任人。这一页在切换启动会上确认后即冻结，后续变更需记录变更原因与批准人。
切换前的输入与依赖清单
范围界定之后，需要判断“现在是否具备进入切换的条件”。做法是把所有前置条件列成准入检查表，逐项标注“已具备”“待补齐”和“不适用”，只有全部关键项为“已具备”才允许进入切换窗口。检查表建议包含以下条目：
- 试迁移已完成，校验记录中的差异项已分级，高等级问题已关闭或有明确处理方案；
- 字段映射表与数据清洗规则已经业务方和技术方共同确认，清洗脚本在试迁移环境跑通；
- 目标系统的组织架构、账号与权限已按来源系统人员对应关系建好，关键角色（项目管理员、空间管理员）权限验证通过；
- 并行运行所需的人力已排班，比对人员明确自己负责的项目范围与比对频率；
- 通知已发出，来源系统的写入冻结时段已与各业务团队确认，冻结期间的新增数据有临时登记方式；
- 切换窗口内的值守人员、沟通渠道（群组或会议桥）已确定。
检查表中每一项都应附证据位置，例如“试迁移校验记录表第 3 版”“映射表确认邮件”，便于在启动会上快速核对。对于“待补齐”项，写明补齐责任人与最晚完成时间；若某项在切换窗口前无法补齐，需要由迁移负责人判断是否降级处理或推迟切换，判断结论记入检查表备注。
试迁移与完整性、附件校验方法
试迁移的价值在于用真实数据暴露问题，校验方法要能回答“迁移结果是否可信”。建议从四个层面核对，每个层面都留下书面记录。
总量比对
按对象类型统计来源系统与目标系统的数量：工作项总数、各类型工作项数量、迭代数量、附件数量、评论数量。差异为零或差异有合理解释（如已标记不迁移的条目）才算通过。数量比对只能发现“少了或多了”，不能证明内容正确，因此必须配合抽样。
抽样比对
按项目、创建时间、状态三个维度分层抽样，覆盖活跃项目与已归档项目、近期数据与历史数据、各主要状态。每个样本逐字段核对：标题、描述、负责人、状态、优先级、截止日期、自定义字段值。抽样比例可按数据量设定，例如每层抽取 20 条，总样本不少于 100 条；高风险项目可全量核对关键字段。
附件与富文本校验
附件检查三项：能否下载、能否在线预览、文件名与大小是否与来源一致。富文本描述中的图片要确认已随文迁移并可显示，超链接要确认指向正确。建议从每个项目抽取若干条带附件的记录实际打开验证，而不是只看附件计数。
状态、关联关系与历史记录
检查工作流状态是否落在正确节点，父子任务、关联缺陷、需求与迭代的归属关系是否保留，评论的时间顺序与作者是否正确，变更历史是否可追溯。关联关系断裂往往在业务使用中才被发现，试迁移阶段应专门抽查跨项目关联和跨类型关联。
所有差异记入试迁移校验记录表，字段包括：差异编号、对象类型、对象标识、差异描述、影响范围、等级（阻断/严重/一般）、处理结论、责任人。阻断级差异指关键数据缺失或核心流程无法走通，必须在切换前关闭；一般级差异可带入切换后跟踪，但需在记录表中注明关闭时限。
校验记录需要有承载位置。在 ONES 中，可以把每条差异登记为工作项，用状态流转标记“待处理—处理中—已关闭”，附件与截图直接挂在记录上，校验人和业务验收人在同一处查看证据，减少表格版本分散带来的核对成本。
业务验收与并行运行安排
数据校验通过只说明“数据在”，业务验收要确认“能用”。验收由业务方主导，迁移团队配合，验收用例应覆盖典型场景：新建一个需求并流转到完成、提交一个缺陷并关联到迭代、上传附件并在详情页预览、按状态筛选工作项、查看历史评论。每个用例写明预期结果与实际结果，验收人签字确认。
并行运行是切换前风险最低的验证方式。安排一段并行期，两套系统同时可用，业务人员在来源系统继续日常操作，比对人员按固定频率核对两边结果。并行安排表应写明：并行时长（按团队规模与业务复杂度确定，常见为一至两周）、比对对象（新增工作项、状态变更、评论、附件）、比对频率（如每日一次）、比对人与差异上报路径。
并行期必须明确写入规则，否则双写会造成数据混乱。通常做法是：并行期内以来源系统为唯一写入源，目标系统只读用于比对；确需在目标系统试操作的，使用专门的测试项目，不进入正式数据范围。若业务方希望在目标系统提前开始工作，则需改为“目标系统为准、来源系统只读”，并在并行安排表中明确切换这一规则的时点。
验收判定标准提前写清：全部验收用例通过、并行期比对差异均为一般级且已记录、无阻断级问题遗留，三项同时满足才算验收通过。任一项不满足，验收结论为“不通过”，列出整改项与复验时间，不进入切换窗口。
切换窗口与执行步骤
切换窗口的选择依据有三条：来源系统写入冻结的时段、业务低峰期、通知已送达并被确认。冻结时段要覆盖最终增量迁移与校验所需的全部时间，并留出缓冲；窗口最好安排在工作日业务量较低的时段，便于出现问题时有业务人员配合验证。
切换当天按固定顺序执行，每一步都有执行人、预计耗时和完成标志：
| 步骤 | 动作 | 执行人 | 完成标志 |
|---|---|---|---|
| 1 | 冻结来源系统写入，通知各团队 | 系统管理员 | 冻结公告发出，来源系统写入受限 |
| 2 | 执行最终增量迁移 | 迁移执行人 | 迁移任务完成，无报错 |
| 3 | 增量数据校验（总量+关键样本） | 数据校验人 | 校验记录签字，差异在阈值内 |
| 4 | 开放目标系统访问，通知切换完成 | 沟通负责人 | 通知送达，关键用户登录成功 |
| 5 | 值守观察，处理首轮反馈 | 值守人员 | 观察期结束，问题清单形成 |
每步之间设置确认点：上一步完成标志未达成，不进入下一步。切换当日安排值守，值守人员覆盖迁移、系统管理和业务代表三类角色，沟通渠道保持畅通，问题按“阻断/一般”分级响应，阻断级问题立即上报回退决策人。
回退条件、回退步骤与停止点
回退预案要在切换前写好并经过评审，而不是等出问题再讨论。触发条件用可观察的事实描述，例如：关键对象类型数据缺失超过约定阈值、附件批量不可下载或不可预览、核心流程（如需求流转、缺陷提交）在目标系统无法完成、目标系统登录或访问持续异常超过约定时长。每个条件对应明确的阈值和观察时点。
回退决策人通常为迁移负责人，备份决策人为业务验收负责人；决策时限写明，例如阻断级问题确认后 30 分钟内作出回退或继续的决定。回退步骤按顺序执行：停止目标系统写入并通知用户、恢复来源系统写入权限、保留目标系统已有数据不做删除（供复盘分析）、通知相关方回退结果与后续安排、确认来源系统业务恢复正常。
回退预案卡建议包含：触发条件清单、决策人与时限、回退步骤、恢复确认项（来源系统可写、关键用户可登录、业务操作正常）、复盘要求。回退后必须复盘，分析触发原因，明确再次切换的前置条件，例如修复特定缺陷、补充校验样本、调整切换窗口时长，条件满足后方可重新排期。
切换后的核验与收尾
切换完成不等于项目结束。首日核验聚焦可用性：关键用户能否登录、权限是否与来源系统一致、核心流程能否走通、附件能否打开、通知是否覆盖全部使用团队。首周核验聚焦稳定性：新增工作项是否正常流转、有无集中反馈的字段或流程问题、并行期遗留差异是否按计划关闭。
建立固定的反馈渠道，例如指定群组或每日短会，明确问题上报格式（现象、影响范围、复现步骤）与响应时限。所有反馈登记为问题项，指定责任人与关闭时间，阻断级问题当日响应，一般问题按约定周期处理。
遗留差异项从试迁移校验记录表延续过来，逐项跟踪至关闭，关闭时附验证证据。切换完成的判定标准提前写明，通常包括：首日核验项全部通过、首周无阻断级问题、遗留差异关闭率达到约定比例、来源系统写入冻结解除或按计划只读。完成判定后归档材料：切换范围说明、准入检查表、试迁移校验记录、业务验收结论、并行比对记录、切换执行时序表、回退预案卡、切换后核验清单与问题关闭记录。归档位置与查阅人一并记录，供后续类似迁移复用。
常见问题
试迁移校验发现差异，哪些必须在切换前关闭，哪些可以带到切换后跟踪？
按影响程度分级处理。阻断级差异指关键数据缺失或核心流程无法走通，例如主要对象类型数量明显不符、附件批量不可下载、需求流转在目标系统无法完成，这类差异必须在切换窗口前关闭。严重级差异影响部分用户或非核心字段，应尽量在切换前修复，无法修复的需写明影响范围和临时应对方式。一般级差异如个别字段格式不一致、少量评论顺序偏差，可以带入切换后跟踪，但要在校验记录表中注明关闭责任人与时限，并在切换后核验阶段逐项确认关闭。
并行运行期间，业务团队已经在目标系统开始操作，写入规则怎么调整？
并行期只允许一个写入源，规则切换要有时点记录。常见做法是并行前期以来源系统为唯一写入源、目标系统只读比对；如果业务方希望提前在目标系统工作，需要由迁移负责人确认后，把规则改为“目标系统为准、来源系统只读”，并在并行安排表中写明切换时点、通知范围和比对方式随之调整。切换规则后，来源系统的新增数据不再纳入比对范围，比对重点转为目标系统内部的数据一致性与流程可用性。无论采用哪种规则，都要避免两套系统同时接受正式业务写入。
切换窗口内增量迁移和校验时间超出预期，应该压缩校验还是推迟开放访问？
优先保证校验，推迟开放访问。校验是判断数据是否可信的唯一依据，压缩校验等于把风险带到切换后。可行的处理顺序是：先评估超出预期的原因，若增量数据量大于预估，可延长冻结时段并通知业务团队；若校验发现差异需要处理，由迁移负责人判断差异等级，阻断级差异未解决时不开放访问，必要时启动回退决策流程。开放访问时间推迟要同步通知关键用户，避免用户在不知情的情况下继续在来源系统写入。
回退之后，目标系统里已经产生的数据怎么处理？
保留不删除，用于复盘分析。回退步骤中明确停止目标系统写入并恢复来源系统写入权限，目标系统已有数据原样保留，便于比对回退前后的差异、定位触发回退的具体原因。复盘时结合切换执行时序表、校验记录和问题清单，确认是数据问题、流程问题还是环境问题，并把结论转化为再次切换的前置条件，例如修复特定缺陷、补充校验样本、调整窗口时长。目标系统数据在再次切换前是否清理或重置，由迁移负责人根据复盘结论决定并记录。
切换完成后，遗留差异项关闭到什么程度才算项目收尾？
在切换前就把关闭率写进完成判定标准，避免收尾阶段反复拉扯。通常的判定包括：首日核验项全部通过、首周无阻断级问题、遗留差异关闭率达到约定比例、来源系统写入冻结按计划解除或转为只读。未关闭的差异项要有明确的责任人、计划关闭时间和影响说明，作为收尾记录的附件一并归档。归档材料包括切换范围说明、准入检查表、试迁移校验记录、业务验收结论、并行比对记录、切换执行时序表、回退预案卡和切换后核验清单，归档位置与查阅人一并记录，供后续类似迁移参考。
