网站开发必备要素：网站迁移应准备哪些记录？
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8737bbe914f8.html
📄
网站开发必备要素：网站迁移应准备哪些记录？
网站迁移要准备的记录，核心是能还原“迁移前是什么、迁移中改了什么、迁移后是否一致”的三类信息。对多人协作来说，最该交付的不是一句“都弄好了”，而是一份可核对的迁移记录包：域名与DNS变更、服务器与环境配置、页面与URL映射、数据备份、账号权限、测试结果和回滚方案。缺少其中任何一项，接手的人就得重新排查，返工往往从这里开始。
先观察：迁移前必须记录哪些现状
迁移前不要急着动文件，先把现状固定下来。建议至少记录以下内容：
- 域名与解析：当前使用的域名、子域名、DNS服务商、关键解析记录（A、CNAME、MX、TXT）及其TTL值。TTL要记，因为它决定解析变更后多久生效。
- 服务器与环境：源站服务器位置、Web服务器类型与版本、运行环境版本、依赖扩展、定时任务、环境变量。不要只写“PHP环境”，要写到具体版本和关键配置项。
- 页面与URL清单：迁移前可访问的URL列表、对应状态码、是否有重定向链。这是后续做映射的底稿。
- 数据与文件：数据库名称、字符集、大小、备份时间；上传目录、静态资源目录、配置文件的位置和体积。
- 账号与权限：域名注册商、DNS、服务器、数据库、CMS后台、第三方接口的账号归属和权限级别。记录谁持有、谁可以操作，不记录明文密码。
观察阶段的判断标准很简单：如果另一个人只拿到这份记录，能否说清“原站点跑在哪里、由哪些部分组成”。做不到，就说明记录还不够。
再判断：哪些记录决定迁移能否顺利交付
记录不是越多越好，而是要覆盖会引发返工的关键点。多人协作时，以下四类最容易出问题：
- URL映射关系：旧URL对应新URL，哪些保留、哪些重定向、哪些下线。判断依据是旧链接是否还有外部引用或用户访问。没有映射表，迁移后大量404只能靠猜。
- 变更前后对照：DNS改了哪条、服务器换了哪个IP、配置改了哪个值。只写“已切换”无法复查，也无法回滚。
- 备份与恢复点：备份文件放在哪、什么时候备份、如何恢复。要能实际执行一次恢复验证，而不是只写“已备份”。
- 责任人与时间点：谁在什么时候执行了哪一步。多人协作中，时间线能快速定位是哪次操作引入了问题。
如果迁移涉及搜索流量，还要单独记录旧URL的收录与重定向策略，但这是迁移记录的一部分，不是全部。把迁移记录写成SEO清单，会漏掉服务器、数据和权限这些更基础的内容。
处理：把记录整理成可交付的迁移文档
记录要落到一个团队都能打开的文件里，按“迁移前、迁移中、迁移后”分段，而不是散落在聊天记录中。一个可执行的整理步骤是：
- 建立迁移记录文档，固定字段：项目、环境、操作人、时间、变更内容、验证结果、回滚方式。
- 迁移前填入现状清单，作为基线。
- 迁移中每完成一步就更新一行，例如“修改DNS A记录，旧IP→新IP，TTL 600”。
- 迁移后逐项核对基线：URL是否可达、重定向是否正确、数据是否完整、定时任务是否运行。
可以用一段简短示例说明记录粒度。假设某站点把首页从旧服务器迁到新服务器，记录应写成：变更：A记录 old-ip → new-ip；TTL：600；执行人：A；验证：首页返回200，静态资源加载正常；回滚：改回old-ip。这里的关键不是格式，而是每条记录都能被独立验证。
需要提醒的是，迁移中出现“页面打不开”可能有多个原因：DNS尚未生效、服务器配置错误、证书问题、应用未启动，或者防火墙限制。没有定位之前，不要把它归为单一原因，记录里应写“现象+已排查项+待排查项”，而不是直接下结论。
复查：迁移完成后核对哪些记录才算闭环
复查不是再看一遍文档，而是拿记录去验证实际状态。建议按以下检查项逐条确认：
- 域名解析是否指向预期目标，TTL是否已按计划调整。
- 主要页面和关键URL是否返回预期状态码，重定向是否符合映射表。
- 数据库和上传文件是否完整，数量或体积与迁移前基线是否一致。
- 账号权限是否已交接，旧环境是否按计划保留或关闭。
- 回滚方案是否仍然可用，回滚触发条件是否写清楚。
判断闭环的标准是：一个没参与迁移的人，只读这份记录，能复现迁移过程、能验证结果、能在出问题时回退。如果做不到，就回到对应环节补记录。复查完成后，把最终版文档归档到团队可访问的位置，并注明版本和日期。
下一步建议：先拿一份现有迁移记录做一次“盲测”——让未参与的人按记录复述迁移步骤和回滚方式，凡是卡住的地方，就是需要补充的记录项。
