商洛建站，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /caba73993093.html
📄
商洛建站，旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段能不能保留，不取决于它在旧系统里用了多久，而取决于它在新站上是否有明确的展示位置、录入责任人和后续使用场景。三者缺一，即使数据迁得过去，也会变成没人维护的垃圾字段。因此决定保留项的正确顺序是：先按“有展示位、有人填、有人用”筛一遍，把字段分成保留、改写、退出三类，再处理迁入方式。
先分清三种字段，而不是先问能不能迁
旧系统字段无法完整迁入，通常不是技术限制，而是新旧两套内容模型的粒度不同。旧系统可能把所有信息塞进一张扩展表，新站则要求结构化字段。此时按下面的标准分类，比逐字段讨论迁移脚本更有效：
- 保留：新站有对应展示位，且有明确的录入人。例如产品规格中的材质、尺寸，前台要展示，后台由运营填写。
- 改写：旧字段承载的信息仍然有用，但形态要变。例如旧系统一个“备注”字段里混着发货说明和售后条款，新站应拆成两个独立字段，或并入正文。
- 退出：旧字段是历史遗留，前台不展示，后台也没人再填。例如早期为某个已下线活动加的标记位。
判断“有人用”时，不要问开发，要问实际录入和审核的人。开发往往只知道字段存在，不知道它是否还被业务依赖。
保留项的硬条件：展示位、录入人、使用场景同时成立
一个字段值得保留，需要同时满足三个条件。只满足其中一两个，通常会演变成下面这些情况：
- 有展示位但没人填：前台出现大片空白，或长期显示默认值。
- 有人填但没展示位：录入者做了无用功，时间一长就停止维护。
- 有展示位也有人填，但没人用：这个字段不影响任何决策，属于可退出项。
假设一个商洛本地的建材类站点，旧系统里有一个“库存位置”字段，记录货物在仓库的哪个区域。如果新站只面向客户展示产品，这个字段既没有前台展示位，也不影响客户决策，就应归入退出项，而不是因为“数据迁过来也不难”就保留。反过来，如果新站要给经销商提供查询入口，这个字段就有明确使用场景，应保留并指定仓库人员为录入人。
改写项的处理：先确定新结构，再决定数据怎么落
改写是最容易被低估的一类。旧字段往往是非结构化的长文本，新站需要拆成多个短字段。处理改写项时，先做两件事：
- 列出旧字段里实际出现的内容类型，而不是看字段名。字段名常与实际内容不符。
- 为新站定义目标字段，并明确每个目标字段是否必填。
如果旧数据无法自动拆分，可以保留一个“原始说明”字段作为过渡，同时在新字段中只填能确定的部分。过渡字段应设定退出时间，例如新站上线后由录入人员在日常维护中逐步补齐，而不是长期保留两套并行结构。否则新旧字段会同时存在，录入者不知道该填哪个，最终两边都不准。
退出项的判断：不要用“以后可能有用”当保留理由
“以后可能有用”是保留决策中最常见的模糊理由。它无法验证，也无法指定责任人。更可操作的做法是给退出项设一个观察条件：如果某个字段在旧系统最近一段时间的实际使用中已经不再产生新内容，且没有前台展示需求，就可以退出。这里要注意，请求量或抓取量归零不能单独证明字段该退出，因为那可能只是页面入口被调整、爬虫策略变化或统计口径改变造成的，与字段本身的价值无关。
退出不等于删除数据。可以把旧字段整体归档到只读的备份表或导出文件中，新站不再建模。这样既减少了新系统的维护面，也保留了回溯可能。需要明确的是，归档数据不应参与新站的前台渲染和后台编辑流程，否则退出就没有实际意义。
一个可执行的决策顺序
把上面的判断落成动作，可以按这个顺序走：
- 导出旧系统字段清单，标注每个字段在旧站前台是否可见。
- 找实际录入人员确认：这个字段现在还有人填吗？填的时候依据什么？
- 对新站每个字段问一句：它出现在哪个页面的哪个位置，由谁维护。
- 把字段归入保留、改写、退出三类，改写项写出目标结构。
- 对退出项做归档，对保留项指定录入人，对改写项设定过渡字段的退出时间。
这个顺序的价值在于：它把“能不能迁”的技术问题，转换成“迁过来之后谁负责、用在哪”的业务问题。技术迁移方案可以后置，因为一旦保留项确定，迁移脚本的目标结构也就确定了。反过来，先写迁移脚本再讨论字段去留，返工几乎不可避免。
最后需要提醒的是，这套判断只在字段数量有限、业务方能够参与确认时成立。如果旧系统字段成百上千，且没有稳定的业务对接人，就不能逐个字段讨论，而应先按内容类型分组，用抽样确认代替全量确认，否则决策成本会超过迁移本身。
