咸阳网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /22ae7e35c063.html
📄
咸阳网站开发：旧系统字段无法完整迁入时怎样决定保留项
先别急着写迁移脚本。把旧系统导出一份样本数据，让业务、编辑和技术三方各自标出“没有它业务会断”的字段，再对照新系统的字段容量做一轮取舍。决定保留项的依据不是字段数量，而是每个字段停用后谁的工作会卡住、卡多久。
先分清三类字段，再谈保留
旧系统字段迁不进去，通常不是技术不愿意做，而是新结构里没有对应位置。可以先把待迁字段分成三类：
- 业务凭证类：订单号、合同编号、审批状态。这类字段一旦缺失，后续对账或追溯就断链，通常必须保留。
- 展示内容类：产品描述、图片说明、栏目文案。这类可以合并、改写或重新录入，保留优先级取决于内容量。
- 过程记录类：创建人、修改时间、历史备注。它们对日常运营影响小，但对审计或纠纷处理可能关键。
分类之后，让每个角色只对自己负责的那类字段表态。技术关心类型和长度，业务关心状态流转，编辑关心展示效果。三方对同一字段的理解往往不同，这正是分歧的来源。
把分歧转成可以核对的清单
分歧不能靠开会投票解决，要转成可核对的条目。对每个争议字段，记录四项信息：旧系统里的实际取值样例、新系统是否有承载位置、缺失后受影响的角色、临时替代方式。例如一个“客户等级”字段，旧系统用数字编码，新系统只接受枚举文本，那么先确认编码含义是否有人能解释清楚，再决定是映射还是放弃。
如果某个字段的取值样例本身就是乱的，比如同一含义有五六种写法，那保留它只是把脏数据搬过去。此时更合理的动作是先清洗，再判断是否值得迁入。清洗后仍然无法统一的部分，可以单独存成备注文本，而不是硬塞进结构化字段。
一个注明假设的取舍例子
假设旧系统有一个“来源渠道”字段，取值包括“官网”“电话”“转介绍”等，但新系统只预留了三个渠道位。此时可以这样做：先导出最近一段时间的记录，统计各取值的实际出现次数；把出现次数极少的取值合并为“其他”，把高频取值保留为独立选项。合并后的“其他”不再参与渠道分析，但原始记录仍可查。这个动作的结果是：报表口径变窄，但迁移可以完成，后续再按需拆分。
这个例子的前提是：渠道分析不是当前业务的核心决策依据。如果渠道数据直接决定投放预算，那合并就是不可接受的，应该优先扩展新系统的字段容量，而不是牺牲数据粒度。
决定保留项之后要做什么
保留项确定后，下一步不是马上全量迁移，而是先用一小批数据跑通。跑通的标准是：业务能查到关键凭证，编辑能看到展示内容，技术能确认没有类型错误。任何一方在试跑中发现缺口，都回到清单上补充，而不是在正式迁移时临时改结构。
如果试跑中发现某个被放弃的字段其实有人依赖，不要直接恢复，而是先问清楚依赖的具体场景。场景成立，就把它加入保留项；场景只是习惯，就记录在交接文档里，让新系统的使用方式逐步替代旧习惯。这样处理，字段取舍就不再是三方拉锯，而是一份可以逐条核对的迁移依据。
