蚌埠网页设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /67f4f7ae9c12.html
📄
蚌埠网页设计：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按字段在新系统里“有没有对应位置”来决定去留，而要按“这个字段离开旧系统后，还有没有人在什么场景下必须读到它”来决定。能回答出具体使用场景的，想办法保留；答不出来的，先归档不迁入。下面用一个假设情境把决策过程走一遍。
假设情境：一个本地服务站的旧表单字段迁不进去
假设蚌埠一家做本地安装服务的站点要换掉旧系统。旧系统里有客户提交的咨询表单，字段包括：联系人、电话、所在小区、房屋面积、装修阶段、意向时间、备注、来源渠道、旧系统内部编号。新系统的表单结构更简单，只能容纳联系人、电话、备注和几个固定选项。
这时真正的问题不是“怎么把九个字段塞进四个位置”，而是：哪些字段承载的信息一旦丢失，后续业务会真的受影响？
第一步：按“谁在什么时候读它”给字段分组
把每个字段问三个问题：谁读、什么时候读、读不到会怎样。按结果分成三类，比按技术难度分类更可靠。
- 业务必须读：客服回访时要用的电话、要确认的服务地址或小区。读不到就无法开展下一步。
- 偶尔回查：装修阶段、意向时间、来源渠道。平时不看，但做阶段统计或判断线索质量时可能翻出来。
- 基本不再读：旧系统内部编号、重复的备注副本。它们只在旧系统内部有意义，离开后没有消费方。
分组之后你会发现，真正需要迁入的字段往往远少于旧系统的字段总数。这一步的实际动作是：把分组结果写成一张清单，交给实际使用这些数据的人确认，而不是由建站方单方面判断。
第二步：为“必须读”的字段找替代承载方式
新系统没有对应字段，不等于信息只能丢掉。常见做法有三种，各有适用条件。
- 并入备注：适合低频、非结构化的信息，比如房屋面积。缺点是以后无法按这个字段筛选，只能人工看。
- 转成固定选项：适合取值有限的字段，比如装修阶段。前提是旧数据里的取值能被归并成几类，归并不了的单独留一档。
- 单独建一张历史表：适合偶尔回查但新系统不需要展示的字段。新表单不显示，后台仍可查。前提是有人愿意维护这张表，否则它很快会变成死数据。
假设你选择把“意向时间”并入备注。结果是新系统里无法按意向时间排序，客服只能逐条打开看。如果你确认客服本来就不会按这个排序，这个取舍成立；如果会，就应该把它转成固定选项而不是塞进备注。
第三步：用“迁移失败后的补救成本”反推保留项
当两个字段都拿不准时，比较它们的补救成本，而不是比较它们看起来重不重要。
假设“所在小区”没迁进来，事后想补，只能打电话问客户，成本高且有打扰；假设“来源渠道”没迁进来，事后基本补不回来，但也很少有人真的去补。前者应该优先保留，后者可以接受丢失。
判断标准可以简化成一句：这条信息丢了以后，是“以后还能问回来”，还是“永远问不回来且有人会要”。后者才值得为它改结构。
第四步：迁移后做一次抽样核对，再决定是否扩大
不要一次性迁完全部数据再检查。先取一小批记录做试迁，核对三类字段的实际落位：必须读的字段是否每条都有值、归并成选项的字段有没有落空、备注里并入的内容有没有被截断。
试迁结果会直接改变下一步：如果必须读的字段出现空值，说明旧数据本身不完整，需要先决定空值怎么处理，而不是继续迁；如果归并选项大量落空，说明取值分类没做够，要回到第二步重新归类；如果备注被截断，就要检查新字段的长度限制，必要时把长内容拆到历史表。
抽样核对的作用是暴露规则问题，不是证明迁移正确。某个字段全部为空，可能是旧系统本来就没收集，也可能是导出时漏了，这两种原因对应的处理完全不同，需要分开确认。
把决定写下来，避免反复
最后把每个字段的去向固定成一句话：迁入哪个字段、并入备注、转成选项、进历史表，还是不迁。写清楚理由和确认人。这样下次有人问“为什么这个字段没了”，不需要重新讨论一遍。旧系统退出时，字段取舍本来就是一次业务判断，不是纯粹的技术搬运。
