品牌网站设计，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8f5c460d40ed.html
📄
品牌网站设计，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段是否重要”投票，而要按“字段是否仍在驱动一个业务动作”决定保留。迁移前先冻结旧系统写入，导出字段清单和近一个业务周期的使用记录，再把每个字段归入保留、合并、归档或丢弃四类。假设某品牌站旧系统有“客户等级”和“历史标签”两个字段，新站只保留“客户等级”，把“历史标签”转为只读归档，这就是一个可执行的取舍。
先判断字段是否仍在驱动业务动作
旧系统字段多，不代表每个字段都有当前用途。判断依据不是字段名称，而是它是否仍被查询、导出、触发通知或参与权限判断。若一个字段只出现在历史报表里，却不再影响任何页面展示、客服判断或后续流程，它就不该占用新站的结构位置。
假设某品牌站旧系统有“来源渠道”字段，过去用于分配销售跟进人。现在跟进规则已改为按地区分配，该字段只剩统计价值。此时应把它归入归档，而不是硬塞进新站表单。保留项应满足至少一个条件：仍参与当前业务规则、仍被一线人员高频查看、仍是合规或对账所需的最小记录。
用四类归置法替代逐字段争论
把候选字段放进四个盒子，能减少“这个也重要”的拉扯：
- 保留：仍驱动当前动作，且新站有明确承接位置。例如“客户等级”继续控制报价权限。
- 合并：两个旧字段表达同一件事，只留一个更稳定的。例如“手机号”和“联系电话”合并为“主要联系方式”。
- 归档：不再驱动动作，但未来可能被查询。只读存放，不进入新站主流程。
- 丢弃：重复、过期、无来源说明或从未被使用的字段。丢弃前要确认没有下游系统依赖它。
这个动作的结果会直接影响下一步：如果“保留”项超过新站结构能承载的数量，就必须回到业务方确认优先级，而不是让开发先建表。
保留项要过三道适用条件
一个字段进入保留名单前，至少过三道条件。第一，当前业务仍在用它做判断；第二，新站有明确的展示或写入位置；第三，迁移后有人负责维护。三条缺一条，就应降级为归档。
例如“历史标签”在旧系统由运营手工维护，新站没有对应运营岗位，也没有页面展示它。即使数据完整，也不该保留为主字段。反之，“客户等级”若仍影响报价和客服响应，且新站已有权限模块承接，就应保留并明确由谁更新。这里的关键不是技术能不能迁，而是迁过去之后有没有人用、有没有流程接。
假设情境：一次品牌站迁移的取舍过程
假设某品牌站要从旧系统迁到新站，旧系统有 60 个客户字段，新站表单只能稳定承接 25 个。团队先导出近一个业务周期的字段使用记录，发现 12 个字段从未被查询，9 个字段只在旧报表中出现，剩余 39 个字段有实际使用。此时不能直接砍掉 35 个，而要按四类归置：
- 把 18 个仍驱动当前动作的字段列入保留，并逐项指定新站位置。
- 把 7 个重复字段合并为 3 个，例如把多个联系方式合并为主要联系方式。
- 把 14 个只用于历史查询的字段转为只读归档，不进入新站主表单。
- 把剩余字段丢弃，但先确认没有下游导出或对账依赖。
执行后如果发现归档字段仍被客服频繁查询，就把它升级为保留；如果保留字段连续一个周期无人使用，就降级为归档。这个结果会改变下一步：保留名单不是一次定死，而是随业务动作变化调整。
迁移后怎样验证保留项是否选对
验证不看字段数量，而看三个信号：一线人员是否仍绕回旧系统查数据、新站表单是否频繁出现空置字段、归档区是否被高频访问。若客服仍回旧系统查“历史标签”，说明归档入口太深或该字段仍影响判断；若新站保留字段长期为空，说明它可能只是旧系统遗留，不构成当前业务动作。
此时的动作是调整归置，而不是继续加字段。把高频回查的归档项升级为保留，把长期空置的保留项降为归档。字段取舍的终点不是一次迁移完成，而是让新站结构跟当前业务动作保持一致。
