乌海网站设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d476d7fbd61.html
📄
乌海网站设计：旧系统字段无法完整迁入时怎样决定保留项
先按“字段是否承载业务闭环”分两类：能独立支撑查询、审核或对账的字段优先保留；只服务于旧界面展示、统计口径已失效或无人认领的字段，可以归档而不迁入。判断依据不是字段数量，而是字段停用后哪一步业务会断。
第一类：字段参与当前业务闭环，优先保留并补齐来源
如果某个字段被前台查询、后台审核、财务对账或售后追踪直接引用，它就不是“历史遗留”，而是当前流程的一部分。此时应保留字段本身，同时把旧系统里的取值规则、空值含义和更新频率一起迁入。只迁数据不迁规则，新系统里会出现大量看似有值、实际无法判断的字段。
假设一个旧客户表里有“客户等级”和“最近跟进时间”两个字段。等级被销售分配规则引用，跟进时间被提醒任务引用，两者都应保留。实施时先拉出最近一个完整业务周期的记录，核对每个字段的取值分布；如果某字段超过九成记录为空，且没有当前流程引用它，就转入待归档清单，而不是直接删除。
这一步的实际动作是：让业务方逐字段标注“停用后哪一步会断”。标注结果直接决定下一步是进入迁移脚本，还是进入归档说明。没有业务方签字的字段，不进入迁移范围。
第二类：字段只服务旧展示或旧统计，转为归档并写清替代口径
旧系统里常见一类字段，只在旧版页面模板、旧报表或已停止的统计任务中使用。它们不影响当前下单、咨询或内容发布，但删除后可能让历史记录无法解释。对这类字段，合理选择是归档原始值，并在新系统里保留一个可读的备注或附件入口，而不是强行塞进主表。
例如旧系统用“页面模板编号”区分不同展示样式，新系统已改为统一组件。这个编号对当前编辑没有作用，但客服回溯旧页面时可能用到。此时可把编号和对应页面截图一起归档，主表不再保留该列。这样既减少迁移时的字段冲突，也不切断历史解释链。
例外是：如果该字段被外部对账、合同附件或监管留存要求引用，即使当前界面不再展示，也应保留原始值并标记来源系统。是否属于例外，由业务、财务和法务各自确认，不能由开发单方判断。
把分歧转成可核对的项目：字段卡与三方签字
多个角色对同一字段的理解经常不同：销售认为“客户来源”必须保留，编辑认为它只是旧表单的默认值，开发则发现该字段在新库里没有对应类型。解决办法不是开会争论，而是把每个争议字段做成一张字段卡，包含旧字段名、旧取值示例、当前引用位置、停用后的影响步骤、建议处理方式和确认人。
- 旧字段名与旧系统里的实际取值示例，至少三条，避免只写“文本型”这类空描述。
- 当前引用位置：写清是前台查询、后台审核、报表、对账还是无人引用。
- 停用后的影响步骤：具体到“无法按来源筛选咨询”或“历史订单无法对应合同”这种可核对动作。
- 建议处理方式：迁入主表、迁入归档表、只保留备注或直接停用。
- 确认人：业务、财务、法务或内容负责人中实际使用该字段的人。
字段卡完成后，先拿五到十个争议最大的字段做一轮试迁。试迁结果如果出现“主表字段冲突”或“历史记录无法关联”，就回到字段卡调整处理方式；如果试迁后业务方能完成一次完整查询或对账，就把该处理方式固化为规则。这个动作的影响很直接：它把“要不要保留”变成“保留后能不能完成一次真实操作”，后续迁移范围随之收窄。
迁移前必须确认的适用条件与停用边界
保留项决策成立的前提是：旧系统仍可读取、业务方愿意逐字段确认、新系统允许归档表或备注字段存在。如果旧系统已经无法导出完整取值，或业务方无法指定确认人，就不适合做精细保留，而应先做数据可用性评估，再决定是否整体归档。
另外，请求量、抓取量或某张报表归零，不能单独证明某个字段可以停用。归零还可能来自统计任务停止、权限变更、页面入口下线或数据被其他字段替代。要区分这些原因，需要对照旧系统的任务日志、权限记录和页面变更记录，而不是只看一个数字。
最终决定保留项时，用一句话写清结论：该字段停用后，哪个角色、哪一步操作会无法完成；如果找不到这个角色和步骤，就归入归档清单，并注明替代查询方式。这样迁移范围、归档范围和后续核对责任都能落到具体项目上，而不是停留在“先迁过去再说”。
