青海网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /6528b995f9b1.html
📄
青海网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入时，不要按字段数量决定保留项，而应按“这个字段是否改变了用户下一步动作”来分层。假设一个青海本地企业的旧站要改版，旧数据库里有约四十个字段，新系统只能承接其中一部分。此时可行的做法是：把字段分成“影响业务动作”“只影响展示”“只是历史冗余”三类，再决定哪些必须迁移、哪些可以合并、哪些可以放弃。这个判断不依赖工具，而依赖对业务动作的核对。
先确认字段到底服务于哪个动作
很多迁移争论的根源，是不同角色对同一个字段的理解不同。运营认为“客户来源”必须保留，技术认为它只是旧表单的备注，市场则认为它决定后续跟进方式。要解决分歧，先把字段和动作对应起来。
可以要求每个角色只回答一个问题：如果这个字段丢失，用户或内部人员的下一步动作会不会改变？会改变，就进入保留候选；不会改变，只是少了一条显示信息，就进入可放弃候选。这个动作可以是用户提交咨询、客服回访、订单确认，也可以是内部对账。字段本身没有价值，它改变的动作才有价值。
假设情境：旧站的“客户意向等级”字段由销售手工填写，新系统没有对应位置。如果丢掉它，销售仍能通过咨询内容判断意向，那么这个字段可以放弃；如果丢掉它，销售就无法区分哪些线索需要当天回访，那么这个字段必须保留，哪怕新系统只能把它并入备注字段。
把“必须保留”压缩成最小可用集合
保留项不是越多越安全。字段越多，迁移时的映射规则越复杂，出错后越难核对。更稳妥的做法是先确定最小可用集合，再考虑扩展。
最小可用集合的判断标准可以写成三条：
- 该字段是否直接决定用户能否完成提交、查询或联系；
- 该字段是否直接决定内部人员能否完成一次回访、发货或对账；
- 该字段是否在旧系统中被高频使用，而不是只在建站初期录入过一次。
三条都满足的字段，优先保留。只满足其中一条的，进入待定。三条都不满足的，可以放弃或归档，不进入新系统的主表。
这里有一个实际动作：把待定字段单独列成一张核对表，交给每个角色分别标记“必须保留”“可以合并”“可以放弃”。如果同一个字段被两个角色标成“必须保留”，就进入最小可用集合；如果只有一个角色坚持，而其他角色认为可以合并，就先按合并处理。这个动作的结果会直接影响下一步的迁移脚本设计：最小可用集合决定新表结构，待定字段决定是否需要额外的备注字段或归档表。
合并与放弃要留下可核对的依据
决定放弃一个字段时，不能只说“没用了”。要留下可核对的依据，否则后续出现数据缺口时，没人能判断是迁移遗漏还是原本就不需要。
依据可以包括：该字段在旧系统中的最后更新时间、最近一次被使用的业务场景、以及放弃后由哪个字段或流程替代。例如“客户意向等级”如果被放弃，替代方案可能是“咨询内容关键词标记”，那么就要在核对表里写明这个替代关系。
合并字段时，同样要写明合并规则。比如旧系统的“联系电话”和“备用电话”合并成一个字段，规则是优先保留联系电话，备用电话写入备注。这个规则要能让不同角色独立核对，而不是只存在于技术人员的记忆里。
如果某个字段既不能放弃，也不能合并，但新系统确实没有对应位置，可以考虑把它放入归档表，只在新系统需要时查询。归档表不参与日常展示，但保留原始记录。这样做的代价是查询多一步，好处是不丢失历史信息。是否值得，取决于这个字段被查询的频率。
用一次小范围核对验证决定
在正式迁移前，先选一批旧记录做小范围核对。选多少条不重要，重要的是覆盖不同角色关心的字段。假设选二十条旧记录，按最小可用集合迁移，然后让运营、销售和技术分别检查：迁移后的记录是否还能支持他们各自的下一步动作。
如果运营发现某条记录缺少一个字段后无法判断是否需要回访，说明这个字段应该进入最小可用集合；如果销售发现合并后的备注字段太长、难以阅读，说明合并规则需要调整。这个核对的结果会直接改变迁移范围：要么增加保留项，要么修改合并规则，要么把某些字段转入归档表。
注意，小范围核对通过，不等于正式迁移一定没有问题。它只能说明当前的保留项和合并规则在抽样范围内成立。正式迁移后仍要保留旧系统的只读访问一段时间，以便对照。旧系统何时可以下线，取决于归档表是否完整、以及是否还有角色需要查询旧字段。
什么时候可以决定放弃
放弃一个字段的条件不是“新系统没有位置”，而是“这个字段不再改变任何人的下一步动作”。如果旧系统里某个字段只用于早期的一次性统计，之后从未被查询，也没有影响过回访或对账，那么它可以放弃。
但要注意，某个字段在旧系统里没人用，可能是因为它藏得太深，而不是因为它没有价值。所以放弃前要确认：该字段是否曾经被使用过，以及使用它的角色是否已经不再需要它。如果无法确认，宁可放入归档表，不要直接删除。
最终决定保留项的人，应该是对业务动作负责的角色，而不是单纯由技术判断字段能否迁入。技术负责说明迁移成本和映射限制，业务角色负责说明字段是否改变动作。两者核对后的结果，才是可以执行的保留项清单。
