云服务器迁移怎么做？先把“能切过去”拆成可验证的资产、数据、流量和回退四件事。迁移不是把镜像复制到新实例后立刻改 DNS；真正容易遗漏的是依赖服务、写入顺序、缓存、证书、监控与旧环境的保留策略。对大多数业务，更稳妥的做法是先建立可运行的目标环境，再用小范围流量验证，最后安排可回退的正式切换。
先列出当前业务的入口和依赖，而不是只列一台云服务器。至少核对域名与 DNS、负载均衡或反向代理、应用实例、对象存储、数据库、缓存、消息队列、定时任务、第三方回调、证书、监控与告警。每一项都要写明负责人、配置来源、数据是否持久化以及发生故障时的影响。
尤其要确认哪些连接是通过内网地址、固定公网 IP、白名单或安全组建立的。新环境的网络段、出网地址、权限角色和密钥管理方式若不同，应用即使成功启动，也可能在访问数据库、调用接口或接收回调时失败。若迁移涉及中国大陆接入资源或业务区域变化，还应重新核对部署与业务边界，可参阅海外服务器部署与接入链路的核对方法。
不要只在新服务器上手工安装一次软件。应记录操作系统、运行时版本、端口、环境变量、存储挂载、权限、安全组、备份和日志位置，并让这些配置能被复查或重复执行。目标环境需要先完成最小可用验证：服务能启动、健康检查能通过、日志能采集、监控能看到关键指标。
数据迁移不只关心复制速度，更要说明正式切换时哪些写入会继续发生。静态文件可先做全量复制后再补增量；数据库、缓存或队列则需要按自身一致性与恢复机制设计同步方案。不要在没有演练的情况下假定“最后同步一次”就能解决并发写入、延迟和失败重试。
| 对象 | 切换前应确认 | 验证重点 |
|---|---|---|
| 文件与对象存储 | 全量复制、增量窗口、权限和生命周期规则 | 关键文件存在、链接可访问、上传路径正确 |
| 数据库 | 同步方式、停写或双写边界、备份与恢复演练 | 关键记录、读写路径、数据延迟和报错 |
| 缓存与队列 | 是否可重建、消费者位置、消息保留策略 | 积压、重复处理、丢失和顺序影响 |
若业务无法承受停写，先做小范围演练，把“何时停止旧写入、何时确认新写入、谁有权决定回退”写清楚。涉及新区域或不同云平台时，迁移工时、网络与配套服务也属于总成本的一部分，可用统一口径的云服务器比价方法把它们单列出来。
正式改解析前，优先通过测试域名、Hosts、内网入口或少量受控流量验证新环境。验证不应只看首页能打开，还要覆盖登录、提交表单、上传下载、后台任务、第三方回调以及告警。把每项测试的预期结果、实际结果和执行人保留下来，避免多人在窗口内各自判断“看起来正常”。
进入正式切换时，提前确定 DNS 生效时间、负载均衡策略和缓存处理方式，并让客服、运营与研发知道窗口和反馈入口。DNS 只是流量路径的一环；如果 CDN、WAF、回源规则、证书或安全组仍指向旧环境，改解析也无法完成真正切换。关于源站暴露和回源链路的风险，可继续阅读CDN 与高防服务器的职责区别。
切换后应在预先约定的观察期内对比新旧环境，而不是看见一两次成功访问就删除旧资源。最少应观察可用性、错误率、响应时间、关键任务完成情况、数据同步状态、告警与用户反馈。对于无法立即确认的异步任务，保留足够的排查窗口再做关闭旧环境的决定。
取决于应用架构、数据同步方式和可接受的一致性边界。静态内容或可横向扩展的服务通常更容易分阶段切换；有持续写入的关键系统则应先通过演练确定停写、双写或回滚安排。
不算。还需要确认新环境的应用依赖、数据、证书、监控、回调、缓存和安全规则已经生效，并在观察期内验证关键业务动作正常。
没有统一时长。应以约定的观察期、数据核对、备份可用性和回滚窗口为准；在这些条件未满足前，先保留旧环境和配置记录。