公司老机房快撑不住了，新云平台也买好了，可一打开迁移方案文档，满屏的‘平滑迁移’‘灰度发布’‘双写同步’，看得人脑壳疼。其实真没必要被术语绕晕，迁移这事，核心就看三件事：业务能不能停、数据能不能丢、人手够不够用。
先分清楚是哪种迁
不是所有迁移都叫‘上云’。有的是旧服务器换新硬件，有的是从VMware搬到K8s，还有的是把Oracle数据库挪到MySQL——每种动的筋骨不一样，技术路线自然不同。
比如，一个内部OA系统，每月只更新两次补丁，用户量不到500人，晚上停机两小时没人投诉。这种直接选‘停机迁移’最省事：
备份数据库 → 关服务 → 拷配置文件 → 启新环境 → 验证登录和流程 → 开放访问。全程脚本化，半天搞定。
数据不能乱动，得有节奏
但要是电商订单库，每秒几十笔下单，停机等于丢钱。这时候就得走‘增量同步+切换验证’路线。常见做法是：
1. 先全量导出旧库（mysqldump -h old-db ...）
2. 导入新库，启动binlog监听
3. 用Canal或Debezium捕获旧库变更，实时写入新库
4. 切流量前比对两边最新10万条订单ID和金额这过程听着复杂，其实工具链早跑熟了。关键是每次同步后，必须人工抽样查几笔真实订单，比如查一笔昨天下午3:17下的手机壳订单，确认新库能查到、状态对、库存扣减没出错。
网络连通性常被忽略
去年帮一家做教育SaaS的客户迁移，应用层一切正常，结果第三方微信回调总失败。排查两小时才发现：新VPC没开8080端口的入方向规则，而微信服务器固定从这个端口回传支付结果。技术路线里如果漏掉‘网络策略映射表’这一项，再好的架构也白搭。
建议迁移前拉个表格，左边列所有对外调用的域名和端口（比如api.wechat.com:443、pay.alipay.com:443），右边填新环境对应的安全组/ACL规则，一条条打钩确认。
别迷信全自动，人盯关键点
有些厂商推‘一键迁移平台’，界面炫酷，进度条拉满。但实际遇到Oracle大表分区不兼容、自定义存储过程语法报错、甚至Linux内核版本差异导致ioctl调用失败……这些坑，工具不会主动喊你。真正靠谱的技术路线，一定留出‘人工卡点’：比如全量同步完成后暂停，DBA手动执行SELECT COUNT(*)对比；切流前运维登录新机器敲top看CPU是否突增；第一波用户进来后盯着日志grep 'ERROR'五分钟。
迁移不是交卷考试，是边跑边调的实操活。路线图上多标几个手写备注，比如‘此处等财务确认发票模块可用’‘测试环境先跑三天慢查询’，比堆十个高大上的架构图管用。