网站迁移要准备的记录,核心是一份能让接手的人不靠口头询问就能复现环境的清单:域名与DNS变更、服务器与部署配置、数据库与文件备份、账号权限、页面与链接对照、回滚方案,以及每一步的执行人和时间。缺少其中任何一项,多人协作时就容易出现改错环境、漏传文件、链接失效后无人认领的情况。
假设泉州一家做建材批发的公司要把旧站迁到新服务器,参与的人有前端、后端、运维和内容编辑。旧站用某个CMS搭建,有产品页、新闻页和在线留言表单。迁移前如果没有记录,常见结果是:运维只备份了数据库没备份上传目录,编辑发现产品图全丢;或者DNS已经切到新IP,但旧服务器上的表单接口还在被调用,留言进不了后台。
如果提前准备记录,流程会变成可交接的步骤:
这里的关键不是记录格式多漂亮,而是任何人拿到这份记录,都能判断“现在做到哪一步、下一步谁来做、出问题退回哪里”。
按交付角度,可以把记录分成四组,每组都要有明确的责任人和更新时间。
多人协作时,建议把这份清单放在团队共用的文档里,而不是散落在聊天记录中。每次改动只追加一行,不覆盖旧记录,这样出问题时能看清是哪一步引入的。
迁移最容易返工的地方是URL变化。旧站如果是动态地址,新站改成静态地址,就必须有一一对应的跳转关系。做法是:
判断结果的标准很直接:访问旧URL时,浏览器地址应稳定跳到新URL,而不是跳到首页或404页。如果跳转到首页,说明跳转规则写得太宽,需要收窄到具体路径。
DNS切换不是迁移的终点,而是风险集中点。切换前应确认:新环境能通过临时地址正常访问,数据库连接正常,上传目录可写,HTTPS证书有效,表单能正常提交并入库。切换后应检查:域名解析是否生效、全站主要页面是否返回正常状态、旧链接跳转是否正确、后台能否登录、日志里是否出现大量404或500错误。
回滚条件要提前写死,例如:切换后两小时内出现大面积500错误、表单完全不可用、或核心页面无法打开。满足任一条件就切回旧解析值,而不是在现场临时讨论。回滚记录同样要写清操作人和时间。
另外,邮件、短信、支付等外部接口的配置经常被忽略。迁移后如果留言通知收不到,先检查接口密钥、回调地址和白名单是否同步更新,而不是直接怀疑程序坏了。
记录做完后,让不参与迁移的同事按清单独立走一遍:从备份文件恢复到新环境,按对照表抽查链接,按检查项确认表单和后台。能独立走通,说明记录合格;走不通的地方,就是下次返工的隐患点。
下一步,把上面四组记录整理成一份可追加的迁移文档,指定一人维护,并在切换前完成一次桌面演练。