牡丹江网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9108ce1a129a.html
📄
牡丹江网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段能不能迁”决定去留，而要先按“这个字段离开旧系统后还有没有业务用途”分成保留、改写、退出三堆。能迁但没人用的字段应当退出；迁不进去但影响订单、售后或对账的字段，应当改写为附件、备注或独立档案，而不是硬塞进新表单。
先判断字段是“数据”还是“流程痕迹”
旧系统里的字段常常混着两类东西。一类是业务数据，例如客户名称、联系记录、合同编号、服务项目。另一类是流程痕迹，例如旧系统内部的状态码、某位离职员工的操作标记、已经停用渠道的来源代号。前者通常值得保留，后者多数只对旧系统本身有意义。
判断方法很简单：拿这个字段去问三个问题。第一，新网站上线后，谁还会看它？第二，如果不迁，会不会导致某笔业务说不清？第三，它能不能用一句自然语言写进备注？三个问题都答不上来的字段，优先退出。
保留项的前提：新系统有承接位置且有人维护
决定保留一个字段，至少要同时满足两个条件：新系统里有明确的存放位置，并且上线后有具体角色会更新它。只满足前者，字段会变成一次性快照；只满足后者，数据没有落点。
可以按下面的顺序做一次筛选：
- 列出旧系统中所有字段，标注每个字段最近一次被使用的业务场景。
- 把字段分成“客户可见”“内部对账”“仅历史查询”三类。
- 对“客户可见”字段，检查新页面是否有对应展示位；没有展示位的，改为内部备注。
- 对“内部对账”字段，确认新系统能否用编号或附件关联；不能关联的，先保留为只读档案。
- 对“仅历史查询”字段，设定一个查询期限，到期后归档，不进入日常表单。
这样做的结果是，新网站的字段数量会明显少于旧系统，但每一列都能对应一个动作或一次查询。下一步的迁移脚本只需要处理这些有归属的字段，返工范围会缩小。
改写项：迁不进去但业务上仍要说得清
有些字段无法直接进入新结构，例如旧系统用多级下拉记录的服务分类，新网站改成了标签。这时不必强行恢复旧下拉，可以把原值转成一段可读文本，放进备注或历史记录区域。
假设一个旧字段叫“客户等级”，取值是 A、B、C，而新网站不再设等级，只记录合作状态。可以把它改写为“历史等级：A（旧系统口径）”，并注明该等级不再参与新流程。这样既保留了可追溯信息，又不会让新表单出现一个没人维护的等级字段。
改写的适用前提是：原字段的含义能用一句话解释清楚，且不会与新字段产生冲突。如果解释起来需要依赖旧系统的其他表，说明它不适合改写，应当整体归档。
退出项：先确认没有下游依赖再删除
删除字段比保留更需要谨慎。退出前要确认三件事：没有报表在引用它，没有外部对接在读取它，没有人工流程在依赖它。三者缺一，就先标记为停用，而不是直接删除。
停用和删除的区别在于可回退性。停用后字段仍在数据库中，只是不再出现在新界面；删除后如果发现还有用，只能从备份恢复。对于拿不准的字段，先停用并记录停用原因，观察一个业务周期，再决定是否彻底清理。
需要说明的是，旧系统里某个字段长期为空，不能单独证明它没有价值。空值可能来自录入习惯、权限限制或旧流程本身就不要求填写。要结合业务记录判断，而不是只看空值率。
把决定写成一张可执行的对照表
最终交付给开发或迁移执行者的，不应是一句“尽量保留”，而是一张对照表。每行包含：旧字段名、处理方式（保留/改写/退出）、新位置、负责人、判断依据。处理方式只有三种，避免出现“待定”长期挂着。
对照表完成后，先拿其中影响订单和售后的字段做一次小范围验证，确认新位置能正常读写，再批量处理其余字段。验证结果会直接影响下一步：如果关键字段读写正常，就可以按表执行；如果出现对不上，先修正映射关系，不要继续扩大迁移范围。
