网站迁移要准备的记录,不是一份“搬家清单”,而是一套能让协作方在出问题时快速还原现场的证据链。最常见的误解是:只要把文件、数据库和域名解析交接完,迁移就算完成。实际上,真正容易造成返工的,是迁移前没有记录“原状态是什么”,迁移中没记录“谁改了什么”,迁移后没记录“哪些地方需要继续观察”。尤其在多人协作中,记录的目标不是留档好看,而是让下一位接手的人不用靠猜。
迁移记录至少要分成三类,混在一起会越写越乱。第一类是资产与配置记录:源站使用了哪些服务器环境、数据库版本、PHP或运行环境版本、伪静态规则、计划任务、对象存储或CDN配置。第二类是变更与操作记录:谁在什么时间改了解析、改了数据库连接、替换了哪些文件、执行了哪些命令。第三类是验证与回滚记录:迁移后检查了哪些页面、发现什么问题、如何回滚、回滚后是否恢复正常。
这三类记录对应不同角色。开发看配置,运维看变更,内容或运营看验证结果。如果全塞进一个“迁移说明.txt”,协作时就会出现“我改了解析但没人知道”“首页正常但内页404没人记录”的情况。
迁移前不记录原站状态,迁移后就无法判断问题是迁移引入的,还是原本就存在。建议至少固化以下内容,并且用文字或截图留证,不要只靠记忆。
这里有一个判断条件:如果原站仍在运行,先做一次完整备份并记录备份时间与存放位置;如果原站已经无法访问,只能从历史工单、聊天记录或旧文档中补录,此时要在记录中标注“信息来源”和“不确定项”,避免把推测当成事实。
变更记录要能回答三个问题:改了什么、为什么改、改完结果如何。只写“调整了解析”没有价值,因为协作方不知道调整前是什么、调整后是什么、是否已验证。
可以按下面这个短例子执行,假设迁移一个企业展示站:
适用条件是多人协作且迁移窗口有限。如果只有一个人操作、站点结构简单,可以简化格式,但“变更前、变更动作、验证结果”这三项不能省。判断结果是否合格的标准是:另一个人拿着这份记录,能否在不询问你的情况下复现操作或执行回滚。
迁移完成不等于可以关闭记录。验证记录要覆盖功能、内容和外部依赖三个层面。功能层面检查表单提交、搜索、登录、支付回调等交互;内容层面抽查栏目页、详情页、图片和附件是否正常加载;外部依赖层面检查统计、客服、接口回调是否仍指向正确地址。
交接时,把记录整理成一份可检索的文档,并明确以下事项:
如果迁移涉及备案信息、域名持有者或服务商变更,这些属于行政与合同层面,不能只靠技术记录覆盖,应单独列出待办项和责任人。记录中不要写“应该没问题”这类判断,只写已验证的事实和未验证的项。
很多团队在迁移后只发一句“已上线”,结果一周后出现图片丢失、内页跳转错误或接口失效,没人说得清是哪一步引入的。正确的做法是:迁移结束当天,由操作人补全变更与验证记录,由另一位协作人按记录抽查关键项,确认无误后再标记迁移关闭。下一步可以直接做一件事:打开你正在进行的迁移文档,检查是否包含“变更前状态、变更动作、验证结果、回滚方式”四项;缺哪项,就先补哪项,再继续后续操作。