黄山企业网站设计，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9e8e4f227c3d.html
📄
黄山企业网站设计，旧系统字段无法完整迁入时怎样决定保留项
先给结论：决定保留项的依据不是旧字段“有没有数据”，而是这个字段在新站上是否承担一项可验收的业务动作。如果一个字段只用于内部备注、历史留痕或已停用的流程，即使旧库里全是有效值，也应优先排除；反之，某个字段虽然大量为空，但少数有值的记录直接决定报价、排期或服务边界，就必须保留并补齐录入规则。黄山本地企业常遇到的情况是：旧站由不同阶段拼装而成，字段命名和实际用途早已脱节，迁移时不能按表结构照搬，而要按“谁在什么环节读它、读了之后做什么”来筛选。
矛盾现象：样本里字段都有值，放到全量数据却大量为空
抽取十几条记录试迁时，某个字段看起来完整可用，于是被列入保留清单；等全量导出后才发现，这个字段只在早期录入的客户上存在，后来业务改版，录入人员早已不再填写。这时会出现两种解释。
- 解释一：字段确实已废弃。旧系统某次流程调整后，新记录不再采集该字段，存量有值只是历史残留。判断证据是：按录入时间分段统计，越接近近期，该字段的空值率越高，且客服、销售、生产等岗位的日常操作都不再引用它。
- 解释二：字段仍在使用，只是入口被藏起来了。录入人员仍在别的备注栏、聊天记录或线下表格里写同类信息，只是旧系统界面没有对应入口。判断证据是：随机抽取近期记录，能在备注、附件名或沟通记录里找到同类内容，并且这些内容确实被下游岗位读取。
区分这两种解释的关键动作，是找两三个实际使用该字段的岗位，请他们各自指出最近一次用到它的具体记录，并说明用完之后触发了什么动作。如果没人能给出具体记录和后续动作，倾向排除；如果有人能指出记录并说明它影响了报价、排期或交付范围，倾向保留。
保留项的三条准入条件
把字段逐个过一遍，满足以下条件才进入保留清单，否则放入归档区，只在新站后台以只读方式保留历史值，不进入前台展示和日常录入。
- 有明确的读取方。能说出哪个岗位、在哪个环节会看这个字段，而不是“以后可能有用”。
- 读取后有动作。看完之后会改报价、改工期、改服务范围、改联系优先级，或者触发一次回访。没有动作的字段，价值接近于零。
- 缺失会造成可验证的损失。假设这个字段在新站为空，能否指出一个具体后果，例如无法判断某类客户是否享受过某项服务。如果后果说不清，就不值得为它设计录入和校验。
假设一个黄山本地的服务型企业，旧站有“首次咨询渠道”和“内部对接人”两个字段。前者只有早期记录有值，近期全靠人工在备注里写；后者虽然大量为空，但有值的记录直接决定后续由谁跟进。按上述条件，前者可以归档，后者应保留，并要求新站录入时设为必填或给出默认值。这个例子只用于说明判断方法，不代表任何具体企业的真实数据。
不能照搬的边界：什么时候必须放弃“完整迁移”
规模化迁移时，例外往往出现在三类字段上：自由文本备注、多值标签、以及与其他系统做过映射的编码字段。自由文本备注看似信息量大，但格式不统一，强行结构化会引入大量人工清洗成本，通常只保留原文附件，不拆成新字段。多值标签在旧库里可能用逗号分隔，也可能用分号，迁入前要先确认新站的分类体系是否与旧标签一一对应，对应不上就整体降级为备注。编码字段如果依赖旧系统的字典表，而字典表本身已经停用，就不能只迁编码值，否则新站读到的是一串无意义的数字。
另一个边界是：当旧字段的保留成本高于重建成本时，应选择重建。判断方法是估算清洗、映射、校验和后续维护所需的人工，与让业务岗位在新站上重新采集一次所需的人工做比较。前者明显更高，就只保留历史查询入口，不再要求新数据继续写入。
决定之后，用一个动作验证取舍是否正确
保留清单确定后，不要直接进入全量迁移。先按清单生成一份小规模对照表，把旧值、新值、缺失原因三列并排，交给实际读取方确认。确认时重点看两件事：被排除的字段里，是否有人指出遗漏了关键信息；被保留的字段里，是否有人表示从来不会看。根据反馈调整清单，再进入正式迁移。这个动作的结果直接决定下一步：如果读取方对排除项没有异议，就可以按清单执行；如果出现异议，说明准入条件中的“读取后有动作”判断有误，需要回到岗位访谈重新确认，而不是简单把字段加回去了事。
