岳阳网站制作，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e568d9de88e4.html
📄
岳阳网站制作，旧系统字段无法完整迁入时怎样决定保留项
先别按“字段新旧”决定去留，而要先确定每个字段背后对应哪一项业务动作。能独立触发动作、且新系统没有等价替代的字段优先保留；只用于展示、统计或历史备注的字段，可以降级为附件或备注。判断依据不是数据量大小，而是缺少它之后，哪一步流程会停下来。
矛盾现象：同一张表，三个人给出三种结论
迁移评审会上常出现这种局面：技术负责人说某字段“没地方放”，业务负责人说“这个必须留”，运营负责人说“从来没用过”。三方看的是同一份旧表，分歧却不在事实本身，而在各自默认的用途。
技术方关注的是目标结构能否容纳该字段的数据类型和长度；业务方关注的是某张单据、某次审批是否依赖它；运营方关注的是日常操作里是否真的会打开它。三种理解都成立，但指向的保留标准不同。如果不先把用途摊开，讨论会一直在“重要不重要”上打转，而无法收敛成可核对的清单。
两种解释：字段真的在用，还是只是历史遗留
对“必须保留”的字段，至少有两种合理解释。
解释一：字段仍在驱动当前流程。例如旧系统里的“客户来源”会影响后续跟进分配，或者“合同编号”被用于对账。这类字段一旦缺失，新系统上线后会出现无法补录、无法对账的空洞。
解释二：字段只是历史数据的痕迹。它当年被录入过，但现在的流程早已绕过它，只是没人清理。保留它更多是出于“怕以后要看”的心理，而不是有明确的使用场景。
这两种解释对应完全不同的处理方式。前者需要在新系统中找到承接位置，后者可以归档为只读备注，甚至只保留在导出文件里。混淆二者，就会出现“为了一个没人用的字段改结构”或者“删掉之后业务停摆”两种极端。
区分两种解释的证据：查动作，不查字段名
要区分上面两种情况，可以按下面的顺序核对，每一步都留下可复查的记录。
- 找出引用该字段的流程节点。在旧系统的表单、审批流、报表或导出模板中搜索字段名，记录它出现在哪一步。如果只出现在列表展示里，说明它更接近展示项；如果出现在提交、校验或分配逻辑里，说明它参与动作。
- 确认是否有替代字段。新系统中是否已有语义相近的字段可以承接？如果有，比较两者的取值规则是否一致。规则不一致时，直接合并会造成数据含义漂移，需要单独处理。
- 询问最近一次真实使用的场景。不是问“这个字段重要吗”，而是问“上一次因为要看它而打开旧系统，是什么时候、为了什么事”。能说出具体事件，说明仍在用；只能回答“应该会用到”，说明证据不足。
- 检查数据完整度。如果该字段在旧数据中大量为空或长期使用默认值，它驱动流程的可能性较低。但要注意，空值也可能是因为录入环节被跳过，不能单独作为删除依据。
做完这四步，通常能把字段分成三类：必须承接、可降级归档、可放弃。分类结果直接决定下一步是调整新系统结构，还是只做数据导出留存。
一个假设例子：保留项如何影响后续动作
假设旧系统有一个“安装预约时段”字段，取值是上午或下午。新系统采用统一的预约时间选择器，不再区分时段。评审时业务方坚持保留，理由是“师傅排班要看这个”。
核对后发现，排班实际使用的是另一个“派工日期”字段，时段只用于短信通知文案。这种情况下，时段字段不需要作为独立结构迁入，只需在通知模板中根据派工时间生成对应文案即可。保留项从“新增字段”变成“模板逻辑”，开发量下降，排班流程也不受影响。
反过来，如果核对发现派工逻辑确实按时段分流，那么它就必须作为独立字段迁入，并且要确认新系统的取值枚举能覆盖旧数据中的全部取值。这个结论会直接改变迁移脚本的映射规则和测试用例，而不是停留在“留还是不留”的口头争论上。
把分歧转成可核对的项目
要让多个角色对同一事实达成一致，可以把每个争议字段写成一条核对项，至少包含：字段名、旧系统中的引用位置、最近一次使用事件、新系统承接方式、验证人。验证人不是签字背书，而是负责在测试环境中实际走一遍相关流程，确认缺少或保留该字段后，流程是否按预期运行。
核对项完成后，保留决策就不再依赖职位高低或印象强弱，而是依赖“哪一步会停下来”这个可观察的结果。下一步的迁移脚本、测试范围和上线检查项，都可以直接从这份清单派生，减少反复确认的成本。
