网站设计规范：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0461f0507a8d.html
📄
网站设计规范：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入时，保留项不应由“字段多少”决定，而应由“这个字段是否仍参与当前业务判断”决定。假设一个情境：某企业官网从旧CMS迁到新系统，旧库里有“客户来源渠道”“历史报价备注”“内部跟进等级”等字段，新系统只能保留其中一部分。此时正确做法是先按业务动作分类，再决定哪些字段必须原样保留、哪些可以合并、哪些只能归档。
先区分“展示字段”和“决策字段”
旧系统里很多字段看起来重要，实际只用于历史展示。判断标准是：如果删掉它，当前页面内容、表单提交或后台跟进会不会出现错误。不会，就归为展示字段；会，就归为决策字段。
- 决策字段：影响表单校验、权限判断、报价计算、线索分配或对外承诺。这类字段必须优先保留，哪怕新系统需要改字段类型。
- 展示字段：只用于旧页面展示、历史备注或内部参考。可以转为附件、归档说明或统一备注，不必强求一对一迁入。
- 过渡字段：当前业务已不再使用，但合同、审计或客服追溯可能还需要。应保留可查询入口，而不是继续放在主表单里。
实际动作：先拉出旧字段清单，逐项标注“删除后会不会导致业务动作失败”。结果会直接决定下一步是设计映射规则，还是进入归档方案。
用“变化前后”决定保留强度
关键前提发生变化时，保留策略要分前后两段。变化前，旧字段可能支撑旧流程；变化后，如果新流程不再依赖它，就不应为了迁而迁。
- 变化前仍在使用：字段必须保留，并验证新系统能否承接相同业务含义。
- 变化前已停用，变化后也不会恢复：转为归档字段，只保证可查，不进入新表单。
- 变化前使用，变化后由新字段替代：建立旧到新的映射说明，避免同一业务出现两个真值来源。
假设旧系统用“跟进等级”决定销售分配，新系统改为“区域+产品线”分配。此时“跟进等级”不再参与新决策，但历史线索仍可能需要追溯。合理做法是把它放入只读历史记录，而不是继续放在新建线索的必填项里。这样下一步的字段设计就不会被旧逻辑拖住。
无法完整迁入时，优先保留三类字段
字段冲突无法全部解决时，按以下顺序保留，能减少业务中断：
- 身份与关联字段：客户编号、订单号、合同号。没有它们，历史记录无法和新记录关联。
- 状态与时间字段：创建时间、状态变更时间、处理结果。它们决定后续追溯和统计口径。
- 责任与权限字段：负责人、所属部门、可见范围。缺失会导致数据越权或无人接手。
如果新系统字段长度、类型或必填规则不同，不要强行把旧值塞进不匹配的字段。更稳妥的做法是增加一个“旧系统原始值”备注字段，保留原值，再用新字段承载新规则。这样既满足新规范，也不丢失旧证据。
验证保留项是否真的成立
决定保留哪些字段后，要用小范围数据验证，而不是直接全量迁移。验证时重点看三件事：
- 新表单提交后，保留字段是否出现在正确位置。
- 旧记录查询时，归档字段是否还能被找到。
- 同一业务含义是否出现两个互相矛盾的字段值。
假设迁移后发现“历史报价备注”被拆成两个新字段，但客服仍按旧备注回复客户。这说明保留项没有落到实际使用路径，应回到字段分类重新判断，而不是继续加字段。验证结果会决定是调整映射规则，还是把该字段降为归档项。
把决定写成可执行的迁移规则
最终要形成一份字段处理表，每个旧字段只对应一种处理方式：保留、合并、归档或废弃。保留项要写明新字段名、是否必填、由谁维护；归档项要写明查询入口和保存期限；废弃项要说明替代字段或不再使用的理由。这样开发、运营和客服才能按同一套规则执行，而不是在迁移过程中反复争论某个字段要不要留。
如果旧字段涉及对外展示内容，还要检查新页面是否仍需要呈现。不需要展示的字段，不必为了“完整”而出现在前台；只需要内部追溯的字段，放在后台归档比放在公开页面更合适。保留项的决定标准始终是当前业务动作，而不是旧系统里字段的数量。
