迁云方案看起来完整，真正切换时却可能卡在一条没登记的定时任务、一份过期证书，或一项云端未开放的网络规则。准备网站从本地机房迁移到云端的评估清单时，先把依赖、数据、网络、运维和退出方案查全，再决定云上资源规格；只按旧服务器的 CPU 和内存照搬，往往不足以判断实际需求。
先查清网站离不开什么
把应用依赖逐项列出来
从网站入口向后梳理：Web 服务、应用进程、数据库、缓存、文件存储、邮件发送、支付或身份验证接口，以及计划任务。记录每项的版本、连接地址、端口、凭据保管位置和负责人。例如，使用 Nginx 的站点要确认配置文件、反向代理规则和证书续期方式；使用 PostgreSQL 的应用则要核对数据库版本、扩展、字符编码和连接数设置。不能只记录“有数据库”，却漏掉依赖的扩展或定时备份。
可从配置文件、服务清单、计划任务和防火墙规则交叉核对。对不确定的外部连接，查看一段有代表性的访问日志或网络流量记录；不要把凭据直接复制到清单中，记录其安全存放位置即可。
用实际负载而非峰值规格估算
收集至少一至两周的 CPU、内存、磁盘 I/O、网络流量和并发请求数据；若业务有月末结算、促销或季节性波动，应覆盖相应时段，必要时观察更久。区分持续负载和短时尖峰，并核查增长趋势。迁云后还要确认磁盘类型、网络带宽上限及突发性能规则是否匹配，而不是仅比较虚拟机的核心数。
数据迁移不等于复制文件
先盘点数据库、上传文件、备份和日志的容量、增长速度及保留要求。核实哪些数据必须迁、哪些可按策略清理，并测算传输时间：大致可用“待传数据量 ÷ 实际可用带宽”估算，实际耗时还会受到线路拥塞、加密开销和小文件数量影响。不要把 RAID 或云端快照当成独立备份；迁移前应有可恢复的备份，并在隔离环境验证恢复结果。
数据库可按条件选择全量导入，或全量导入后持续同步增量：数据量较小、可安排维护窗口时，前者更简单；写入持续且停机窗口有限时，增量同步更合适，但需要额外验证复制延迟、版本兼容和切换顺序。两种方式都应先核对记录数或校验结果，再安排最终切换。
最容易漏掉的网络与访问边界
逐项核对 DNS 的 A、AAAA、MX、TXT 记录，避免只迁网站地址却漏掉邮件收发、域名验证或发信策略。切换前可提前降低解析 TTL，例如调整到数分钟至一小时的范围，并留出时间让旧缓存逐步过期；不同递归解析器和本地缓存的行为并不完全一致，TTL 不能保证所有用户同时切换。还要确认 HTTPS 证书覆盖的域名、证书部署位置及续期流程。
对照旧机房的入站、出站规则，检查云端安全组、主机防火墙和管理入口是否分别配置。需要固定来源访问的后台、数据库管理端口，不应因为迁移方便而开放给所有公网地址；若依赖办公网络或站点间专线，也要验证路由、地址冲突和回程路径。
运维、安全与费用要一起算
明确谁负责补丁、监控、备份、证书续期和故障响应，并在迁移前测试告警是否送达。比较费用时，除计算资源外，还要纳入磁盘、快照、备份存储、公网流量、固定 IP、日志留存及软件许可。流量费用通常受出口方向、计费方式和区域影响，应以拟选服务的计费规则核算，不能只看标价中的实例费用。
按顺序完成迁移前检查
- 建清单：登记应用组件、数据位置、外部接口、域名记录和负责人。
- 做演练：在非生产环境部署应用，验证登录、写入、上传、邮件及计划任务。
- 核对数据：完成备份恢复测试，选定全量或增量迁移方式，并比较关键数据。
- 定切换窗口：明确写入暂停或只读安排、DNS 调整步骤、验证人和回退触发条件。
- 保留旧环境：新环境稳定运行并确认数据无误后，再按留存和安全要求处理旧机房资源。
常见问题
是否必须一次性迁完所有服务？
不一定。依赖关系简单、停机窗口充足时可整体切换；组件耦合较弱时可分阶段迁移，但要先验证两侧网络连通、数据同步和故障边界。
怎样判断云上规格够不够？
结合代表性时段的资源使用、增长趋势和压测结果判断，并为峰值留出余量。旧服务器配置本身不能说明真实负载。
DNS 改完后能马上关掉旧服务器吗？
不建议。解析缓存可能使部分访问仍到旧地址，应观察新旧环境的请求和错误情况，并按预先约定的稳定观察期决定何时下线。
迁移前最重要的回退条件是什么？
写清楚什么情况触发回退、谁有权决定，以及回退时如何避免新旧环境数据分叉。完成这份网站从本地机房迁移到云端的评估清单后，再执行切换，才能让风险和责任都可检查。