荆门网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1bc3ddf92fa8.html
📄
荆门网站制作：旧系统字段无法完整迁入时怎样决定保留项
先别把“旧字段全保留”当成迁移目标。更稳的做法是：把字段分成“业务继续要用”和“历史留痕”两类，前者必须在新站找到承接位置，后者优先导出归档而不是硬塞进新结构。判断依据不是字段数量，而是它是否参与当前下单、咨询、排期或对账。只要一个字段在近期的实际流程里没人读取、没人填写、也不进入任何通知或统计，它就不该占用新站的表单和数据库位置。
先确认字段的“活口”在哪里
旧系统字段多，往往是因为历史上换过业务口径。决定保留项之前，先做一次来源盘点：每个字段从哪来、谁填、谁看、多久看一次。可以按下面三类标记：
- 流程字段：客户提交时必须填，后台要据此安排服务或发货，缺了业务会卡住。
- 记录字段：只在历史订单、旧会员资料里出现，用于查证和追溯，不参与新提交流程。
- 废弃字段：当年为某个活动或旧版页面加的，现在无人维护，也没有下游读取。
实际动作是：拉一份字段清单，让前台接待、后台执行、财务各标一次“不用会怎样”。如果三方都答不出具体后果，这个字段大概率属于记录或废弃。这个动作的结果会直接影响下一步——流程字段进入新表单设计，记录字段进入导出归档，废弃字段不再迁移。
两种做法成立的条件不同
面对无法完整迁入的字段，常见取舍是“全部保留”与“只留流程必需”。两者都不是绝对正确，关键看条件。
选择全部保留的条件与代价
当旧字段涉及合同、对账、售后追溯，且行业或内部制度要求可查证时，保留更稳。比如客户历史欠款备注、旧订单修改记录，这些字段一旦丢失，后续对账只能靠人工翻旧系统。代价是新站表单变长、后台字段冗余、录入人员容易跳过非必填项，反而让数据质量下降。此时的动作是把保留字段设为“只读展示”或“后台可见”，不放进前台必填区。
选择只留流程必需的条件与代价
当旧字段只服务于已经停止的旧业务，或新站已有替代字段能覆盖同一信息时，精简更合适。比如旧系统把“联系电话”拆成区号、座机、分机三个字段，新站只保留一个手机号字段即可。代价是历史数据查询需要回到归档文件，不能在新后台一键搜索。动作是先导出旧表为可读格式，再在新站上线前做一次抽样核对，确认归档能打开、能对应到客户。
用假设例子走一遍判断
假设旧系统里有“客户来源渠道”字段，取值包括“电话咨询”“老客户介绍”“路过进店”。新站表单只想留一个下拉框。此时不要直接删，先问：这个字段现在还有人统计吗？如果每月复盘要看各渠道转化，它属于流程字段，应保留并统一取值；如果只是当年记录，现在没人看，就导出归档。再假设旧系统有“备注”字段，内容混着送货要求和内部提醒。保留整个备注会污染新站，合理动作是拆成“客户可见备注”和“内部备注”两个字段，只把前者放进新表单。这个拆分结果会影响下一步的权限设置：内部备注只对后台角色可见，客户可见备注进入通知内容。
例外：字段本身没变，但承接方式要变
有些字段必须保留，却不适合继续用旧格式。比如旧系统用自由文本记录地址，新站如果要做区域统计或配送范围判断，自由文本无法直接聚合。这时保留项不是原字段，而是它的结构化版本：省、市、区、详细地址拆开，旧文本作为“历史地址”另存。判断标准是下游用途——只要需要筛选、统计或自动通知，就应结构化；只用于人工阅读，可以保留文本。动作是先定新字段结构，再写一条旧数据映射规则，上线后抽样比对，确认拆分没有把“荆门”误写成“荆门市”之外的形式。
最后要接受一个现实：迁移不可能让所有旧字段都获得同等地位。把流程字段迁准、记录字段归档、废弃字段停用，比强行全量搬入更能让新站可用。决定保留项时，先问“不保留会卡住哪一步”，答案清楚的留下，答案模糊的导出，这样后续开发和验收才有明确边界。
