
发布时间:2026-07-28 09:39:00
去年帮一个客户做迁移,对方是一家做电商SaaS的中型公司。他们的CTO跟我说了一句话让我印象很深:“我们不是不想上云,是不敢搬——万一搬坏了,几百个客户的数据就没了。 ”
这句话我记到现在。
服务器迁移,说白了就是“搬家”——从你机房里那台嗡嗡响的物理服务器,搬到AWS云端。但问题在于,这不是搬一箱书那么简单。搬错了,业务就断了。
今天这篇文章,我把这几年帮客户做迁移的经验全倒出来。不讲空话,全是能照着做的步骤。

很多团队一上来就装Agent、开复制,结果迁到一半发现选错了策略。
第一问:这台服务器到底值不值得迁?
Rehost(原样搬迁) :时间紧、任务重的时候选这个,最快
Replatform(小改动适配) :保留应用,但做一些调整让它在云上跑得更好
Refactor(重构) :只对业务核心系统做,投入大但回报也大
Repurchase(SaaS替换) :不迁了,直接用SaaS替代
Retire/Retain(淘汰/保留) :没用的系统直接淘汰,暂时动不了的先留着
一个实用的判断方法:问自己“这个系统未来有没有云原生的可能?”如果它迟早要被拆分成微服务或容器,那现在的Rehost只是临时方案,别把它当最终架构。
第二问:能停多久?能丢多少数据?
RTO:业务最多能停多久?30分钟?2小时?还是一天?
RPO:最多能丢多少数据?1分钟?5分钟?还是可以接受丢一天的数据?
第三问:如果失败了,怎么回来?
认证服务中断超过5分钟 → 立即回滚
交易失败率超过1% → 立即回滚
数据不一致 → 立即回滚
把迁移拆成四个阶段,每一步都走稳了再往下。
阶段 | 核心任务 | 关键产出 | 常见坑 |
评估 | 盘点服务器、梳理依赖关系 | 迁移清单、依赖图谱 | 漏掉了隐藏的依赖服务 |
准备 | 搭建AWS Landing Zone、配置网络 | VPC、子网、安全组 | 网络不通,复制失败 |
复制与测试 | 安装Agent、数据同步、测试启动 | 测试实例、验证报告 | 测试不充分,切的时候出问题 |
切换与稳定 | DNS切换、监控、优化 | 上线确认、成本报告 | 没有回滚计划,切不回来 |
AWS Application Migration Service(MGN)是官方推荐的迁移工具,提供高度自动化的直接迁移解决方案。
第1步:初始化MGN

在目标区域打开AWS MGN服务,完成初始化设置。
第2步:安装复制Agent

在源服务器上安装AWS复制代理。注意:确保源环境能稳定访问AWS,最常见的障碍是出口限制、代理和TLS检查干扰了HTTPS连接。
第3步:配置启动设置
在MGN中配置目标实例的类型、子网、安全组等。
第4步:执行测试启动
这一步千万别跳过。先启动一个测试实例,验证所有功能正常。确认没问题了,再切生产。
第5步:正式切换(Cutover)
在约定的停机窗口内,停止源服务器,启动目标实例,切换DNS。
AWS不支持在VPC之间直接迁移EC2实例。但有两种方法可以做到:
方法一:使用AWSSupport-CopyEC2Instance自动化文档
打开AWSSupport-CopyEC2Instance页面
方法二:手动操作
注意事项:对于没有现有快照的大型文件系统,创建AMI可能需要数小时。如果源实例已加入域,创建AMI前先用Sysprep工具或先将实例从域中移除,避免SID冲突。
说实话,迁移工具谁都会用——点几下按钮的事。但真正难的是迁移前的评估和迁移后的优化。
我们见过太多案例:
该淘汰的服务器被原封不动搬上云,每月白花几百美金
依赖关系没梳理清楚,切过去才发现API调不通
测试不充分,上线当天出问题,客户电话被打爆
一个好的迁移项目,70%的精力花在准备阶段,20%花在测试,只有10%花在真正的切换上。
如果你正准备做迁移,我的建议是:别急着动手,先花一周把评估做好。磨刀不误砍柴工。
如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议,他们有国际阿里云,国际腾讯云,国际华为云,aws亚马逊,谷歌云一级代理的渠道,客服1V1服务,支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。