随州企业建站，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /68214bab58ca.html
📄
随州企业建站，旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段迁不全时，不要按“新系统能装多少”来砍，而要按“丢了这个字段，哪条业务动作会断”来留。把每个字段对应到一个具体动作（报价、发货、对账、售后），动作断了就必须保留，动作能靠备注或线下补的，才允许放弃或降级。
用一个假设情境看清取舍逻辑
假设随州一家做专用车配件的小厂，旧站后台里产品表有 26 个字段：型号、材质、适配车型、起订量、交期、含税价、不含税价、运费模板、库存状态、替代型号等。新站产品模型只开放 12 个自定义字段。这时常见做法是“先导能导的”，结果上线后业务员发现客户问“这个型号能不能装在某款底盘上”，页面上没有适配车型，只能人工回复。这就是典型的字段取舍失误——被砍掉的恰好是高频业务动作依赖的字段。
第一步：给每个字段标出它支撑的业务动作
把旧字段逐个写成“字段名 → 谁在用 → 用来做什么决定”。判断标准不是字段重不重要，而是它是否直接参与一次对外承诺。可以按下面三类归档：
- 承诺类字段：客户据此下单或询价，如价格、起订量、交期、适配范围。缺失会导致报价错误或纠纷，原则上必须保留。
- 筛选类字段：客户用来缩小范围，如材质、规格、适用场景。缺失会让查找变慢，但可通过分类或描述部分弥补，属于可降级项。
- 内部类字段：仅供内部记录，如录入人、内部编号、旧系统主键。对外无影响，可留在旧系统或导出为对照表，不必强塞进新站。
这样分类后，26 个字段里真正必须迁的往往只有 8 到 12 个，剩下的可以用合并字段、详情描述或外部对照表承接。
第二步：判断“装不下”是真限制还是假限制
字段数量不够，先别急着删。要区分三种情况：
- 模型限制：新站产品表确实只允许固定数量的自定义字段。此时优先保留承诺类，把筛选类合并成“规格参数”一段结构化文本。
- 结构错配：旧字段是自由文本，新站要求枚举值。例如“交期”旧系统写“7-15天”，新站只接受数字。这时应保留字段名，把值统一成区间或标准单位，而不是删字段。
- 关系缺失：旧系统里“适配车型”是独立表，新站没有关联表。可以把它降级为产品描述中的固定段落，但要保证每个产品都填写，否则等于没迁。
如果确认是模型限制，就按上一步的分类做减法；如果是结构或关系问题，优先改数据形态，不要直接砍字段。
第三步：用一条真实业务链验证保留项是否够用
字段清单定下来后，拿一个最复杂的真实产品走一遍完整流程：客户搜索 → 查看详情 → 询价 → 报价 → 下单 → 售后。每走一步，检查所需信息是否都能在新站找到。假设某型号在旧系统里有“替代型号”字段，新站没保留。客户原型号停产时，业务员无法在页面提示替代品，只能逐个回复。这说明“替代型号”虽不是价格类字段，但支撑售后动作，应升级为保留项。
反过来，旧系统里的“录入时间”“最后修改人”这类字段，走完整流程时没有任何一步用到，就可以不迁。验证时至少覆盖两类产品：常规款和特殊款，因为特殊款往往依赖更多字段。
第四步：确定降级方案和后续动作
对不能完整迁入的字段，不要简单丢弃，而是明确降级方式并指定负责人。常见降级方式有三种：
- 合并：把多个筛选类字段合并成一个“技术参数”字段，用固定分隔符或短标签区分。
- 外挂：字段留在旧系统或导出的对照表中，新站只保留查询入口或说明文字。
- 人工补：页面上留空，由业务员在沟通中补充。这种方式只适用于低频、非承诺类字段。
每确定一个降级项，就记录：降级方式、影响哪个动作、由谁在什么时间补全。例如把“运费模板”降级为“运费另议”，就要在询价表单里增加一个提示，并让客服在首次回复时说明。这个动作会直接影响下一步——如果降级后客户询价量上升但转化下降，说明该字段其实属于承诺类，应重新评估是否迁入。
不能直接照搬的边界
上面这套方法适用于旧系统字段多、新站字段少的场景。但如果旧系统本身字段混乱、大量重复或长期无人维护，就不能按“业务动作”逐条判断，而应先做字段清理，否则会把旧问题一起迁进新站。另外，如果企业业务模式正在调整，比如从批发转向零售，旧字段对应的动作可能已经消失，这时保留项应以新业务为准，而不是以旧系统为准。判断依据是：该字段对应的动作在当前和未来半年内是否仍会发生。如果答案是否定的，即使旧系统里天天用，也可以不迁。
