CMS系统选择：旧系统字段无法完整迁入时怎样决定保留项，同一个报错，可能是两种完全不同的原因
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d9e54b524b85.html
📄
CMS系统选择：旧系统字段无法完整迁入时怎样决定保留项，同一个报错，可能是两种完全不同的原因
先给结论：不要按“字段能不能迁”决定保留，而要按“字段离开旧系统后是否还有下游用途”决定。迁移工具报错、目标模型没有对应字段，只说明技术映射困难，不说明内容该丢。真正要判断的是：这个字段承载的信息，是否仍被编辑、检索、展示、审核或对外承诺所需要。若答案是否定的，即使能迁也不值得保留；若是肯定的，即使要手工补录也应保留。
同一个报错，可能是两种完全不同的原因
旧系统字段迁不进去，常见两种解释。第一种是结构错配：旧字段是自由文本，新系统要求结构化选项；旧字段存的是多值，新系统只接受单值。这类问题通常可以通过中间转换解决，信息本身仍有价值。第二种是语义废弃：该字段在旧系统里早已停止维护，编辑多年不填，前台也不展示，只是数据库里还留着列。这类字段即使格式完全兼容，迁过去也只是搬运垃圾。
两种解释的处理方向相反：前者值得为它设计转换规则，后者应当直接列入不保留清单。把两者混在一起，就会出现“能迁的全迁、迁不动的全丢”的粗放结果。
用三条证据区分“该保留”和“可放弃”
要区分上述两种原因，可以查三类可验证的证据，而不是凭印象争论。
- 使用痕迹：该字段最近一次被编辑填写是什么时候，填写比例大概如何。若长期大面积留空，倾向语义废弃；若填写稳定，倾向结构错配。
- 下游依赖：前台模板、检索、导出报表、审核流程、对外文档是否读取该字段。只要有一个下游还在用，就不能简单丢弃。
- 重建成本：若丢弃后需要重新补齐，补录依据是否存在。有原始来源可追溯的，丢弃风险低；一旦丢失无法复原的，应优先保留。
这三条证据要一起看。单看“填写比例低”容易误判——某些字段天然只在少数条目上填写，但每条都关键，例如特殊许可说明。单看“下游在用”也不够，下游可能只是历史遗留的展示位，早已无人关注。
一个假设例子：把字段分成四类再决定
假设某站旧系统有 20 个自定义字段，新系统只能容纳 8 个。可以先做一次分类，而不是逐个纠结：
- 必留：有下游读取且无法重建，如对外承诺编号、生效日期。这类字段即使需要写转换脚本也要保留。
- 可留：有下游读取但可重建，如从标题自动生成的摘要。可先迁入，后续用规则重新生成。
- 可弃：无下游读取且可重建，如内部临时备注。直接列入不保留清单。
- 待定：有下游读取但语义已变，如旧分类标签。需要先确认新分类体系，再决定映射或合并。
这个例子里的数字只为说明比较方法，不代表任何真实系统的容量。分类完成后，实际动作是：先对“必留”字段做一次抽样导出，验证转换后内容是否可读、可检索。这一步的结果会直接影响下一步——如果抽样发现转换后大量字段值错位或截断，说明映射规则本身有问题，应先修规则，而不是继续扩大迁移范围；如果抽样通过，再把“待定”字段提交给内容负责人确认，避免技术团队替业务做取舍。
保留项定下来之后，还要写清退出条件
决定保留不等于永久背负。对每个保留字段，应记录它的用途、责任人和复核时间点。若一个字段在约定周期内既无编辑填写，也无下游读取，就可以进入下一轮清理，而不是一直留在系统里。这样做的价值在于：把“暂时保留”和“长期承诺”分开，避免旧系统的字段债务被原样搬进新系统。
最后需要说明的是，迁移后某些统计归零或抓取量下降，不能单独证明保留项判断正确。它也可能来自新页面结构变化、访问路径调整或外部链接失效。要验证判断，还是回到那三条证据：使用痕迹、下游依赖和重建成本，在迁移后重新核对一次，再决定是否调整保留清单。
