拷贝很少是弄坏一次 WordPress 迁移的部分。弄坏它的，是没人写下来的东西：一个 cron、一个 webhook、一个把旧主机名写进某一行的插件、一个仍从旧服务器发出的邮箱。我把清单当作迁移本身。文件传输是之后那个轻松的下午。
动手之前先把系统写下来
在文件搬走之前，我写一页陌生人也能用的说明。PHP 版本。数据库大小。cron 行，以及 WordPress 里面的计划任务，这两份不是同一张清单。邮件：谁发、经什么发、SPF 是否已经点名那台主机。每一个调用站点或被站点调用的集成。支付 webhook 和 CRM 同步是常见的意外，因为它们住在没人导出过的插件设置里。
我也会写下，对这家店来说「能用」是什么意思。一件实物的结账。一件虚拟商品的结账。登录。一次密码重置。联系表单，包括那封该到达的邮件。如果目录靠搜索，就包括搜索。如果我说不出这条路径，我就还没准备好改 DNS。
| 一行 | 它为什么在这里 |
|---|---|
| PHP、数据库大小、对象缓存 | 新主机可以是“起来了”，却仍然是错误的运行时。 |
| Cron 和计划任务 | 漏掉的夜间任务看起来没事，直到早晨的报告是空的。 |
| 邮件路径 | 网站可以打开，而每一封订单邮件都死在新机器上。 |
| Webhook 和对外 API | 它们通常没有写下来，而且最先注意到主机名。 |
| 赚钱的五条路径 | 看一眼首页并没有把它们走一遍。 |
前一天把 TTL 调低
切换前一天，把 DNS 的 TTL 设成 300 秒。如果您跳过这一步，而新主机是错的，一部分访客会把旧记录留上好几个小时。您没法催一个没有提前缩短的缓存。我宁可故意等一天，也不要在故障里才发现这段等待。
预发地址不是真正的主机名
我把新服务器拉起来，只用自己的机器通过 hosts 文件指过去，这时公开的 DNS 仍指向旧主机。然后我在真实主机名上走那些路径。staging 的地址会藏起把生产域名写进数据库的插件。它们表现正常，直到请求里出现真实名字，而那正是您不想再有意外的时刻。
如果关键路径没有在真正的主机名上走过，这次迁移就没有被测试过。
让旧主机先留着
迁移那一周我不会停掉旧主机。它至少再留两周，只读。花费很少。这是唯一不依赖一份我还没用过的备份的退路。如果新主机在第三天出问题，旧记录仍然有意义。
邮件是人们会忘掉的那项检查
网站可以看起来已经完成，而每一封订单邮件都死在新机器上。我写下 From 地址、中继，以及 25 端口到底开没开。不止一台主机上它是关的，唯一能走的路是 587 上经过认证的中继。SPF 已经有一条记录。我不加第二条。两条 SPF 不会合并。两条都会失效，而原来能到的邮件，会在一次除此之外都顺利的迁移之后的那一周开始消失。
在我说迁移完成之前，我会从新主机给一个我能打开的邮箱发一封真实的订单邮件和一封密码重置。日志里写着 “sent”，不等于邮箱里有那封信。后者才是测试。
apex 和 www 上都有 HTTPS。证书自己续期。邮件仍然发出。五条路径仍然走完。然后我看一天错误日志，不看首页。首页是监控已经在恭喜您的地方。日志才是 webhook 开始向支付方返回 404 的地方。
这样做的迁移很无聊。这正是目的。关于迁移的有趣故事，几乎都是清单里缺了一行。
