资阳企业建站，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1b21516ae61c.html
📄
资阳企业建站，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“能不能迁”决定保留项，而要先按字段是否仍在参与业务闭环来分组。只有仍被前台展示、后台审批或对外接口依赖的字段才进入保留清单；仅用于历史存档、已经无人维护的字段应转入离线归档，而不是硬塞进新站。这样做的直接结果是迁移范围收窄，后续字段映射和验收才有明确边界。
两种条件，对应两种保留策略
第一种条件：旧系统仍在运行，且新站需要与它并存一段时间。此时保留项应以“跨系统一致性”为准，凡是两边都要读写的字段必须保留并统一命名，只在新站使用的扩展字段可以后置。第二种条件：旧系统即将下线，只做一次性迁移。此时保留项应以“业务是否还会用到”为准，凡是无人查询、无人导出的字段即使数据量很大，也可以不进入新站主表。
判断依据不是字段数量，而是依赖关系。可以逐个字段问三个问题：前台页面是否直接输出它；后台是否有角色在流程中修改它；外部系统或报表是否按它取数。三个问题只要有一个为“是”，就进入保留清单；全部为“否”，转入归档。
先做字段依赖盘点，再谈映射
实际动作是导出旧系统的字段清单，并给每个字段标注来源表、使用页面、使用角色和最近一次被修改的时间。这个动作的结果会直接决定下一步：如果某字段被多个页面引用，就不能简单改名，需要先确认新站的信息架构是否还保留对应位置；如果某字段只在一张废弃报表里出现，就可以直接标记为归档。
盘点时容易出现的例外是“字段名相同但含义不同”。例如旧系统里的“状态”可能同时表示审核状态和发布状态，迁入新站前必须拆成两个字段，否则后续流程会互相覆盖。遇到这种情况，保留项不是原字段，而是拆分后的语义字段。
可区分原因的证据，比字段总数更有用
- 有页面模板直接引用该字段：说明它参与展示，保留优先级高。
- 有后台角色在流程中编辑该字段：说明它参与业务流转，保留优先级高。
- 只有历史数据导出脚本引用：说明它偏存档，可放入归档库。
- 字段值为空或长期未更新：不能单独作为删除证据，还要确认是否有默认值逻辑。
需要说明的是，导出脚本报错、接口返回为空或某张表记录数归零，都不能单独证明该字段可以删除。合理解释还包括权限变更、定时任务暂停或数据源切换。要排除这些解释，至少核对一次业务方的实际使用记录。
一个带假设的短例子
假设某资阳企业的旧站有“客户行业”“客户规模”“跟进记录”三个字段。新站只保留表单和咨询入口，不再做客户管理。此时“客户行业”和“客户规模”如果仍用于前台表单筛选，就保留；“跟进记录”只存在于旧后台，且无人导出，就归档。迁移后如果发现销售仍需要按行业筛选咨询，再把该字段加回主表，而不是一开始就全量迁入。这个顺序的好处是：先保证前台可用，再按真实需求补后台字段。
保留项确定后的实施动作
确定保留清单后，下一步是建立字段映射表，写明旧字段名、新字段名、类型、是否必填、默认值和负责角色。映射表完成后先做一次小样本导入，只取几十条记录，检查页面输出和后台编辑是否正常。如果小样本通过，再扩大导入范围；如果小样本出现字段错位，应先修正映射规则，而不是继续导入全部数据。
最后要留出例外处理：旧系统中存在但新站不需要的字段，不要直接删除原始数据，应保留只读归档，并记录归档位置和访问方式。这样既缩小了新站维护面，也避免以后需要追溯时找不到依据。
