渭南建网站：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /80c6154d9cd8.html
📄
渭南建网站：旧系统字段无法完整迁入时怎样决定保留项
先把“字段能不能迁”改成“字段值保不保真”：能直接搬过去的不等于必须保留，搬过去会变形、会丢语义、会制造两套口径的，才需要进入取舍。决定保留项的依据不是字段数量，而是这个字段离开旧系统后，是否还有角色愿意为它的准确性负责。
假设一个改版情境：同一批客户记录，三个角色三种说法
假设渭南一家做本地工程配套的企业要重建网站，旧系统里有一张“客户咨询记录”，字段包括手机号、需求描述、来源渠道、跟进人、备注、客户等级、首次联系时间。新系统只支持固定表单字段，备注和等级没有对应位置。此时销售说等级必须留，客服说备注最重要，负责网站的人说只留手机号和需求描述就够。三种说法都不算错，因为它们各自对应不同的后续动作。
把分歧转成可核对的项目，可以要求每个角色回答同一个问题：如果这个字段在新系统里消失，你下一次做决定时缺哪条信息？销售缺等级，就无法判断先联系谁；客服缺备注，就无法判断上次沟通到哪一步；网站负责人缺来源渠道，就无法判断哪个入口带来的咨询更值得继续优化。答案不同，保留项自然不同。
先判断字段属于哪一类：事实、判断还是过程
旧系统字段迁不完整时，最容易犯的错是把所有字段都当成同等重要的数据。更实用的分法是把字段分成三类，再决定保留顺序。
- 事实类字段：手机号、提交时间、需求描述。这类字段一旦丢失，后续无法补录，通常优先保留。
- 判断类字段：客户等级、意向评分、优先级。这类字段依赖某个人的判断，换系统后判断标准可能已经变化，保留时要连同判断依据一起考虑。
- 过程类字段：跟进人、备注、沟通记录。这类字段往往只对当前处理人有用，如果新系统没有对应流程，硬搬过去只会变成无人维护的死数据。
这个分类的作用是让讨论从“哪个字段重要”转向“哪类信息离开旧系统后还能被使用”。事实类字段通常直接保留；判断类字段要问标准是否仍然成立；过程类字段则要看新系统是否真的会继续产生同类记录。
用“迁移后谁维护”作为保留与否的硬条件
一个字段值得保留，除了历史价值，还要看迁移后有没有人继续填写、继续核对。假设旧系统里的“客户等级”由销售主管每周手动调整，新网站没有后台分级功能，只能写进备注。那么保留这个字段的结果，是等级变成一段不会更新的文字，几个月后反而误导后来的人。
反过来，如果新系统虽然字段名不同，但有一个“意向说明”输入框，且客服每天都会填写，那么旧备注可以按规则截取关键句迁入，并明确标注这是历史记录。此时保留成立的条件不是字段名一致，而是新位置有人负责。
实际操作可以这样：先列一张保留项核对表，每一行写字段名、迁移后的存放位置、维护角色、更新频率。任何一行如果维护角色为空，就先不进入保留清单，而是进入“归档但不展示”清单。这个动作的结果会直接影响下一步：保留清单用于新系统建字段，归档清单只用于必要时人工查询，不再占用页面和表单。
当两个角色坚持不同字段时，用一组可核对证据收敛
分歧不能靠投票解决，因为投票只反映人数，不反映使用频率。更可靠的做法是找一组可核对证据，让双方对同一批记录做判断。
- 从旧系统抽取一小批记录，数量不必大，覆盖不同来源和不同处理阶段即可。
- 让每个角色在不看对方结论的情况下，只凭自己坚持保留的字段，写出下一步动作。
- 对比结果：如果缺少某个字段就无法写出下一步，说明它是决策必需项；如果缺少后仍能写出下一步，说明它可以降级为参考项。
- 把结论写回核对表，并注明判断依据来自哪一批记录，而不是来自个人偏好。
这个过程的产出不是“谁赢了”，而是一份可以复查的保留理由。下次再有人问为什么某个字段没迁，直接看当时填写的下一步动作即可。
保留项确定后，先做小范围试迁再全量处理
保留清单确定后，不建议立即全量迁移。先选一小批记录试迁，重点检查三件事：字段值是否被截断、判断类字段是否失去原有限定、过程类字段是否还能看出时间顺序。试迁结果如果发现某个字段大部分记录为空，就要重新评估它是否值得占用新系统的位置。
需要提醒的是，旧系统里某个字段查询量下降、抓取记录归零，并不能单独证明它不重要。也可能只是旧入口已经很少有人访问，或者统计方式发生了变化。判断保留项时，应把这类现象当作线索，而不是结论，回到“谁在什么动作里会用到它”这个问题上。
最终决定可以归纳成一句话：能补录的事实字段优先留，依赖旧判断标准的字段谨慎留，没有新维护人的过程字段归档不留。按这个顺序处理，迁移后的系统不会因为字段太多而难用，也不会因为删得太快而失去关键线索。
