张家界网站建设，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0b3ee8fc2633.html
📄
张家界网站建设，旧系统字段无法完整迁入时怎样决定保留项
先把“迁不动”拆成两类：字段值本身缺失，和字段值存在但目标结构放不下。前者通常只能放弃或人工补录；后者往往可以通过合并、降级或延后迁移保留。决定保留项的核心不是字段重不重要，而是它是否仍被当前业务流程读取、是否有可核对的来源、以及迁移后谁负责维护。
先分清是数据缺失还是结构不兼容
旧系统里一个字段为空，可能因为从未录入，也可能因为录入入口早已关闭。这两种情况处理方式不同：从未录入的字段，迁过去也是空值，保留意义有限；曾经录入但入口关闭的字段，值得先导出样本，确认历史数据是否完整。
结构不兼容则更常见。例如旧系统把“联系人”存成一个长文本，新结构要求拆成姓名、职务、联系方式三个字段。这时不是删掉，而是判断能否用规则拆分。可以先用一批样本试拆，统计能自动拆分的比例。假设一百条记录里七十条能按固定分隔符拆开，剩下三十条需要人工判断，那么保留这个字段的成本就是可估算的，而不是凭感觉争论。
实际操作上，先做一份字段清单，逐项标注：来源表、样本量、空值比例、是否被当前页面或流程读取。这份清单是后续讨论的共同依据，能避免不同角色各说各话。
两种条件下保留项的判断标准不同
条件一：字段仍被当前业务读取。如果某个字段仍出现在询价表单、订单备注或客服查询里，它就不只是历史数据，而是活数据。这类字段优先保留，哪怕需要临时用附加表存放。判断依据是：近期的业务流程是否真的在用它，而不是“以后可能有用”。
条件二：字段只服务历史查询。如果字段只用于回看旧记录，且没有页面或流程读取，可以降级为归档字段：迁移时保留原始值，但不进入主表结构，不参与新录入。这样既保住了可追溯性，也不拖慢新系统。
两种条件的分界点在于“谁在读”。让负责日常运营的角色指出哪些字段每天会被打开，让负责历史追溯的角色指出哪些字段只在纠纷或审计时才会查。把这两组名单对齐，保留项自然收敛。
把分歧转成可核对的项目
多个角色对同一字段的理解经常不一致：技术方看到的是类型和长度，业务方看到的是“这个字段很重要”，管理方看到的是迁移工期。要把分歧变成可核对的项目，可以做三件事。
- 给每个争议字段写一句“它回答什么问题”。写不出来的字段，通常可以放弃。
- 标注该字段的来源和更新方式：是人工录入、系统生成，还是从其他表计算得出。
- 指定迁移后的维护责任人。没有人维护的字段，保留下来也会逐渐失真。
完成这三步后，再开一次短会逐项确认。结果是：能回答问题的字段进入保留清单，回答不了但涉及历史凭证的进入归档清单，其余进入放弃清单。这个动作本身不产生代码，但它决定了后面迁移脚本要写多少分支。
实施动作与例外
确定保留项后，先做一次小批量试迁，而不是全量执行。试迁时记录三类结果：成功迁入、需要人工补录、迁移后无法在新界面显示。第三类最容易被忽略——字段进了数据库，但没有任何页面能读到它，等于白迁。
试迁结果会直接影响下一步：如果人工补录比例过高，就要回头重新评估该字段是否值得保留，或者调整拆分规则；如果字段迁入后无处显示，就要先确认新系统是否需要增加展示位置，再决定是否继续迁。
例外情况也要提前写明。涉及合同、金额、身份信息的字段，即使当前无人读取，也应按归档处理，保留原始值并限制访问，而不是直接删除。反之，临时备注、测试数据、重复的中间字段，可以在确认无引用后放弃。
最后，把保留、归档、放弃三份清单和试迁记录一起存档。下次再遇到字段迁不动的情况，可以直接对照这份记录判断，而不必从头争论一遍。
