把 WordPress 网站从一个主机迁到另一个主机，听起来简单，实际操作却布满小地雷。一次失败的迁移可能流失访客、弄坏表单、丢失最新内容，最糟的是让网站连续数天处于这样一种状态：一部分访客访问的是旧主机，另一部分访客访问的是新主机。
若操作得当，迁移对访客来说是无形的，对企业主来说是毫无压力的。以下是我们在 Defyn 迁移 WordPress 网站时使用的八步完整流程，它在一百多次迁移中不断打磨而成。
第一步：动手之前先做盘点
在新主机拿到数据库之前、在 DNS 接近任何改动之前，先把一切重要的东西列出来。插件版本、自定义代码、计划任务、第三方集成、支付网关、邮箱账户、DNS 记录、SSL 证书提供商、反垃圾邮件密钥、备份目的地。任何不在清单上的东西，都有被遗漏的风险。
这一步需要一到两个小时，却能省下迁移后四个小时的救火时间。
第二步：降低 DNS 的 TTL
在切换前三天，把 A 记录和重要 CNAME 的 TTL 从默认值（通常是 24 或 48 小时）降到 300 秒。这意味着一旦完成切换，DNS 会在五分钟内传播，而不必等待缓存在一两天内过期。
正是这一步，把一次干净的迁移与一段长达 36 小时的 DNS 悬空状态区分开来——在那种状态下，一部分访客看到旧网站，另一部分看到新网站。
第三步：将新主机搭建为预演环境
在临时网址下，或通过修改 hosts 文件覆盖，把加载了 WordPress 网站的新主机启动起来。真正的工作就在这里完成：导入数据库、复制文件、安装 SSL 证书、配置缓存，并验证一切确实能正常运行。
这一步通常需要一整个工作日。hosts 文件的做法让团队可以在办公室内部测试整个网站，而公共 DNS 此时还没有指向新主机。
第四步：测试每一个表单、支付和集成
大多数迁移正是在这里翻车。联系表单看起来一模一样，但 SMTP 凭据需要为新主机重新配置；支付网关开着，但 webhook 网址仍指向旧主机；邮件插件能用，但新主机的 IP 信誉如何尚不可知。
把网站上的每一个表单都走一遍，提交它们，确认邮件确实送达。完成一笔真实（随后退款）的交易。手动运行计划中的 cron 任务并核对输出。在包括手机在内的三种浏览器中测试。
第五步：最后一次数据库同步
就在 DNS 切换之前，做一次最后的数据库同步，以捕获测试期间发生的任何内容编辑、评论或交易。然后，如果可能，把源站点置于只读状态（一个维护插件或短暂的内容冻结），这样在切换期间旧主机上就不会产生新数据。
第六步：切换 DNS
由于 TTL 已提前降低，把 A 记录（或视主机而定的 CNAME、ANAME）指向新服务器。五分钟内，大多数访客便会访问新主机；一小时内，几乎所有访客都会如此。
在最初的 24 小时内让两台服务器同时运行。如果某位访客使用的是尚未完成传播的慢速 DNS 解析器，他会访问旧主机，并依然看到一个正常运行的网站。这个双服务器窗口在旧账户上只多花一天的主机费用，而这份保障是值得的。
第七步：在最初的 48 小时持续监控
盯着可用性监控，盯着主机的错误日志，盯着联系表单的收件箱。迁移后冒出来的大多数问题都会在最初的 12 小时内出现：一条缺失的重定向、一张为某个子域名配置错误的 SSL 证书、一个需要更新 IP 白名单的第三方集成。
第八步：下线并归档记录
在新主机上稳定运行 48 小时后，为旧环境做一次最终备份以便存档，然后将旧账户下线。记录下新架构：数据库在哪里、套餐是哪一档、各项登录凭据分别存放在何处、配置了哪些监控，以及万一发生灾难性问题时的回滚流程是什么。
这份文档才是六个月后真正重要的交付物。没有它，下一个需要做主机决策的人将毫无背景可循。
自行迁移常在哪里出错
自行迁移最常见的两种失败，是跳过第二步（降低 TTL）和跳过第四步（完整的集成测试）。这两步看起来都很枯燥，却都能省去另一端数小时的烦恼。据我们的经验，一次遵循完整八步的迁移，对访客是无形的，对企业主是波澜不惊的。
如果你正面临一次主机迁移，并希望找一个已经做过数十次的合作伙伴，Defyn 的主机团队会把 WordPress 迁移当作一个范围固定、结构清晰的项目来处理。网站干净利落地完成迁移，你照常工作，事后没有人会提起这次迁移，因为一切都没有出错。如果你需要帮助离开当前的主机，欢迎联系 Defyn。
