迁移之前，
先把这 8 件事确认掉

迁移的成败往往在动手之前就定了。下面这 8 项按实际排障顺序排列，前 4 项决定窗口能不能守住，后 4 项决定切过去之后会不会出问题。每一项都对应一次真实的翻车场景。

1. 01

   算清数据量与可用带宽

   先量出实际数据量（不含日志和缓存）和两端之间的可用带宽，再算传输时间。100GB 在 10Mbps 上要跑 22 小时以上，这个数字直接决定要不要停机、要不要分批。

2. 02

   把 DNS TTL 提前降下来

   切换前 24–48 小时把 TTL 调到 60 秒。如果一直是 3600 秒，改完解析要等一小时才生效，回滚同样要等一小时——这是最容易被忽略、代价最高的一项。

3. 03

   列全依赖，不只是代码

   数据库、对象存储、证书与私钥、定时任务、消息队列、外部回调地址、白名单 IP。漏掉证书会导致切完立刻全站 HTTPS 报错，漏掉回调会导致支付或推送静默失败。

4. 04

   定好回滚方案

   旧环境保留多久、数据往哪个方向同步、回滚触发条件是什么。没有回滚方案的迁移不是迁移，是赌博。至少要保证切回旧环境的操作有人演练过一次。

5. 05

   确认备案与合规

   换服务商、换地域是否影响备案主体和接入信息，香港与海外节点不涉及 ICP 备案但可能涉及数据出境。这一步要在买资源之前问，不是买完之后。

6. 06

   梳理所有对外 IP

   除了域名，还有第三方白名单、回调地址、监控探针、合作伙伴的固定 IP 信任。换 IP 之后这些不会自己更新，需要逐个通知或重新登记。

7. 07

   先补监控，再切流量

   新环境的监控、日志、告警要在切换前就跑起来。切过去才发现没配告警，等于盲飞。至少要有 CPU、内存、磁盘、负载和一条业务探活。

8. 08

   按只读 → 灰度 → 全量的顺序切

   先让新环境接只读流量验证数据一致性，再按比例灰度，最后全量。每一步都观察一轮再往下走，比一次性切换安全得多，也多不了多少时间。

三个反复出现的坑

需要人搭把手的时候

如果现有架构复杂、或者没人能全程盯着迁移窗口，可以按项目评估范围与费用。通常的做法是：先做一次现状梳理和风险评估，出一份可执行的迁移清单，再决定是自己动手还是委托实施。