齐齐哈尔网站建设：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e343bb920645.html
📄
齐齐哈尔网站建设：旧系统字段无法完整迁入时怎样决定保留项
结论先给：当旧系统的字段无法完整迁入新站时，保留项不应按“字段数量”或“数据库里有没有值”来决定，而应按“这个字段是否还支撑一个当前必须完成的用户任务或业务动作”来决定。凡是只服务已停用流程、只被历史报表引用、或只是当年录入习惯留下的字段，可以归档而不迁入；凡是仍被前台展示、表单提交、订单流转或对外承诺引用的字段，即使数据很脏也要先迁入再清洗。下面给出可核对的判断依据、一个会让结论失效的反例，以及决定后的下一步动作。
先区分三类字段，而不是先看数据量
面对旧库字段，常见的直觉是“有数据的就留，空的就删”。这个判断在多数情况下会出错，因为空字段可能是新站必须保留但旧系统从未强制填写的项，而有大量数据的字段可能只是历史日志。更稳的做法是把字段分成三类，再分别处理。
- 任务字段：直接参与用户当前要完成的事，例如联系表单里的需求描述、产品页的参数、报名信息中的证件类型。这类字段无论旧数据多乱，都应先迁入。
- 引用字段：不直接展示，但被其他流程、编号规则或对外文件引用，例如客户编号、合同关联号。迁入时要保留原值，不能重新生成。
- 历史字段：只服务已下线流程或旧统计口径，例如某次活动专用标记、已停用渠道来源。可以导出归档，不进入新站主表。
判断一个字段属于哪类，可以问一句：如果新站没有这个字段，哪个具体动作会做不下去？答不出具体动作的，基本可以归入历史字段。
用可核对的证据区分“必须保留”和“可以放弃”
分类之后，还需要证据支撑，否则容易变成个人偏好。以下证据比“字段看起来重要”更可靠：
- 在新站原型或需求清单里，能否指出该字段出现在哪个页面、哪个表单或哪个导出文件中；
- 旧系统中该字段最近一次被实际使用的时间，注意这里要看使用记录而不是存在记录；
- 是否有外部文件、对账单或线下流程依赖该字段的原始值；
- 去掉该字段后，是否需要人工补录或跨系统查找才能完成同一件事。
如果第 1 条和第 4 条同时成立，说明它是任务字段或引用字段，应优先迁入。如果只有第 2 条显示“很久没用”，但第 1 条也找不到落点，可以放入归档表。需要提醒的是，“很久没用”不能单独作为删除依据，因为有些字段只在年度结算、资质年检等低频场景才被调用，平时没有记录并不等于不需要。
一个会让“按任务保留”结论失效的反例
假设某旧系统的“客户来源”字段被判定为历史字段，因为新站不再按来源做分流。但如果该字段同时被财务用于区分对账口径，或者被线下合同引用为附件编号的一部分，那么按任务保留的结论就失效了——它已经变成引用字段。此时正确做法不是删除，而是迁入后标记为“只读引用”，不在前台展示，也不参与新流程，但保留原值和可检索能力。
这个反例说明：判断保留项时，不能只看新站前台，还要看旧字段是否被新站之外的系统或文件引用。只要存在一个外部引用，就不能按“前台不用”来放弃。
决定保留项后的实际动作与结果
假设经过上面的判断，确定保留“需求描述”和“客户编号”，放弃“活动标记”。下一步不是直接写迁移脚本，而是先做一次字段映射表，至少包含：旧字段名、新字段名、是否必填、清洗规则、负责人。这个动作的结果会直接影响迁移能否回滚：映射表清楚，迁移出错时可以按字段回退；映射表缺失，就只能整表重来。
映射完成后，先用一小批真实旧数据试迁，检查三件事：原值是否被截断、编码是否乱码、空值是否被错误转成默认值。试迁结果如果发现某字段大面积异常，应暂停该字段的迁入，回到分类步骤重新确认它是否真的属于任务字段。这个暂停动作看似拖慢进度，但能避免把脏数据带进新站后再花更大力气清理。
最后，把放弃的字段导出为独立归档文件，记录导出日期和字段说明，交给业务方保存。归档不是删除，而是把决定权留在可查的地方。这样即使日后发现某个字段仍被需要，也能从归档中找回，而不是从已清空的旧库里束手无策。
