先给结论:当旧系统字段无法完整迁入时,保留项不应按“字段是否重要”来投票,而应先按“目标系统是否有承载位置”和“缺失后是否影响读者完成动作”两把尺子筛一遍。假设你从旧博客系统迁到新系统,旧库里有“文章副标题、阅读时长、来源声明、作者职称、自定义推荐位”五个字段,新系统只提供标题、正文、作者、标签和摘要。此时不要急着写转换脚本,先做一次字段用途盘点,再决定哪些合并进正文、哪些转成标签、哪些直接放弃。
旧系统字段不能完整迁入时,最容易犯的错是把所有字段都当成内容。实际应先判断它在旧站承担什么职责:是给读者看的展示信息,还是给站内检索、聚合页、模板判断用的结构信息。展示字段缺失后,读者仍能读完文章;检索字段缺失后,相关文章列表、归档页或筛选入口可能变空。
把字段归入这三类后,保留优先级会清楚很多:检索字段优先找替代承载方式,展示字段优先判断能否并入正文,混合字段先确认新系统是否真的需要它参与查询。如果旧站的阅读时长只是显示,不参与任何列表逻辑,那它就不该占用迁移工时。
字段保留与否,不取决于旧系统里它多完整,而取决于新系统有没有稳定位置。假设新系统只有标题、正文、作者、标签、摘要五个位置,那么旧字段的去向可以这样判断:
这里的实际动作是:先为每个旧字段写一行去向备注,格式为“字段名 → 新位置或放弃 → 影响页面”。写完后再打开新系统后台,逐个确认这些位置是否真实存在。如果某个字段被标记为“转标签”,但新系统标签页不支持层级或描述,就要重新评估它是否值得保留。这个动作的结果会直接影响下一步:去向备注能全部落到真实位置,才进入批量迁移;落不下去的字段,先回到保留项清单重新排序。
下面用一个明确假设的短情境说明决策顺序。假设旧博客有 300 篇文章,每篇都带五个字段,新系统只接受标题、正文、作者、标签和摘要。迁移前你发现旧字段无法原样导入。
第一步,列出缺失后读者会卡住的动作。读者在新站要完成三件事:找到同主题文章、确认作者身份、知道内容来源。与这三件事无关的字段,先降级。
第二步,给每个字段找最低成本替代。副标题并入正文首段;作者职称并入作者简介;来源声明放入正文末尾;阅读时长放弃;推荐位标识转为标签。这样处理后,读者仍能完成上述三个动作。
第三步,用一条测试文章验证。选一篇旧文,按上述方案手工迁移,然后从前台检查:标签页能否列出该文、作者页是否显示职称、正文末尾是否出现来源声明。若标签页为空,说明推荐位标识不该转标签,而应改为分类或直接放弃。这个测试结果会改变保留项清单,而不是只改变这一篇文章的显示。
决定保留项时,只写“保留什么”不够,还要写“放弃后读者会看到什么”。这能防止把可接受的缺失误判为必须修复的问题。
这张清单的作用是给后续迁移脚本定边界:只有标记为“不可接受”的字段才需要写转换逻辑,其余字段可以手工处理或直接丢弃。这样能避免为了一个只影响显示的旧字段,拖慢整个迁移进度。
如果旧字段之间存在依赖关系,例如推荐位标识同时控制首页排序和文章页推荐,而新系统没有对应结构,那么继续做字段映射只会制造更多例外。此时更合理的动作是停止逐字段迁移,改为在新系统里重新定义内容结构:用标签表达主题,用分类表达栏目,用正文末尾表达来源。重建字段的代价是旧数据需要二次整理,但好处是后续编辑不再面对两套逻辑。
判断是否进入重建,可以看一个信号:同一字段在不同文章里的用途不一致。比如“来源声明”有时是转载授权,有时只是编辑备注。这种字段即使勉强迁入,也会让新系统的标签或摘要变得混乱。遇到这种情况,先按用途拆成两个字段,再决定哪个保留、哪个放弃。拆完后若仍找不到稳定位置,就放弃该字段,并把必须保留的信息写入正文。最终保留项应少到能在一张表里说清去向,而不是多到需要逐篇判断。