网站迁移包含文件、数据库、域名和业务依赖的协同变化。“新服务器首页能打开”只能证明一部分工作完成。对于持续写入订单或用户资料的网站，还必须安排最终同步与回退。下面的检查清单适用于常见网站；高并发交易、多区域系统和复杂数据同步应制定单独的迁移方案。
1. 建立清单，先写下切换和回退条件
记录域名、DNS 管理位置、源服务器、数据库、存储、计划任务、第三方接口和告警配置。确认谁能操作、谁负责验证、谁有权决定回退。约定停写窗口、允许的中断时间及回退截止点，例如关键业务失败时停止切换。AWS 的迁移指南将依赖关系、测试与回退流程列为切换前准备内容。
2. 备份完成后，做一次恢复验证
备份网站文件、上传目录、数据库和必要配置，并记录时间与版本。WordPress 官方迁移说明同样要求保存文件和数据库。备份应存放在与待迁移目录分离的位置，限制访问权限。选择隔离环境实际恢复，核对文章、媒体、用户与关键业务记录；不要仅凭压缩包存在就确认备份可用。
3. 对齐运行环境和外部依赖
核对操作系统、运行时、数据库版本、扩展模块、字符集、时区、文件权限和重写规则。新环境使用不同公网 IP 时，还要确认接口白名单、邮件发送、对象存储和支付回调配置。配置迁移应使用必要的授权，切勿把密钥写入网页或公开代码。计划任务要安排启停顺序，避免两个环境重复执行。
4. 在切换域名前验证完整路径
通过受保护的预览环境或本地解析访问新站，确保测试使用正确域名和 HTTPS 条件。至少验证首页、文章页、后台登录、搜索、上传、表单及实际使用的业务流程。电商网站还需检查购物、支付回调和订单状态，测试时使用对应平台允许的测试方式，避免产生真实扣款或重复通知。
| 检查项目 | 通过标准 |
|---|---|
| 页面和资源 | 关键页面、图片、样式与下载可访问，无错误域名 |
| 后台与数据 | 可以编辑和保存，样本数据与源站一致 |
| HTTPS 与链接 | 证书覆盖正式域名，重定向无循环，无混合内容 |
| 权限和依赖 | 必要端口可用，后台受保护，外部接口验证通过 |
| 备份与回退 | 有可恢复备份，明确回退动作和决定时点 |
5. 安排最终数据同步，再切换流量
全量复制后源站仍可能产生新数据。切换前按方案暂停写入或使用经过验证的同步机制，核对最终数据一致性。提前调整 DNS 的 TTL 可减少部分缓存等待，但需要考虑旧记录缓存，不能承诺立即在所有网络生效。切换期间避免新旧环境分别接受写入，否则可能造成订单或资料分散。
6. 换服务器与换网址，分别检查
仅更换服务器且网址保持不变时，应保留现有路径与链接。若同时更换域名或路径，整理旧新网址对应表，将有对应内容的旧网址永久重定向到新网址；不应把不相关的旧文章全部跳转到首页。Google 搜索中心建议测试新站、建立网址映射并监测迁移，删除且无替代内容的地址应正常返回 404 或 410。
检查规范网址、站点地图及搜索引擎可见性。预览阶段设置的访问限制或禁止索引，在正式上线时要按用途移除；后台仍需保持保护。站点地图应只包含正式网址，并检查站内链接没有继续指向测试域名。搜索表现可能在迁移期间变化，不能以当天搜索结果作为迁移成功的唯一标准。
7. 回退要保护切换后产生的新数据
提前保留源站与必要配置，但不要直接把“改回 DNS”当作完整回退。如果新站已接收订单或编辑内容，需要先决定如何保留和同步这些变化，再恢复旧入口。没有验证过双向同步能力时，不让两端长期同时写入。回退步骤和预计耗时应在上线前演练或审查。
8. 上线后观察，再关闭旧资源
持续检查关键页面、响应时间、错误日志、数据库连接、后台任务与备份结果，并覆盖业务高峰。观察期由业务周期和风险决定，不套用统一天数。确认源站没有必要流量、数据保留和恢复要求已满足后，再关闭旧实例、附属磁盘和其他付费资源。迁移验收材料应包括配置清单、备份位置和后续维护事项。
云要发发科技提供部署与迁移服务。咨询时说明现有程序、数据量、域名是否变化以及允许的中断窗口，我们会据此明确交付范围与切换方案。也可以先阅读购买海外云服务器前的需求清单，准备目标环境的选型信息。
参考资料
本文为一般选型与运维参考，不包含固定报价。产品功能、可用地区和计费规则会调整，请以实际采购时的官方说明和书面方案为准。