建站规划方案：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /80f8db3fdbed.html
📄
建站规划方案：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入时，保留项不应按“字段数量”决定，而应按“字段消失后是否会让某条业务动作无法完成”来决定。具体做法是先把字段分成阻断型、解释型、装饰型三类，再对每一类做一次可逆性测试——如果删掉后仍能通过其他字段或线下记录还原，就不进入新库；如果删掉后订单、审批、对账或售后其中任一环节会断，就必须保留，哪怕它在新系统里只是备注字段。
矛盾现象：字段越迁越少，业务却说“没丢东西”
常见情况是：旧库有 60 个字段，新系统只能承接 35 个，迁移报告显示“成功”，但客服、财务或仓库仍能正常运转。这时容易得出一个错误结论——剩下 25 个字段本来就没用。另一种解释同样成立：那 25 个字段的使用频率极低，只是恰好没在迁移后的观察期内被触发。两种解释对应完全不同的处理方式，不能靠“目前没出问题”来判断。
要区分它们，需要找的是“触发条件”而不是“使用次数”。低频字段往往绑定在退货、换票、跨期结算、历史合同调阅这类不常发生的动作上。只要这些动作在观察期内没有发生，字段缺失就不会暴露。因此，判断保留项的第一步不是看日志，而是列出业务上一年只发生几次、但一旦发生就必须查旧记录的动作。
两个解释：字段真的冗余，还是触发条件未出现
解释一：字段冗余。该字段的值可以从其他字段推导出来，或者旧系统里长期为空、填写规则互相矛盾。例如“客户全称”与“客户简称”并存，但简称从未被任何流程引用，这类字段不进入新库不会造成阻断。
解释二：触发条件未出现。字段本身有明确用途，只是对应业务动作发生频率低。例如旧系统中的“原订单号”“换货原因代码”“跨月结算标记”，平时几乎不出现，但一旦发生退货或跨期对账，缺少它们就无法把新旧记录关联起来。
这两种解释的区别不在于字段多少，而在于：删掉它之后，是否存在一个可预期的业务动作会因此无法完成。如果存在，就是解释二；如果所有可预期的动作都能绕开它，才接近解释一。
能区分两种解释的证据
可以用下面这组证据来判断，而不是依赖迁移工具的默认映射结果：
- 字段被哪些流程引用：查旧系统的表单、打印模板、导出报表和接口调用记录。只要字段出现在对外单据、财务凭证或售后凭证上，就应视为阻断型。
- 字段值的可还原性：如果字段值能由订单号、时间戳、操作人加规则推导出来，可以降级为解释型；如果推导需要人工判断或外部记录，应保留。
- 缺失后的补救成本：假设某字段未迁入，出现一次退货时需要人工翻旧库、比对纸质单据或联系客户确认。若单次补救超过可接受范围，就应保留。
- 字段之间的依赖关系：有些字段单独看无用，但被其他字段的计算或筛选引用。删除前要确认没有下游规则依赖它。
这些证据指向同一个判断：保留项的价值体现在“防止某个动作断掉”，而不是体现在“曾经被填写过”。
假设例子：用一次可逆性测试决定保留项
假设某旧系统有“结算批次号”字段，新系统没有对应位置。可以先做一次可逆性测试：把该字段暂时不迁入，然后模拟一次跨月对账。如果对账人员能通过订单号加结算日期还原批次，说明该字段可降级为解释型；如果必须依赖批次号才能区分同一日期的多笔结算，则它属于阻断型，应保留为备注或独立字段。
这个测试的动作是“模拟一次低频业务动作”，结果是：能还原则删除，不能还原则保留。下一步据此更新字段映射表，而不是等真实业务出问题后再回补。需要注意，这个例子是假设的比较方法，不代表任何具体系统的实际表现。
决定保留项后的落地动作
确定保留清单后，不要直接开始批量导入。先做两件事：第一，为每个保留字段标注它在哪个业务动作中被引用，以及缺失时的补救路径；第二，把保留字段分成“必须结构化存储”和“可作为备注文本存储”两类。前者用于会被查询、筛选或参与计算的字段，后者用于只在人工查阅时需要的字段。
这样处理的结果是：新库的字段数量可能仍然少于旧库，但每一个被删掉的字段都有明确的删除理由，每一个被保留的字段都有对应的业务动作。后续如果出现新的迁移问题，可以按同一套分类和可逆性测试重新判断，而不必重新争论一遍“这个字段到底有没有用”。
