昭通网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d83afd1347ac.html
📄
昭通网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给判断：字段能不能保留，不取决于旧系统里有没有这个字段，而取决于新站上线后有没有人必须用它完成一件具体的事。没有人用、没有页面承载、没有后续流程接得住的字段，即使数据再完整，也应该在新站结构里删掉，只把原始数据留档。下面用一个假设情境把决策过程走一遍。
先设定一个假设情境
假设昭通一家做本地建材批发的企业要重做网站。旧系统里客户询价表单有二十多个字段，包括称呼、电话、公司名、工程地址、材料品类、预计用量、交货时间、开票要求、旧系统内部编号、来源渠道、备注等。新站准备把询价流程简化成三步，新表单只打算保留八个字段。剩下的十几个字段里，有一部分在旧库里长期为空，有一部分只有销售在内部看，还有一部分是当年为了配合旧系统某个统计报表才加的。
这时真正的问题不是“怎么把二十个字段都搬过去”，而是“哪几个字段值得在新结构里占一个位置”。
用三个问题筛掉大部分字段
对每个待定字段依次问三个问题，只要有一个答案是否定的，就进入删除候选，而不是硬塞进新表单。
- 有没有人必须用它做决定？比如“预计用量”决定销售要不要当天回电，“开票要求”决定报价单怎么出。如果只是“留着以后可能有用”，不算。
- 新站有没有页面或流程承载它？字段要落在某个表单、某段展示内容或某条内部通知里。没有落点，数据迁进来也是死数据。
- 缺了它会不会导致返工？如果客户提交后销售必须再打一次电话才能补齐关键信息，那这个字段就该保留；如果补不补都不影响下一步动作，就可以删。
按这三个问题过一遍，上面假设情境里的“旧系统内部编号”“来源渠道”通常最先出局，因为它们服务于旧系统的内部统计，新站前台没有人会填，后台也没有对应流程去消费。而“材料品类”“预计用量”“交货时间”往往能留下，因为它们直接决定销售怎么跟进。
保留项要分清“前台必填”和“后台留档”
筛完之后，剩下的字段不要一律做成表单必填项，而要分成两类处理。
- 前台必填：客户自己知道、也愿意填、且直接影响响应动作的字段。这类字段少而精，通常控制在能一屏填完的范围。
- 后台留档：销售或客服在沟通中补充、用于内部跟进的字段。它们不必出现在公开表单里，可以在新站后台单独建一个记录区，或者继续留在原来的业务系统里，新站只做跳转或同步。
这个区分很关键。很多迁移失败不是因为字段丢了，而是把内部字段硬塞进前台表单，导致客户填写意愿下降，最终有效询价反而变少。把“开票要求”这类字段挪到销售后续沟通环节，前台只留“称呼、电话、品类、用量”，提交率通常更稳。
一个动作：先做字段去向表，再决定迁移范围
具体动作是：在动手迁移之前，先拉一张字段去向表，每个旧字段占一行，标注四列——字段名、是否有人用、新站落点、处理方式（保留前台／保留后台／只留档／删除）。这张表不需要复杂工具，普通表格即可。
做完这张表，下一步会变得清晰：去向表里“新站落点”为空的行，就是必须先决策的行。如果某行反复填不出落点，说明这个字段的保留理由不成立，直接归入只留档或删除。反过来，如果某行落点明确、且缺了会导致销售返工，就优先保证它在迁移中不丢失。
假设情境里，做完这张表后通常会发现：真正需要迁进新结构的字段只有六到十个，其余十几个只需把旧库原始数据导出留档即可。迁移工作量因此大幅下降，测试范围也更可控。
什么条件下应该改变这个决策
上面这套判断成立的前提是：新站的询价流程确实被简化了，且旧字段没有外部合规或对账要求。如果前提变化，决策也要跟着变。
- 如果企业有开票、合同或对账要求，涉及金额、税号、开票信息的字段就不能只留档，必须保证可查、可导出，即使不出现在前台表单。
- 如果旧系统的某些字段是行业监管或平台对接必须保留的，比如特定资质编号，那就不能按“有没有人用”来删，而要按“是否必须可追溯”来保留。
- 如果新站上线后业务模式没有变、销售流程也没变，那保留项可以放宽，优先保证迁移完整性，而不是急着做减法。
换句话说，删字段是为了让新流程跑得动，不是为了删而删。判断标准始终是：这个字段在新站上线后，有没有一个明确的动作依赖它。有，就留；没有，就留档。把这张去向表做完，迁移范围自然就定了，后续开发和测试也才有明确的验收对象。
