海口网站设计旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c7b44006a2e7.html
📄
海口网站设计旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段能不能迁”决定保留项，而要按“这个字段是否仍支撑当前业务动作”决定。字段迁不进去通常有两个原因——目标结构没有对应位置，或者字段本身已经失去业务用途。两者要分开处理，否则容易把历史包袱带进新站，也容易误删仍在用的信息。
现象：能导出的字段很多，能用的却很少
旧系统往往积累了多年字段：产品参数、客户备注、内部编号、状态标记。导出时看起来完整，导入新结构时却频繁报错或落空。常见的解释有两种。
- 结构不兼容：旧字段是自由文本或一对多关系，新结构要求固定选项或单值字段，格式对不上。
- 业务已废弃：字段当年为某个流程服务，该流程早已停止，数据留着只是历史痕迹。
这两种解释的处理方式完全不同。前者需要转换或重建映射，后者应当直接放弃。判断错方向，就会在做数据清洗时浪费大量时间，或者在新站上线后才发现关键信息缺失。
区分两种解释的证据：看字段是否还触发动作
判断一个字段该不该保留，最直接的证据是：今天还有没有人因为它而做某件事。如果客服会查看某个备注字段来决定是否回访，它就仍在业务链上；如果某个内部编号只在旧报表里出现，而报表本身已停用，它就没有保留价值。
可以按下面三步收集证据：
- 列出该字段当前的所有使用场景，包括人工查看、导出报表、对接其他系统。
- 确认每个场景是否仍在运行。已经停用的流程不算使用场景。
- 对仍在运行且依赖该字段的场景，记录它需要的最小信息量。
完成这三步后，保留项自然浮现：仍触发动作的字段进入迁移清单，其余归入历史归档。归档不等于删除，可以保留在只读备份中，但不进入新站的主数据结构。
一个假设例子：产品参数字段的取舍
假设旧系统里有一个“材质说明”自由文本字段，新结构只提供固定选项。直接迁移会失败。此时先看它是否仍被使用：如果销售在报价时仍会打开这个字段确认材质，就说明它支撑当前动作，需要保留。处理方式不是原样搬入，而是把自由文本拆成“材质类别”固定选项加一个“补充说明”短文本字段，既满足新结构，又不丢信息。
反过来，如果这个字段只出现在三年前的旧报价单里，而当前报价流程已改用另一套参数表，那么它就不该占用新结构的字段位。把它留在只读备份中即可。
动作与结果：先做一次字段使用场景盘点，再决定迁移或归档。盘点结果会直接影响下一步——需要迁移的字段进入映射设计，不需要迁移的字段进入备份清单。如果跳过盘点直接迁移，后续往往要在新站里补字段、改结构，返工成本更高。
决定保留项时的两个成立条件
条件一：字段仍被当前业务流程读取。满足这个条件时，保留并设计迁移映射。映射可以简化，但不能丢失触发动作所需的最小信息。
条件二：字段只被已停用的流程或报表使用。满足这个条件时，不进入新站主结构，转为只读归档。归档位置要能让需要查历史的人找到，但不参与新站日常运行。
两个条件之间的灰色地带，比如“偶尔有人查但没人依赖它做决定”，建议按条件二处理。偶尔查看可以通过归档满足，不必为此在新站里保留一个长期不维护的字段。
迁移后仍需验证的一件事
保留项确定并完成迁移后，要抽查几个真实业务动作是否还能走通。例如客服能否按预期找到客户备注，销售能否按预期确认产品参数。抽查不通过，说明映射设计遗漏了某个使用场景，需要回到字段盘点阶段补充，而不是在新站里临时加字段补救。
字段取舍的本质是业务取舍。旧系统里字段多不代表信息全，能支撑当前动作的字段才值得进入新结构。把盘点做在迁移之前，比迁移之后再回头补要省力得多。
