四平网站设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4dc373f2fe2d.html
📄
四平网站设计：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入时，保留项不应按“字段新旧”或“数量多少”决定，而应按前端是否可见、业务是否仍在使用、缺失后能否由其他字段推导三条标准排序。假设情境：某四平企业站要从旧CMS换到新系统，旧库有“客户行业”“来源渠道”“跟进备注”等字段，但新系统只提供有限的扩展位，且旧库导出缺少部分权限。此时可执行的最小动作是：先导出能拿到的字段清单和近三个月表单提交样本，逐条标注可见性与使用频率，再决定保留、合并还是放弃。这个动作能缩小争议范围，但不能单凭它证明某个字段一定该删，因为导出缺失也可能来自权限限制而非字段本身无价值。
先分清“迁不进去”的三种原因
字段无法迁入，常见原因并不相同，处理方式也不同。第一种是结构不兼容，例如旧系统把多选值存成逗号分隔文本，新系统只接受固定选项；第二种是权限或导出限制，你能看到后台界面，却拿不到完整数据表；第三种是业务上已废弃，字段还在，但近半年没人填写或查看。把这三类混在一起讨论，容易把“暂时拿不到”误判成“没有用”。
可区分的证据是：如果字段在后台仍可正常查询、导出样本里也有值，只是新系统没有对应控件，那属于结构不兼容；如果导出文件里该列整列为空，但后台单条记录能看到值，那更可能是权限或导出范围问题；如果连续多批样本中该字段填写率极低，且没有下游流程引用它，才更接近废弃。
用“保留、合并、放弃”三档代替逐字段争论
与其对每个字段投票，不如先定三档处理规则，再往里放字段。下面是假设情境中的判断依据，不是通用模板，但方法可复用。
- 保留：前端表单或详情页仍在展示，且业务人员会据此做后续动作。例如“来源渠道”若影响回访优先级，就应保留，哪怕它只是单选。
- 合并：两个字段回答的是同一类问题，只是旧系统拆得细。例如“客户行业”和“客户类型”若在实际使用中经常填成一样，可合并为一个更宽的分类字段，并保留旧值映射关系。
- 放弃：既不在前端出现，也没有人查询，且删除后不影响任何已知流程。放弃前应记录旧字段名和可能的值域，便于日后追溯。
这个分档的关键是：先看使用，再看结构。结构不兼容只说明迁移成本高，不说明该字段该消失。
缺少完整数据或权限时，最小动作是什么
如果拿不到完整导出，不要停在“等权限”。可以先做三件事：第一，从后台逐页截图或复制最近若干条记录，形成小样本；第二，让一线使用者在字段清单上标注“每天用、偶尔用、不用”；第三，把新系统可用字段位数列出来，明确硬约束。这个动作的结果会直接影响下一步：如果小样本显示某字段确实有值且被使用，就进入保留或合并评估；如果小样本也显示长期为空，才进入放弃讨论。
需要提醒的是，样本为空不能单独证明字段无用。它还可能是因为填写入口太深、旧系统校验缺失、或导出时被过滤。遇到这种情况，应把“待确认”单独列一档，而不是直接删除。
一个假设例子：三个字段的去留如何影响后续
假设旧系统有“需求描述”“预算范围”“期望联系时间”三个字段，新系统只允许保留两个自定义字段。先看使用：客服反馈“需求描述”每天要看，“预算范围”多数记录为空，“期望联系时间”偶尔用于安排回访。再看前端：三个字段都曾出现在旧表单，但“预算范围”并非必填。此时较稳妥的处理是保留“需求描述”和“期望联系时间”，把“预算范围”改为在备注中可选填写，而不是直接删除。这个决定的影响是：新表单字段数减少，提交门槛可能降低，但后续若业务确实需要预算筛选，就得在备注里做文本检索，而不是结构化筛选。这个代价是否可接受，取决于业务是否真的按预算做分流。
如果业务确实按预算分流，那么更合理的做法可能是保留“预算范围”并放弃“期望联系时间”，把联系时间并入人工沟通。可见，保留项不是由字段本身决定，而是由它支撑的下一步动作决定。
决定之后要留下什么记录
无论保留、合并还是放弃，都应留下简短记录：旧字段名、处理方式、判断依据、谁确认。这样做的实际作用是，当新站运行一段时间后有人问“以前那个字段怎么没了”，你能回答它是被合并还是被放弃，而不是重新翻旧库。记录本身不保证迁移正确，但能让后续调整有据可查。
最后要明确适用条件：上述方法适用于字段数量有限、业务方还能参与判断的迁移场景。如果旧系统字段极多、且没有任何使用记录可查，那么更现实的做法是先保留原始导出文件，在新系统中只重建当前明确需要的字段，把旧数据作为离线参考，而不是强行把所有字段塞进新结构。这样至少不会因为迁不进去而阻塞新站上线。
