先给结论:不要按“新系统能建多少字段”来决定保留项,而要按字段是否仍在业务流程中产生动作来决定。旧字段只要还影响查询、审批、对账、通知或对外展示中的任一环节,就应进入保留清单;如果只是历史录入习惯、无人读取、也不参与任何后续动作,才适合归档而不迁入。真正困难的是介于两者之间的字段,这时应先用一轮小范围验证,再决定是迁入、合并还是只留只读映射。
旧系统字段无法完整迁入,通常不是技术容量问题,而是新模型没有对应位置。判断保留项时,先看字段是否仍在驱动动作。例如一个旧客户表里有“客户来源备注”“首次接触渠道”“历史跟进人”三个字段。若新系统只保留标准来源分类,那么“客户来源备注”可能仍被销售在报价前查看,属于保留项;“首次接触渠道”若已并入标准来源,可以合并;“历史跟进人”若只用于追责且当前流程已改为按团队分配,则更适合归档。
这里的关键证据不是字段有没有值,而是有没有人因为看到它而改变下一步动作。可以抽查最近一段时间的实际流程记录,观察哪些字段被打开、被引用、被复制到邮件或工单中。若某个字段长期只出现在导出报表里,却没有任何人根据它做判断,它就不应优先占用新系统的必填位置。
当字段仍参与当前业务动作,且新系统有明确承载位置时,选择迁入。迁入不只是把值搬过去,还要定义它在哪个页面出现、是否可编辑、由谁维护、变更后是否触发通知。实际动作可以这样安排:先列出字段名、旧表来源、新表目标、是否必填、默认值来源,再让业务方逐项确认。确认后,下一步才是写迁移脚本和做抽样比对。这个动作的结果会直接影响后续验收:如果目标字段没有明确归属,迁移后就会出现“数据在但没人敢用”的情况。
当字段仍有查询价值,但新系统没有对应编辑场景时,选择只读映射。只读映射的代价是旧值不能在新系统内修改,只能回旧系统或由管理员批量处理。适用条件是:该字段主要用于历史追溯、审计或客服查证,不参与新流程的创建和审批。此时应把字段放在详情页的“历史信息”区域,并标注数据来源和最后同步时间。若后续业务方要求编辑,就必须重新评估是否升级为可写字段,而不是在只读区域偷偷加编辑入口。
当团队对某个字段是否保留争执不下时,不要继续开会投票。可以选一小批真实记录,按假设的迁移规则跑一遍,再让实际使用者在测试环境里完成一次典型任务。例如假设有 50 条客户记录,其中 12 条带有旧字段“特殊结算说明”。让财务和销售各走一遍报价到结算流程,观察他们是否主动打开该字段、是否因为看不到它而停下来询问。若多数人需要它才能完成动作,就保留;若只有个别人出于好奇查看,就降级为归档。
这个验证的假设必须写清楚:样本来自哪个时间段、覆盖哪些业务类型、参与者是否熟悉新旧流程。验证结果只说明这批样本下的使用情况,不能直接推导为全量结论。它的价值在于把“我觉得重要”变成可观察的动作差异,从而决定下一步是扩大迁移范围,还是把字段移入归档库。
有些旧字段不是保留或丢弃的二选一,而是可以合并。合并的前提是能说清映射规则和冲突处理。比如旧系统有“手机”“备用电话”“紧急联系人电话”三个字段,新系统只保留“主要联系方式”和“备用联系方式”。此时不能简单把三个值拼在一起,而要先定义:哪个优先进入主要联系方式,重复值怎么去重,空值怎么处理,历史记录是否保留原字段名。
可执行的动作是先做一张映射表,列出旧字段、新字段、转换规则、冲突示例。然后抽取包含冲突的记录做人工核对。若冲突比例高到无法自动处理,就应保留原字段为只读备注,而不是强行合并。合并后的结果会影响后续查询和通知:如果主要联系方式被错误覆盖,通知就可能发错人,这时必须回退到只读映射方案。
有一类字段不能因为“最近没人看”就归档。涉及合同条款、同意记录、财务凭证、对外承诺或监管留存的字段,即使当前流程不再主动读取,也应保留可查。适用条件是:组织有明确的留存要求,或该字段是某份对外文件的唯一凭证。此时应保留原值、原时间戳和来源系统标识,并确保只读可查。
这类字段的处理动作不是迁入日常编辑表单,而是进入独立的留存区,并限制修改权限。它的代价是增加存储和查询复杂度,但换来的是后续核对时有据可依。若把这类字段混入普通业务字段一起决定去留,就容易在审计或纠纷时找不到原始记录。
最终决定保留项时,可以用一句话检验:这个字段是否还会让某个人做出不同动作,或者是否必须为过去某个动作留下证据。前者指向迁入或合并,后者指向只读留存。两者都不满足的字段,才适合归档不迁入。