青海网站开发，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f72609aa2b19.html
📄
青海网站开发，旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧库字段迁不完整时，保留项不应按“字段是否重要”来投票，而应按“该字段是否仍影响当前业务动作”来分级。具体做法是先把字段分成阻断型、解释型、存档型三类，再决定是迁入新系统、留在只读旧库，还是彻底放弃。假设你正在做一次青海网站开发的数据迁移：旧系统里有 60 多个字段，新系统只建了 30 个，剩下 30 个字段无法一一对应。此时真正要回答的不是“怎么全搬过去”，而是“哪些字段不搬也不会让业务断掉”。
先判断字段属于阻断型、解释型还是存档型
阻断型字段一旦缺失，当前流程就走不下去。例如订单状态、客户联系方式、产品编号、合同有效期。这类字段必须在新系统里有落点，哪怕临时用备注字段承接，也要先保证能读能写。解释型字段不影响流程启动，但影响判断质量，例如旧系统里的“客户来源备注”“历史沟通摘要”“特殊折扣原因”。它们可以晚一步迁，但不能直接丢。存档型字段只在追溯、审计或纠纷时才会被翻出来，例如多年前的操作日志、已失效的旧分类编号、不再使用的渠道代码。
区分方法很直接：拿一个当前正在发生的业务动作去测。如果缺少这个字段，客服无法确认身份、运营无法发货、财务无法对账，它就是阻断型。如果缺少后仍能完成动作，只是需要额外问一句或查一次旧系统，它就是解释型。如果缺少后一个月内没有任何人主动去找，它就是存档型。
用“动作测试”替代“字段重要性”讨论
很多迁移卡住，是因为团队在争论“这个字段重不重要”。重要性没有统一尺度，但动作可以观察。建议做一张短表，只记三列：字段名、依赖它的当前动作、缺少后的替代路径。替代路径为空，说明它是阻断型；替代路径是“查旧库”或“问同事”，说明它是解释型；替代路径是“基本不用”，说明它是存档型。
假设旧系统里有一个“客户等级”字段，新系统没有对应项。如果当前动作是“按等级决定是否人工审核”，那它属于阻断型，必须迁。如果当前动作只是“销售自己参考”，那它属于解释型，可以放进客户备注。如果这个等级已经两年没有参与任何规则，只在导出报表时出现，那它属于存档型，留在旧库只读即可。这个判断不依赖字段本身多复杂，而依赖它是否还挂在某个动作上。
决定保留项时，先处理“一对多”和“多对一”
字段无法完整迁入，常见原因不是数量多，而是对应关系变了。旧系统一个字段在新系统里可能拆成两个，例如“地址”拆成“省市区”和“详细地址”；也可能多个旧字段合并成一个，例如“固定电话”“手机”“邮箱”合并为“联系方式”。这时保留项的决定顺序应该是：先保证新系统的主字段有值，再决定旧字段是拼合、截取还是另存。
如果旧字段和新字段是一对多，优先迁入新系统必填的那一个，其余作为补充信息放入备注或扩展表。如果旧字段和新字段是多对一，先确认合并后是否会丢失区分度。例如旧系统把“咨询来源”和“下单来源”分开记录，新系统只有一个“来源”，合并后可能无法判断是哪个环节带来的客户。这种情况下，保留项应选择保留两个旧字段，而不是强行合并成一个。动作上，可以先在新系统加一个“来源环节”标记，再决定是否回填历史数据。
假设情境：一次迁移评审会上的取舍
假设某青海本地企业要把旧客户管理系统迁入新网站后台，旧库有 48 个字段，新后台只有 22 个。团队最初想全部保留，做法是把剩余 26 个字段塞进一个“其他信息”长文本。评审时发现三个问题：第一，长文本里的字段无法被检索；第二，新后台的筛选和提醒功能读不到这些值；第三，客服在页面上要手动翻找，反而比查旧系统更慢。
调整后的做法是：先列出当前每天发生的 5 个动作，分别是新客登记、报价、合同到期提醒、售后回访、月度对账。然后逐个字段问“哪个动作会用到它”。结果只有 9 个字段被判定为阻断型，必须在新后台建独立字段；11 个字段属于解释型，保留在“客户备注”和“沟通记录”中，允许搜索但不必结构化；剩下 6 个字段被标记为存档型，旧库转为只读，不再迁入。这个结果不是按字段新旧决定的，而是按动作依赖决定的。
接下来做一个实际动作：把这份分级清单交给开发，只要求先实现 9 个阻断型字段的读写，并保证旧库只读查询可用。结果是新后台能先上线核心流程，解释型字段在后续迭代中补，存档型字段不阻塞上线。如果反过来先迁全部字段，开发和测试周期会被拉长，而且很多字段迁完后并没有人使用。这个假设情境说明，保留项的决定标准是“当前动作是否依赖”，而不是“历史数据是否完整”。
无法判断时，用只读旧库兜底，而不是硬塞进新系统
如果某个字段既不能确认是阻断型，又不能确认没人用，最稳妥的做法不是把它塞进新系统的主表，而是保留旧库的只读查询入口，并记录查询日志。后续观察一段时间，如果确实有人频繁查，再把它升级为解释型或阻断型；如果无人查询，再考虑归档或删除。这里要注意，查询量归零不能单独证明该字段无用，也可能是因为没人知道旧库还能查，或者查询入口太深。合理解释还包括：业务季节性、旧库权限未开放、替代信息已经出现在别处。
因此，决定保留项时，建议至少保留一个可回退的只读路径。它的作用不是长期并行两套系统，而是给判断留出证据。动作上，可以先开放旧库的只读账号给少数岗位，并约定两周后复查查询记录。复查结果只作为下一步讨论的依据，不直接等同于字段价值结论。
最后回到取舍本身：旧系统字段无法完整迁入时，先按阻断型、解释型、存档型分级，再用当前业务动作测试，最后用只读旧库兜底不确定项。这样做的结果不是把所有字段都搬过去，而是让新系统先跑通当前流程，同时不丢掉真正需要追溯的信息。
