很多迁移方案写了工具和时间，却没有说明业务如何停止、由谁验证、失败后数据如何回退。迁移成功不只是虚拟机能够开机，还要求业务、监控、备份和日常运维全部完成接入。
READING NOTES
本文要点
- 按业务风险分批，不按虚拟机数量平均分批
- 第一批先验证工具与流程，核心业务最后迁
- 回退条件、数据处理和决策人必须在停机前写清楚
01｜先做源端盘点
先导出虚拟机清单，再补齐平台无法导出的信息：业务负责人、启停顺序、维护窗口、IP 依赖、授权绑定、备份策略、RPO/RTO 和验证方法。没有业务负责人确认的虚拟机，不应直接排入迁移批次。
- 虚拟硬件：CPU、内存、磁盘、控制器、网卡、BIOS/UEFI。
- 系统：操作系统版本、驱动、文件系统、静态 IP、时间同步。
- 业务：上下游依赖、集群关系、数据库一致性、停机顺序。
- 运维：监控、备份、安全代理、日志采集、定时任务。
02｜迁移批次怎样划分
第一批选能重建、低风险、有明确验证方法的系统，用来暴露驱动、网络和工具问题。第二批是普通业务，流程稳定后放量。数据库、授权绑定硬件、老旧系统和跨机集群放到最后单独演练。
| 批次 | 对象 | 主要目的 | 回退难度 |
|---|---|---|---|
| 试迁批 | 测试机、无状态服务 | 验证工具、驱动、网络和文档 | 低 |
| 普通批 | 一般业务系统 | 验证批量流程和多人协作 | 中 |
| 核心批 | 数据库、中间件、核心应用 | 在专项方案下完成正式切换 | 高 |
| 特殊批 | 老旧 OS、硬件授权、超大磁盘 | 单独制定技术路线 | 视场景而定 |
03｜切换当天按时间走
迁移窗口里不临时讨论流程。每个时间点谁下命令、谁确认数据、谁决定继续或回退，都提前写好。群里只同步状态，关键证据进迁移记录。
T-7d 兼容性、空间、驱动与回退演练
T-1d 最后同步，冻结配置变更
T0 业务停写，确认应用和数据库状态
T+15m 增量同步，目标端隔离启动
T+45m 系统、网络、业务、监控、备份验证
T+90m 决定继续运行或执行回退
T+7d 观察期结束，按审批回收源端04｜目标端验收不止看业务
业务负责人确认功能只是第一层。还需要检查时间同步、磁盘性能、网卡错误、监控告警、备份任务、安全代理和重启后的自启动。迁移当天正常但第二天备份失败，同样不能算交付完成。
FIELD NOTE迁移工具解决的是数据搬运，迁移方案解决的是业务风险。不要把这两件事混在一起。