昆明网站设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f58ac2d6dae4.html
📄
昆明网站设计：旧系统字段无法完整迁入时怎样决定保留项
先按“字段是否支撑当前业务动作”分三档：直接支撑下单、咨询、售后或对账的字段优先保留；只用于历史统计、且新系统能通过其他记录还原的字段可以退出；介于两者之间的字段先做一次小范围改写验证，再决定是否进入正式迁移。判断依据不是字段数量，而是字段缺失后，哪个岗位会立刻无法完成工作。
保留、改写、退出各自成立的前提
保留的适用前提是：该字段仍参与当前流程，且新系统的数据结构能容纳它的取值方式。例如旧系统用“客户等级”决定报价折扣，新系统也有对应权限层级，这类字段应保留，并明确由谁维护。
改写的适用前提是：字段本身仍有价值，但格式或颗粒度不再匹配。例如旧系统把“地址”写成一个长文本，新系统需要省、市、区分离；此时不是丢弃地址，而是把长文本拆成可校验的结构。改写的代价是要安排一次人工核对，否则拆分错误会进入后续物流或回访环节。
退出的适用前提是：字段对应的业务动作已经停止，或新系统能通过订单、日志、附件等旁路记录还原。比如旧系统单独存的“打印次数”，如果新系统已不再按打印次数计费，就不必为了迁而迁。退出的代价是历史查询会变慢，需要提前说明由谁接受这种不便。
用一次缺失推演代替争论
把候选字段列出来后，不要逐个问“要不要”，而是做一次缺失推演：假设新系统上线后该字段为空，谁会先发现问题，问题会卡住哪一步。若答案是客服无法确认售后归属，或财务无法对账，这个字段应进入保留或改写；若答案是“报表少一列，但不影响当月结算”，就可以进入退出清单。
这个推演要拉上实际使用字段的岗位，而不是只由开发判断。开发看到的是字段类型，业务看到的是动作断点，两者结论经常不同。推演结果直接决定下一步：保留项进入映射表，改写项进入清洗任务，退出项进入归档说明。
假设例子：三个字段的不同处理
假设一个昆明本地服务类旧站要换新系统，旧库里有两个字段：customer_level 和 last_print_time，还有一个长文本 full_address。若 customer_level 仍影响折扣，应保留并映射到新权限字段；若 last_print_time 只用于旧版打印统计，且新流程不再按打印次数收费，可以退出，但要在旧库保留只读备份；若 full_address 要拆成结构化地址，应先抽一批记录试拆，核对拆分准确率，再决定是否全量执行。这个例子只说明比较方法，不代表任何真实项目结果。
决定之后要落成可检查的动作
保留项要写清来源字段、目标字段、默认值和责任人；改写项要写清洗规则、抽样比例和异常回退方式；退出项要写归档位置和查询替代路径。动作的结果会影响下一步：如果抽样清洗的错误集中在某一类记录，应先修规则再扩大范围；如果退出项在试运行期间被频繁查询，就应重新评估是否保留只读入口。
最后用一条验收线收口：新系统上线后，任一字段为空时，业务是否能按约定路径完成动作。能完成，退出成立；不能完成，就回到保留或改写。决定保留项的过程，本质上是把“旧数据不能丢”翻译成“哪个动作不能断”。
