上个月，一个做了十年传统IT的朋友找我喝酒。他们公司终于决定“上云”，老板下了死命令：年底前把所有业务从自建机房搬到云上。

我问：“你们准备怎么搬？”

他说：“找了几家迁移服务商报了价，准备选个便宜的，周末直接搬，周一前搞定。”

我差点把酒喷出来。

“你们机房有多少台服务器？”

“两百多台。”

“跑着什么业务？”

“ERP、CRM、官网、邮件系统，还有几个内部工具。”

“数据库呢？”

“MySQL和SQL Server都有，有些是老旧版本，跑在Windows Server 2008上。”

我放下酒杯：“你知道这有多大概率会出事吗？”

他沉默了一会儿：“所以我才找你喝酒。”

今天聊聊云迁移。不是那种“上云好处多”的废话，而是帮你理清楚：怎么评估、怎么规划、怎么执行，以及怎么避开那些能让你周末加班的坑。

01 先破除几个幻觉

幻觉一：上云就是省钱。

这是最普遍的误解。云计算的计费模型是OPEX（运营支出），机房是CAPEX（资本支出）。CAPEX是一次性投入，买完就是你的；OPEX是按月交钱，用多少付多少。

如果业务稳定、负载可预测，自己买服务器用五年，算下来可能比云便宜。云的优势在于弹性——业务涨了能扩，跌了能缩。如果你迁移后还是按峰值买实例，24小时开着，那大概率比自建机房还贵。

幻觉二：直接搬过去就行。

有人觉得云就是“别人家的机房”，把服务器镜像传上去就能跑。这叫“抬升和移位”（Lift and Shift），技术上可行，但往往是灾难的开始。

老应用可能依赖特定硬件、特定网络拓扑、特定操作系统版本。上云后性能下降、莫名其妙报错、连不上数据库——这些坑我见过太多次。

幻觉三：迁移窗口越长越安全。

有些团队把迁移拉长到半年甚至一年，想着慢慢来，双轨运行，出了问题可以回滚。

但双轨运行的成本是双倍的——要同时维护两套环境，付两份钱，团队精力被分散。拖得越久，消耗越大，最后骑虎难下。

02 迁移四阶段：别跳步

第一阶段：评估

这是最容易被跳过的，也是最重要的。

• 盘点资产：多少台服务器？什么配置？跑着什么应用？依赖关系是什么？

• 分类定级：哪些是核心业务？哪些可以接受短暂停机？哪些有合规要求？

• 确定迁移策略：下面会细说。

评估阶段要出的成果是一张迁移清单，每台服务器、每个数据库、每个依赖项都列清楚，标注优先级和迁移方式。

第二阶段：规划

• 选目标Region和AZ：用户在哪？合规要求什么？灾备怎么做？

• 网络设计：VPC怎么划？要不要建专线？VPN带宽够吗？

• 数据同步方案：全量复制还是增量同步？停机窗口多长？

• 回滚计划：万一失败了怎么退回来？数据一致性怎么保证？

• 排期：先搬非核心练手，再搬核心业务。千万别上来就动ERP。

第三阶段：执行

• 搭建目标环境：按规划把VPC、子网、安全组建好。

• 数据迁移：用云厂商的工具（AWS DMS、阿里云数据传输服务）做数据同步。

• 应用迁移：按迁移策略（Rehost、Replatform、Refactor）搬应用。

• 验证测试：功能测试、性能测试、安全测试，一样不能少。

第四阶段：优化

搬上去只是开始。云上要持续优化：

• 缩容：原来按峰值买的实例，可以降配了。

• 弹性配置：设好自动伸缩，应对业务波动。

• 成本监控：开预算告警，别等账单出来才傻眼。

03 迁移五种策略：选对的不选贵的

云迁移有经典的五种策略（行业叫“5R”），对应不同的投入产出比。

1. Rehost（重新托管）—— 直接搬

把服务器镜像原封不动搬到云上，用云主机跑。最快，但可能性能差、成本高。适合非核心系统、临时过渡。

2. Replatform（更换平台）—— 改一点再搬

不改代码，但换用云上的托管服务。比如自建MySQL改成RDS，自己搭的Redis改成云Redis。省了运维，性能提升，性价比高。适合大部分业务系统。

3. Refactor（重构）—— 改了再搬

改代码，让应用能利用云原生能力。比如把单体拆成微服务、用Lambda代替部分逻辑。投入最大，收益也最大。适合核心业务、长期战略。

4. Repurchase（重新购买）—— 换套软件

SaaS化替换。比如自建CRM换成Salesforce，自建邮箱换成企业微信。最快，但可能有数据迁移和定制化问题。

5. Retire（退役）—— 直接关掉

盘点时发现有的系统根本没人用，直接关机，最省钱。

没有哪个策略永远正确，关键看业务价值和技术债务的平衡。

04 迁移中的四个关键坑

坑一：网络带宽估算错误

数据量估算失误，导致同步时间远超预期。1TB数据，10Mbps带宽，理论上传需要9天。很多人忘了算这个账。

解法：提前做数据量统计，按实际带宽算时间，留够缓冲。数据量大的考虑用物理传输设备（AWS Snowball、阿里云闪电立方）。

坑二：依赖关系漏了

迁移完A系统，发现它要连B系统的内网IP，但B还没搬，IP变了，连不上。

解法：评估阶段画好依赖关系图，按依赖顺序迁移。或者先打通网络，用VPN把云上和机房连成一张网，逐步切流。

坑三：数据一致性出问题

增量同步过程中，两边都在写数据，最后切过去发现数据对不上。

解法：用数据库同步工具（DMS、DataX）做双向同步，切流前做数据校验，确保两边一致才切。

坑四：回滚时没退路

迁移到一半发现有问题，想回滚，结果发现数据已经覆盖了，回不去了。

解法：迁移前打好全量快照，切流前做完整备份，回滚路径提前演练一遍。

05 迁移案例：一步错步步错

三年前帮一个客户复盘失败的迁移。他们从自建机房搬到云上，踩了所有能踩的坑：

• 没做评估，直接找外包按“台数”报价

• 选了最便宜的Rehost，老系统带着十几年的配置搬上去

• 带宽没算，20TB数据预估3天，实际用了两周

• 依赖关系漏了，搬完ERP发现连不上财务系统

• 回滚没演练，出问题后花了三天才恢复

最后项目延期三个月，成本超预算两倍，团队累垮三个人。

后来重做时换了策略：先用Replatform把数据库迁到RDS，应用层分批重构，网络走专线，数据用DMS同步。三个月平稳落地，成本比原来机房还低20%。