蚌埠网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5031572da1e9.html
📄
蚌埠网站制作：旧系统字段无法完整迁入时怎样决定保留项
结论先给：当旧系统字段无法完整迁入时，不要按“字段多少”决定保留项，而应按“这个字段是否支撑一个当前仍在发生的业务动作”来决定。能支撑动作的字段优先保留，只用于历史记录、且新站没有任何页面或流程消费它的字段，可以暂不迁入。这个结论有一个反例：如果该字段是外部对账、审计或合同履约的唯一凭据，即使当前页面不展示，也必须保留，否则后续无法自证。
先判断字段属于“活的”还是“只读历史”
旧系统里的字段通常分两类。一类仍被当前业务动作引用，例如客户等级、服务状态、订单归属人，这些字段一旦缺失，新站的后台流程就走不通。另一类只在旧记录里存在，例如早期的备注格式、已停用渠道的编码，它们不再被任何新流程读取。
判断方法不是看字段名，而是看“谁在什么时候会用到它”。可以列出最近仍在发生的动作，逐个追问：这个动作的输入或输出是否依赖该字段。依赖的，进入保留清单；不依赖的，进入暂缓清单。
用“动作—字段”对照表替代字段清单
直接罗列几百个字段很难做取舍。更有效的做法是建一张对照表，左边写当前仍在发生的动作，右边写该动作必需的字段。假设一个场景：新站要支持“客户提交服务申请—后台指派—完成回访”三个动作，那么申请时间、指派对象、回访结果就是必需字段；而旧系统里的“录入人所属科室代码”如果新流程不再按科室分派，就可以暂缓。
这张表的作用是暴露遗漏条件。很多迁移失败不是因为字段太多，而是因为某个动作只在一个边缘环节用到某字段，常规清点没发现。把动作写全，遗漏项才会浮出来。
哪些字段即使“没人看”也必须保留
有三类字段不能只用“当前是否展示”来判断：
- 对外凭据类：合同编号、对账标识、发票关联号。它们可能不在页面上出现，但外部机构或客户会拿来核对。
- 时间与责任链类：操作时间、操作人、状态变更记录。缺少它们，后续出现争议时无法还原过程。
- 唯一关联键类：能把旧记录与新记录对应起来的编号。丢掉它，历史数据就变成孤岛。
这三类的共同点是：它们服务的是“以后可能要证明什么”，而不是“现在要显示什么”。如果业务涉及对账、审计或售后追溯，它们应默认保留。
一个会让上述结论失效的反例
如果旧字段虽然属于凭据类，但它的含义已经无法解释——例如编码规则由已离职人员掌握、对照表丢失、同一编码在不同时期代表不同含义——那么强行迁入反而会制造错误数据。此时正确的动作不是保留，而是先冻结该字段，单独标注“含义待确认”，不并入新站主流程，等含义核实后再决定。
换句话说，保留的前提是字段含义可解释、可对应。含义不可解释的字段，保留比丢弃风险更大。
下一步动作：先做一次可回退的试迁
决定保留项之后，不要直接全量迁移。先选一个动作链条做试迁：把该动作涉及的字段导入新站，跑通一次完整流程，检查是否有环节因为缺字段而中断。试迁结果会直接告诉你保留清单是否完整——如果某个动作在第三步卡住，说明对照表漏了一个字段，需要回到清单补充，而不是继续扩大迁移范围。
试迁通过后，再按“保留、暂缓、冻结”三档处理其余字段。暂缓项保留在旧系统中可查，冻结项单独存档并注明待确认，这样既不会让新站背负无用字段，也不会让关键凭据在迁移中消失。
