六安做网站：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f42ca3f35790.html
📄
六安做网站：旧系统字段无法完整迁入时怎样决定保留项
结论先给：如果旧字段仍然承担业务判断、对账或售后追溯，就必须保留并补齐映射；如果它只服务于旧版展示、重复记录同一事实，或迁移后无人能解释其用途，就应放弃。判断依据不是字段数量，而是它是否影响下一步业务动作。一个反例是：某字段看似无人查询，却是财务对账的唯一凭据，这时放弃它会让后续账目无法闭合，结论随即失效。
先确认字段的“业务责任”，再谈保留
旧系统字段无法完整迁入，通常不是技术容量问题，而是新旧模型对同一业务事实的定义不同。决定保留项时，先问三个问题：这个字段由谁维护、在什么流程中被读取、缺失后哪个岗位会停下来。能回答清楚这三个问题的字段，属于责任字段，应优先保留；回答不清楚的，属于遗留字段，可以进入放弃清单。
可以按下面顺序过一遍：
- 列出旧表中所有字段，标注最近一次被业务使用的场景。
- 把字段分为“决策依据”“追溯凭据”“展示文案”“系统冗余”四类。
- 只对前两类做迁移映射，后两类先记录来源表名和字段名，再决定是否归档。
这样做的实际结果是：迁移范围会明显缩小，但每一个被保留的字段都能说清保留理由，后续验收时不会因为“以前好像有”而反复返工。
三种必须保留的条件，和一种可以放弃的条件
必须保留的条件通常有三种。第一，字段参与金额、库存、工期或权限计算，缺失会导致结果不一致。第二，字段是历史记录的唯一来源，例如旧订单的备注、变更原因、审批意见。第三，字段被外部系统或线下流程引用，例如纸质单据编号、对接方要求的编码。
可以放弃的条件只有一种：字段内容能从其他保留字段推导出来，且推导结果与旧值一致。例如旧表同时存了“单价、数量、金额”，新系统只保留单价和数量，金额由计算得出。此时放弃金额字段不会丢失信息。
需要提醒的是，字段有值不等于字段有用。旧库里大量字段都有默认值或历史脏数据，不能仅凭“非空”就判断它重要。更可靠的做法是抽样核对：随机取若干条旧记录，请实际使用该数据的同事指出哪些字段他们认识、哪些从未见过。这个动作的结果会直接决定映射表是继续扩充还是开始收缩。
一个假设例子：保留项如何影响下一步
假设某六安本地业务旧系统里有“客户来源”和“首次接触渠道”两个字段，新系统只能保留一个。核对后发现，售后回访时工作人员只看“首次接触渠道”，而“客户来源”是早期广告投放时留下的，已经无人维护。此时保留“首次接触渠道”，把“客户来源”连同旧表名写入迁移说明即可。
如果反过来保留“客户来源”，下一步做回访分组时就会缺少可用依据，只能再回头翻旧库，迁移等于没有完成。这个例子的重点不是字段名称，而是：保留项应当服务于迁移之后的下一个业务动作，而不是服务于旧界面的完整复刻。
迁移说明要写清“放弃了什么”
决定保留项之后，还需要一份简短的迁移说明，至少包含：旧表名、旧字段名、处理方式（保留、合并、归档、放弃）、判断人、判断日期。这份说明的作用不是留档好看，而是当后续有人问“某个信息去哪了”时，能直接定位到结论，而不是重新发起一轮讨论。
如果某个字段暂时无法判断，建议先归入归档而不是直接删除。归档的成本通常低于事后找回，但归档也要设定期限和负责人，否则会变成新的遗留问题。
下一步动作
拿一张纸或一份表格，把旧系统字段按“决策依据、追溯凭据、展示文案、系统冗余”四类各归一次位；对进入前两类的字段补上使用人和使用场景，对后两类写明放弃或归档理由。完成这一步后再开始写迁移脚本，返工概率会明显下降。若核对过程中发现某个字段的使用人已经离职且无人能说明用途，应把它标记为待确认，而不是直接判定为无用。
