CMS系统选择 - 网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7abdbe498fd.html
📄
CMS系统选择 - 网站迁移应准备哪些记录
网站迁移前要准备的记录，核心不是“把旧站文件打包”，而是一份能让接手者在不问你任何问题的前提下完成迁移的交付清单。多人协作时，最常见的误解是认为迁移记录等于数据库导出加一份栏目截图。实际上，真正导致返工的是那些没被写下来的隐性约定：某个栏目为什么用自定义字段、某张图片为什么必须走外链、某个页面为什么不能直接改模板。这些信息不在文件里，只在人的记忆里。迁移记录的目标，是把这些记忆变成可核对、可执行的条目。
先分清三类记录，不要混在一份文档里
迁移记录至少分三层，混在一起会互相干扰。第一层是资产清单，回答“有什么”：文章、页面、分类、标签、媒体文件、用户、评论、表单提交记录。第二层是结构映射，回答“怎么对应”：旧栏目对应新站哪个分类，旧固定链接对应新链接，哪些页面合并、哪些重定向。第三层是行为与依赖，回答“为什么这样”：哪些字段是模板调用的、哪些插件输出被前端引用、哪些定时任务在跑。
多人协作时，三层记录分别由不同角色维护更可靠。内容负责人维护资产清单，前端或模板负责人维护结构映射，运维或原开发维护行为与依赖。如果只有一个人写全部记录，他离职或请假时，迁移就会卡住。
迁移前必须写下来的具体条目
下面这份清单可以直接作为交付模板使用，适用条件是：旧站仍可访问、数据库可导出、有至少两人参与迁移。如果旧站已经无法访问，只能依赖备份和日志，那么清单中的“行为与依赖”部分需要改为从备份中反推。
- 内容类型与数量：文章、页面、产品、自定义文章类型各多少条，草稿和回收站是否迁移。
- 字段与分类法：每个自定义字段的名称、类型、是否必填、在前端哪个位置显示；分类和标签的层级关系。
- 固定链接规则：旧站链接结构，例如
/archives/{id}.html或/category/post-name，以及需要保留的链接列表。 - 媒体文件：文件存放路径、命名规则、是否有外链图片、是否有版权或授权记录需要保留。
- 用户与权限：需要迁移的账号、角色、作者与内容的对应关系；不迁移的账号要注明原因。
- 模板与插件依赖：哪些页面由模板文件控制，哪些输出依赖插件；插件停用后哪些区域会空白。
- 重定向与合并规则：哪些旧链接 301 到新链接，哪些页面合并后只保留一个入口。
- 检查项与验收人：每一项由谁检查、检查通过的标准是什么。
这份清单不需要一次写完。可以先写资产清单和结构映射，行为与依赖部分在迁移测试中逐步补全。关键是每一项都要有负责人和验收标准，而不是只写“待确认”。
一个常见误解：记录越详细越好
记录不是越详细越好，而是越可执行越好。把旧站每个页面的 HTML 源码都贴进文档，既没人看，也无法核对。正确的做法是记录判断依据和例外情况。例如，不要写“所有文章都要迁移”，而要写“已发布文章迁移，草稿中标注‘待审’的迁移，其余不迁移”。这样接手者遇到边界情况时能自己判断，而不是反复问你。
另一个误解是认为迁移记录写完就固定了。迁移过程中一定会发现遗漏，记录应该允许追加，但追加的条目要标注发现时间和影响范围。否则多人同时修改，最后没人知道哪条是最新版本。
迁移后如何验证记录是否够用
验证方法很简单：找一个没参与旧站维护的人，只给他这份记录和新站后台，让他完成三件事——发布一篇带自定义字段的文章、把一条旧链接重定向到新链接、说明某个栏目为什么不能直接删除。如果他不需要额外提问就能完成，记录基本够用；如果他在某一步停下来问“这个字段填什么”，说明对应条目缺少判断依据。
适用条件是：新站已经可以登录，旧站数据已经导入。判断结果是：能独立完成上述三项，记录可交付；需要提问，把提问内容补进记录后再测一次。这个过程本身也是验收的一部分，不需要额外工具。
下一步：把清单变成可勾选的交付表
把上面的条目转成一张带负责人、状态、验收标准的表格，每完成一项就勾选并注明完成时间。迁移结束后，这张表连同重定向规则和字段说明一起归档。下次再迁移或换人维护时，先从这张表开始核对，而不是从零回忆。
