📍 WDQWDWQD987AAAAA:216.73.217.153
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28c4d202d880.html
📄

昭通网站建设 - 网站迁移应准备哪些记录

网站迁移前最该先准备的是一份能对照新旧环境的迁移记录表，至少包含域名与解析、服务器与运行环境、程序与数据库、页面与链接、账号与权限、备份与回滚六类信息。时间和人手有限时，先做这份表，再动文件，能避免迁到一半才发现缺参数、缺权限或缺备份。

先观察：迁移前要盘清哪些现状

迁移不是复制文件那么简单，先把旧站的真实状态记录下来。观察阶段的目标是形成一份可核对的清单，而不是凭记忆操作。

• 域名与解析：记录域名注册商、DNS 服务商、A 记录与 CNAME 指向、TTL 值、是否启用 CDN 或邮件解析。
• 服务器环境：记录操作系统版本、Web 服务软件及版本、PHP/Node/Python 等运行时版本、端口与防火墙规则。
• 程序与数据库：记录 CMS 名称与版本、数据库类型与版本、字符集、表前缀、连接账号（不写明文密码，记存放位置）。
• 页面与链接：记录栏目结构、伪静态规则、已收录的 URL 形态、是否有重定向规则。
• 账号与权限：记录后台管理员、数据库账号、FTP/SFTP 账号、CDN 与 DNS 控制台权限归属。
• 备份与回滚：记录最近一次完整备份的时间、存放位置、恢复方式，以及回滚到旧环境的触发条件。

这份记录建议用表格维护，每项写清“旧环境值”和“新环境值”两列，迁移时逐项填写，复查时逐项核对。

再判断：哪些记录必须先有，哪些可以后补

人手有限时，按“缺了就停摆”的程度排序。以下三类属于必须先有：

1. 数据可恢复的记录：数据库导出文件、网站文件完整备份、备份校验方式。没有可恢复备份，不应开始迁移。
2. 访问可切换的记录：域名解析权限、TTL 当前值、新服务器 IP。TTL 较大时，提前调小可以减少切换等待。
3. 程序可运行的记录：运行时版本、数据库版本、扩展模块列表。版本不一致是迁移后白屏或报错的常见原因之一。

可以后补的包括：统计代码、第三方接口密钥、部分静态资源路径。但要在记录表里标出“待补”，避免遗漏后无人跟进。

判断依据很简单：如果某条记录缺失会导致网站无法打开、数据无法恢复或无法回退，它就属于第一优先级。

处理：按记录表执行迁移的先后顺序

有了记录表，执行顺序可以固定下来，减少来回确认。

1. 在新环境按记录表配置服务器、运行时和数据库，版本尽量与旧环境一致。
2. 导入数据库备份，上传网站文件，按记录修改数据库连接配置。
3. 用临时域名或 hosts 绑定方式在新环境自测，不改动正式解析。
4. 逐项检查首页、栏目页、内容页、搜索页、表单提交是否正常。
5. 确认无误后，切换 DNS 解析到新服务器，观察解析生效情况。
6. 保留旧环境一段时间，作为回滚通道。

如果旧站使用了伪静态或重定向规则，例如 <h2> 这类标签本身不涉及迁移，但伪静态配置文件和 .htaccess 规则需要一并记录并迁移，否则迁移后链接可能大面积失效。

复查：迁移完成后核对哪些记录项

复查不是重新看一遍，而是用可验证的方式确认结果。

• 解析核对：用不同网络环境访问域名，确认指向新服务器 IP。
• 链接核对：抽查旧 URL 是否能正常打开，是否按预期跳转，有无 404 集中出现。
• 数据核对：对比迁移前后文章数、用户数、订单数等关键计数是否一致。
• 功能核对：登录后台、发布测试内容、提交表单、查看邮件通知是否正常。
• 备份核对：确认新环境已建立新的备份任务，并实际恢复一次验证可用。

复查中发现的问题要回填到记录表，注明现象、可能原因和处理结果。同一现象可能有多种原因，例如页面打不开既可能是解析未生效，也可能是新服务器防火墙未放行，不要只凭一个现象就断定原因。

下一步

现在就可以打开一份空白表格，按上面六类字段先填“旧环境值”。填不出来的项，就是迁移前需要优先确认的信息。表填完再安排迁移操作，比边迁边找参数更省时间。