网站建设成功案例：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f386baac7ba7.html
📄
网站建设成功案例：旧系统字段无法完整迁入时怎样决定保留项
先定一条硬规则：只保留“新站上线后仍会被业务动作直接调用”的字段，其余字段先冻结、归档，不进入新库。判断依据不是字段数量，而是它是否参与查询、展示、筛选、导出或后续人工跟进。假设一个旧站有 120 个内容字段，新站只支持 40 个，那么优先保留的是标题、正文、发布日期、分类、标签、作者、状态和外部旧链接；阅读数、内部评分、冗余备注、旧版式开关这类字段，除非有明确的下游用途，否则不迁。
先区分“内容字段”和“流程字段”
旧系统里很多字段看起来是内容，实际承担的是流程状态。比如“审核人”“审核时间”“退回原因”“发布渠道”属于流程字段；它们决定一条内容在新站里能不能被正确编辑、复核和下线。内容字段缺失通常只影响展示，流程字段缺失会影响后续操作，所以后者优先级更高。
可以用一个假设情境来串联：某企业旧站有“产品编号、产品名称、规格、旧分类、库存状态、负责人、内部备注、历史图片路径”八个字段，新站只允许保留五个。先问每个字段在新站上线后是否还会被用：产品编号用于对外查询和客服核对，保留；产品名称和规格用于展示，保留；旧分类用于跳转兼容，保留；历史图片路径用于补图，保留。库存状态如果已经由新系统实时接口提供，就不迁；内部备注如果只供旧团队内部查看，就归档到只读文件，不进入新站编辑界面。
用三个问题筛掉“看起来重要”的字段
- 没有它，新站会不会出现错误页面或错误信息？会，就保留。比如旧链接映射字段、唯一编号、状态字段。
- 没有它，日常编辑会不会被迫回到旧系统？会，就保留。比如作者、审核状态、发布时间。
- 没有它，是否只影响历史统计或内部参考？是，就归档，不迁。比如阅读数、旧评分、内部排序权重。
这三个问题的顺序不能颠倒。先保证可访问和可编辑，再考虑历史统计。很多迁移失败不是因为字段太多，而是把统计字段当成了展示字段，结果新站结构被拖复杂，编辑人员反而找不到真正要改的内容。
保留项要写成可执行的映射表
决定保留哪些字段后，不要只写“保留标题、正文、分类”，而要写成旧字段到新字段的对应关系，并注明空值怎么处理。例如：
old_title→title，空值则用“未命名”占位，并进入待补清单。old_body→body，保留原始段落，不自动截断。old_category→category，旧分类不存在时映射到“未分类”，同时记录旧值。old_url→redirect_source，用于后续跳转配置，不直接展示。
这张表的作用是让下一步的迁移脚本、人工补录和验收都有共同依据。如果只写“保留重要字段”，执行时每个人对“重要”的理解不同，最后仍然会返工。
先迁一批样本，再决定是否扩大保留范围
假设先抽 20 条旧内容做试迁，迁完后检查三件事：页面能否正常打开，编辑能否在不回旧系统的情况下完成一次修改，旧链接能否落到新站对应页面。如果这三件事都通过，再扩大迁移范围；如果编辑仍然需要查旧库才能补字段，说明保留项少了，应把该字段加入保留清单；如果新站编辑界面被大量无用字段占满，说明保留项多了，应把只读字段移出编辑界面，放进归档视图。
这个动作的结果会直接影响下一步：样本迁移通过后，才值得投入批量迁移；样本迁移不通过，先改映射表和字段清单，不要急着全量导入。全量导入后再删字段，成本通常比先冻结字段更高。
退出旧系统时，给不保留的字段留一条可查路径
不迁入新站不等于直接删除。更稳妥的做法是把旧库导出为只读归档，按内容编号或旧链接建立索引，并保留一段可查询的过渡期。这样做的目的不是继续依赖旧系统，而是当新站出现“某条旧内容缺少某个字段”的反馈时，能快速确认是迁移遗漏还是本来就不需要展示。过渡期结束后，再根据实际查询记录决定是否继续保留归档。
如果归档文件没有索引、没有字段说明，也没有人知道怎么查，那它只是形式上的备份，不能帮助判断保留项是否正确。因此，归档至少应包含字段名、旧内容编号、导出时间和对应负责人，方便后续核对。
