企业云迁移不是把服务器镜像复制到公有云。真正的迁移项目要同时处理应用依赖、数据一致性、身份权限、网络、可观测性、成本、发布窗口和回滚路径。任何一项被留到切换当天，都会把技术问题变成业务风险。
一次可控的云迁移，必须在切换前证明三件事：新环境能承载业务、故障能够被看见、失败可以安全回退。
一、先定义迁移目标和验收标准
“上云”不是可以验收的目标。每个工作负载应有明确结果，例如缩短发布周期、覆盖新的海外地区、支持弹性峰值、提升恢复能力、统一监控或降低三年总拥有成本。
建议同时定义五组指标：
| 指标组 | 示例 |
|---|---|
| 业务 | 可接受停机窗口、关键交易成功率、用户体验 |
| 性能 | 吞吐、P95/P99 时延、并发、批处理完成时间 |
| 可靠性 | 可用性、RTO、RPO、备份恢复时间 |
| 安全 | 身份权限、数据边界、日志覆盖、密钥管理 |
| 成本 | 月度预算、单位业务成本、网络费用、运维工时 |
只有目标和验收标准确定后，团队才能决定迁移策略、波次和投入。
二、阶段 1：资产盘点与依赖发现
盘点范围不能只有服务器数量。至少覆盖：
- 应用、服务、域名、证书、定时任务和消息队列
- 数据库、缓存、对象存储、文件共享和备份
- 用户、角色、服务账号、密钥与第三方凭据
- 上下游 API、支付、登录、短信、邮件、MMP 等外部依赖
- 日常与峰值资源、版本、生命周期和许可证
- 数据级别、驻留要求、访问范围与保留期限
- 负责人、业务重要度、维护窗口和已知风险
通过流量、日志和配置生成依赖图，并让业务负责人确认。最危险的依赖往往是“大家知道但文档里没有”的脚本、白名单、固定 IP 或人工操作。
三、阶段 2：为每个工作负载选择迁移策略
AWS Migration Lens 使用常见的 7R 迁移分类。企业可以采用同一思路为每个应用确定路径，而不是“一刀切”。
| 策略 | 说明 | 适合情况 |
|---|---|---|
| Retire | 下线不再需要的系统 | 无用户、重复或已被替代 |
| Retain | 暂时保留原环境 | 合规、生命周期或依赖尚不允许迁移 |
| Rehost | 基本不改架构直接迁移 | 时间紧、依赖清楚、先搬后优化 |
| Relocate | 迁移完整虚拟化环境 | 希望减少应用层改动 |
| Replatform | 小幅改造并使用部分托管服务 | 希望降低运维但控制改造量 |
| Repurchase | 更换为新的 SaaS 或产品 | 自建系统缺乏长期价值 |
| Refactor | 重构为云原生架构 | 业务长期增长且改造收益明确 |
策略应记录决策依据、改造量、停机窗口、成本、回滚方式和负责人。不要把“云原生”当成所有系统的默认答案。
四、阶段 3：先建 Landing Zone，再接生产业务
Landing Zone 是承载生产工作负载的治理底座，应至少包含：
组织与账号
按企业、业务、环境和成本中心设计组织层级；生产、测试、安全与共享服务隔离；关键账号和账单归属企业。
身份与权限
接入统一身份，启用多因素认证；遵循最小权限；人和服务账号分离；高权限操作有审批和审计。
网络与入口
确定 VPC/VNet、子网、路由、NAT、专线或 VPN、DNS、证书、WAF、负载均衡和出口控制。提前处理 IP 白名单和第三方回调。
安全与日志
配置密钥、漏洞、配置策略、安全日志、审计日志和日志保留。日志必须集中、可检索并有责任人。
账单与资源规范
建立标签、预算、异常费用告警、资源规格和区域准入。资源创建规范应在迁移前生效，而不是迁移后补治理。
Google Cloud 的 Landing Zone 指南也把身份、资源层级、网络、安全、日志与监控作为核心基础能力。
五、阶段 4：按依赖组设计迁移波次
迁移顺序建议按“低风险试点—内部系统—一般生产—核心链路”逐步推进。Microsoft Cloud Adoption Framework 强调根据依赖关系形成迁移组，再排成迁移波次。
每个波次都应明确：
- 范围、负责人、维护窗口和沟通对象
- 数据同步方式、完整性校验和最终增量
- 应用部署、配置、密钥和域名切换步骤
- 监控面板、告警、业务验证和用户验证
- 回滚触发条件、回滚负责人和最晚决策时间
- 切换后的观察期和旧环境保留期限
先从代表性系统学习，能暴露权限、网络、镜像、日志和流程问题，但试点不能只选“最简单、没有真实依赖”的演示应用。
六、阶段 5：数据迁移与一致性控制
数据迁移方案取决于数据量、变更速度、停机窗口和网络路径。
| 方案 | 特点 | 重点风险 |
|---|---|---|
| 离线导入 | 结构简单，适合可停机系统 | 数据冻结、窗口超时、恢复验证 |
| 全量 + 增量同步 | 先复制存量，再追平变化 | 延迟、重复、顺序和最终校验 |
| 双写/双读 | 可逐步切流 | 一致性、补偿、实现复杂度 |
| 物理设备传输 | 适合超大数据集 | 加密、链路时间和最后增量 |
数据库切换前要验证表数量、行数、校验和、关键业务聚合指标，并演练从备份恢复到可提供服务的完整时间。备份“成功生成”不等于“可以恢复”。
七、阶段 6：切换、灰度和回滚
切换前至少进行一次完整彩排。正式窗口可按以下顺序执行：
- 冻结高风险变更并确认相关人员在线
- 检查新环境容量、配额、证书、密钥与监控
- 完成最终增量同步和数据校验
- 通过灰度流量或受控用户验证核心链路
- 调整 DNS、负载均衡或流量策略逐步放量
- 监控技术指标与业务指标，记录每个决策点
- 达到验收标准后继续观察，未达到则按阈值回滚
回滚计划不能只写“切回旧环境”。必须说明新环境产生的数据如何处理、旧环境是否仍可写、域名 TTL 如何设置、第三方回调如何恢复，以及谁有权做最终决定。
AWS Migration Lens 建议在切换前测试高可用、容错和灾难恢复，并为重大迁移保留回滚计划。
八、阶段 7：迁移后 30 天稳定化
迁移完成不是项目结束。建议设置 30 天稳定化阶段：
第 1—3 天
重点看错误率、时延、业务成功率、日志完整性、容量和异常费用；保留快速回滚能力。
第 4—14 天
修复告警噪音、资源规格、自动扩缩容、备份任务和权限问题；完成运维交接与应急演练。
第 15—30 天
进行成本基线、闲置资源、承诺用量、架构优化和旧环境下线评审；更新架构图、运行手册、资产和责任人。
不要在验证期结束前删除旧数据和回滚资产，也不要在业务尚未稳定时同时推进大规模重构。
九、迁移项目的常见失败模式
- 只盘点服务器，没有发现业务依赖
- 在个人账号或临时项目中直接建设生产环境
- 权限、日志、预算和备份等到上线后再补
- 测试只看接口返回，没有验证业务数据和用户体验
- 高峰前没有申请配额，也没有完成容量压测
- 只准备迁入方案，没有数据出口和回滚方案
- 所有系统同一周切换，团队无法并行排错
- 迁移后继续保留双份资源，却无人负责下线和成本
十、迁移验收清单
- 核心业务流程、支付、登录、通知和第三方回调通过验证
- 性能、错误率和容量达到预设标准
- 日志、监控、告警、值班和升级路径已生效
- 备份恢复、故障切换和回滚完成演练
- 身份、权限、密钥和审计符合要求
- 成本标签、预算和异常费用告警可用
- 架构图、运行手册、资产清单和责任人已更新
- 旧环境保留、只读、归档与下线日期明确
官方框架参考
如果需要根据现有应用、数据库、目标地区和停机窗口制定迁移波次，可通过海外云与 AI 模型服务提交架构与需求，获得云咨询、资源交付、迁移实施、监控容灾和持续优化支持。
