拉萨网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /279ab4a82103.html
📄
拉萨网站开发：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：当旧系统字段无法完整迁入时，不要按“字段是否重要”来逐项投票，而要先判断字段缺失的原因属于哪一类。若是数据源本身已无完整记录，保留项应收缩到能支撑当前业务闭环的最小集合；若是迁移权限或导出能力不足，则应先补一次可验证的导出，再决定取舍。两者的动作方向不同，判断错了会白做一轮迁移。
矛盾现象：字段清单齐全，实际能迁的却很少
常见情形是：旧系统后台看起来有几十个字段，导出后却出现大量空值、截断或重复。此时容易得出一个错误结论——“旧数据质量差，只能全部放弃”。但空值多并不等于字段无价值，它可能只是导出环节没有覆盖到。
更稳妥的做法是先做一次小样本对照：从旧系统随机取若干条记录，逐字段与导出文件比对。如果导出文件中某些字段整列为空，而旧系统页面上能看到内容，说明问题出在导出映射或读取权限，而不是数据本身。反之，如果旧系统页面上同样为空，才更可能是历史数据从未被填写。
两种解释：数据从未存在，还是迁移通道不完整
第一种解释是字段从未被稳定使用。旧系统可能允许自由填写，导致同一含义散落在备注、标题或附件里，结构化字段长期为空。这种情况下，强行保留该字段只会把噪声带进新系统。
第二种解释是迁移通道不完整。旧系统的字段可能依赖某个关联表、插件或权限角色才能显示，单独导出主表时自然缺失。此时字段本身有内容，只是没有被正确取出。
区分这两种解释的证据不是字段名称，而是可复核的痕迹：旧系统页面上是否能看到该字段的实际值、该值是否有修改时间、导出文件是否在相同记录上出现整列空值。如果页面上有值而导出为空，优先按迁移通道问题处理；如果页面上同样为空，才按数据缺失处理。
决定保留项的最小动作：先做可回退的对照导出
在权限或数据不完整的情况下，仍然可以执行一个最小动作：选一小批记录，分别用两种方式导出——一种按主表直接导出，一种按旧系统页面逐条记录字段值。把两份结果放在一起比对，标记出“页面有、导出无”的字段。
这个动作的结果会直接影响下一步：
- 如果“页面有、导出无”的字段集中在少数几个，说明迁移通道可以修补，优先补导出逻辑，而不是删字段。
- 如果这类字段数量很多且分散，说明旧系统结构本身不稳定，保留项应改为只保留能对应新系统必填项的字段。
- 如果两种导出结果一致且都为空，说明该字段没有可迁移内容，可以放弃，但要在迁移记录中写明放弃理由。
需要强调的是，这个动作只能回答“字段当前能否被取出”，不能推出“该字段对业务一定有价值”或“放弃后不会有人需要”。它只是把取舍建立在可验证的证据上，而不是凭印象决定。
保留项的判断规则：按业务闭环而不是按字段数量
确定哪些字段值得保留时，可以用一个假设例子来说明比较方法。假设旧系统有“客户来源”“首次咨询时间”“跟进备注”三个字段，新系统只要求保留能支撑后续联系和归属判断的信息。若“首次咨询时间”在旧系统中大量为空，但“跟进备注”里经常写着日期，那么直接迁移“首次咨询时间”会得到大量空值，而迁移“跟进备注”再人工提取日期，成本更高但覆盖更广。
这时保留项不应简单选“字段名更规范”的那个，而应比较两个条件：该字段在新系统中是否参与必填校验或列表筛选；该字段的空值是否会导致后续流程无法继续。两个条件都满足的字段优先保留，只满足一个的放入待定，都不满足的可以放弃或转为附件说明。
另一个实际动作是给每个保留项标注来源类型：直接迁移、从其他字段提取、或标记为历史缺失。这个标注会影响后续开发排期——直接迁移的字段可以进入自动脚本，需要提取的字段要安排人工或规则处理，标记缺失的字段则要在新系统里允许留空，避免导入时报错。
不能从迁移结果推出的结论
迁移完成后，某些字段为空或请求量下降，并不能单独证明保留项决策正确。空值可能来自导入规则过滤、权限未开放或页面未展示。要区分这些原因，需要检查导入日志中该字段的写入条数，而不是只看最终页面。
同样，字段被保留也不等于它会被使用。保留只解决了“数据在不在”的问题，是否参与后续流程，还要看新系统的表单、筛选和通知是否真正引用它。如果保留后没有任何入口引用，它只是占位，不会自动产生价值。
因此，决定保留项的收尾动作不是宣布迁移完成，而是列出每个保留字段在新系统中的引用位置。没有引用位置的字段，要么补上入口，要么在下一轮清理中重新评估。这一步做完，迁移才算对后续开发有实际约束。
