先给结论:当旧系统字段无法完整迁入时,保留项不应按“字段数量”决定,而应按“这个字段是否仍参与当前业务判断”决定。如果某字段只服务于已停用的流程、已合并的岗位或已不再出具的报表,即使数据看起来完整,也可以不迁;反过来,只要字段仍影响报价、交付、对账、售后或合规留痕,即使它残缺、格式混乱、需要人工补录,也应优先保留并单独设计承接方式。这个结论有一个明确的反例:如果旧字段虽然不再参与日常操作,却是历史争议、审计追溯或客户对账的唯一凭据,那么它不能因为“当前不用”就被删掉,而应转为只读归档字段,不进入新系统的业务表单。
把旧系统字段逐个过一遍时,最有效的问法不是“这个字段重不重要”,而是“缺了它,下一步动作会不会做错”。例如旧客户表里有“首次咨询来源”和“最近一次成交渠道”两个字段,如果新站只做线索登记、不做渠道归因,前者可以只保留为备注,后者若仍用于分配销售跟进优先级,就必须保留为可筛选字段。再如旧订单表里的“手工折扣原因”,如果财务仍要按原因分类核对,它就不能只塞进一个自由文本备注,否则后续无法统计。
实际动作可以这样执行:先拉出旧系统中所有被引用的字段,再标注每个字段当前被哪些岗位、哪些报表、哪些对外文件使用。结果会直接影响下一步——被两个以上岗位或对外文件引用的字段进入必留清单;只被单个内部备注引用的字段进入可选清单;没有任何当前引用的字段进入归档评估清单。这个动作的价值在于,它把“字段迁移”从技术问题变成了业务承接问题。
旧系统字段无法完整迁入,常见原因不是字段本身没用,而是旧数据格式与新系统不兼容。比如旧系统用单行文本记录“安装地址”,新系统要求省、市、区、详细地址分开。此时是否保留,取决于业务是否还需要按区域筛选或派单。如果仍要按区域派单,就不能因为拆分麻烦而放弃,而应保留原始文本,同时增加一个“待补全”标记,让后续人工补齐;如果不按区域派单,只用于联系,那么保留一个完整地址文本字段即可。
这里有一个可区分的证据:看旧字段的残缺是“格式不统一”还是“内容本身缺失”。格式不统一可以通过规则清洗或人工补录解决,内容本身缺失则要看缺失比例和影响范围。假设旧系统有一千条客户记录,其中“行业分类”字段有三百条为空,而当前业务仍需要按行业做内容推荐,那么保留该字段并标记空值,比直接删除更合理;反之,如果该字段为空的比例很高,且当前业务已不再按行业分类,那么删除或转为归档备注更合适。这个比较方法只是说明判断逻辑,不是真实项目统计。
前面的结论是“当前不用就可以不迁”,但历史追溯场景会让它失效。假设旧系统里有一个“合同变更次数”字段,当前运营已经不再看它,新站也不展示,但它曾是某类纠纷中判断责任归属的依据。这种情况下,即使当前没有任何岗位日常引用,也不能直接删除,而应把它迁入只读的历史记录表,保留原始值和变更时间。它不参与新站表单,也不影响日常操作,但可以在需要时被检索出来。
因此,保留项要分成三类来处理:业务必留,进入新系统主表并参与筛选、报表或流程;归档可查,不进入日常表单,但保留原始数据并支持按旧编号检索;确认可弃,在确认没有对外承诺、没有审计要求、没有历史争议用途后,才停止迁移。这个分类的关键不是技术难度,而是字段在未来是否可能被重新调用。
建议在正式迁移前完成一张决策表,每行一个旧字段,列包括:当前引用岗位、是否影响对外文件、是否影响对账或售后、是否涉及历史追溯、残缺类型、承接方式。填完后按以下顺序处理:
完成这张表后,下一步不是马上写迁移脚本,而是先拿第一优先级字段做一次小范围试迁,观察新系统里的必填校验、默认值和报表统计是否因此变化。如果试迁后发现某个字段导致大量记录无法保存,就回到决策表调整它的承接方式,而不是强行清空数据。这样,保留项的决定就不再依赖个人记忆,而是有依据、可复核、能随业务变化调整。