河北网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6befa14a3db7.html
📄
河北网站开发：旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段无法完整迁入时，不要按“旧系统里有什么”决定保留项，而要按“新站上线后哪些字段会进入真实业务流程”决定。缺少完整数据或权限时，仍可执行的最小动作是：导出旧系统里所有字段名和示例值，逐个标注它在新站上由谁填写、在哪个页面展示、是否参与筛选或通知。标注不出来的字段先进入待定区，而不是直接删除或强行迁移。
先判断字段属于哪一类：展示型还是流程型
两类字段的处理逻辑不同，混在一起讨论就会一直争不出结果。
- 展示型字段：只用于前台呈现，例如简介、备注、补充说明。它的取舍依据是“新站是否还有对应位置”。如果新模板没有这个位置，且业务上没有人会主动填写，就可以不迁。
- 流程型字段：参与筛选、排序、通知、导出或后续对接，例如状态、归属、时间、分类。它的取舍依据是“去掉之后，哪一步操作会断”。只要有一处流程会断，就必须保留或找到替代字段。
判断流程型字段时，可以问一个具体问题：这个字段的值，会不会出现在后台列表、导出文件或通知内容里？如果会，它就不是可选项。展示型字段则可以更宽松地处理，先不迁，后续按实际需要补录。
条件一：旧系统还能导出字段结构时，先做字段映射表
只要还能拿到字段名、类型和少量示例值，就先把决策落到一张映射表上，而不是在会议上凭印象争论。映射表至少包含四列：旧字段名、字段类型、新站对应字段、状态。状态只用三种：直接映射、需要转换、暂不迁移。
“需要转换”的典型情况是格式不一致，例如旧系统把多个分类塞在一个文本字段里，新站需要拆成独立分类。这时先确认拆分规则是否唯一：如果同一个值在不同记录里写法不同，就要先定清洗规则，再决定是否迁移。
“暂不迁移”的字段不要立刻从旧系统删掉。保留旧系统的只读访问或离线导出，是后续补录的依据。动作上，先完成映射表并通过一轮抽样核对，再开始正式迁移。抽样核对的结果会直接影响下一步：如果抽样中发现大量字段无法对应，说明问题不在字段本身，而在业务规则没定清楚，此时应先定规则，而不是继续迁数据。
条件二：拿不到完整数据或权限时，先保住关键字段的可用性
缺少完整导出权限时，不必等所有数据到手才决定。可以先按“流程型优先”的原则，列出必须保留的最小字段集合，再逐个确认这些字段能否通过其他方式获得，例如后台可见的列表页、已有导出文件或人工记录。
这个阶段能执行的最小动作是：把最小字段集合写成一页清单，标注每个字段的来源和责任人。来源不明确的字段，先标记为风险项，不要假设它以后一定能补上。风险项会影响后续决策——如果某个流程型字段既拿不到历史值，也没有新的填写入口，那么新站上线后这条流程就要改成从上线日开始记录，而不是假装历史数据完整。
需要说明的是，旧系统里某些字段的值为空或缺失，不能直接说明该字段没有业务价值。更合理的解释包括：旧系统没有强制填写、填写入口太深、或者该字段只在特定角色下可见。要区分这些原因，需要看字段的填写规则和可见范围，而不是只看数据本身。
一个假设例子：分类字段的两种处理
假设旧系统有一个“所属分类”文本字段，新站需要改成可筛选的分类。如果旧值写法统一，可以按值建立对应关系后迁移；如果写法混乱，例如同一分类出现多种拼写，就不适合直接迁移。此时可选的做法是：只迁移能明确对应的记录，其余记录统一进入“待归类”，并保留旧值作为备注。这个例子只是说明比较方法，不代表任何具体项目的实际结果。
例外与收尾：什么情况下可以整体放弃迁移
如果某个字段既不属于流程型，也没有任何人在新站上会查看或维护，且旧值本身质量很低，那么整体放弃迁移是成立的。但放弃之前要确认一件事：它是否被其他系统引用。只要存在外部引用，就不能单方面决定不迁，而要先确认引用方的处理方式。
决定保留项之后，下一步不是立刻开始批量导入，而是先用少量记录跑一遍完整流程，确认字段在新站上能被正确填写、展示和筛选。这一步的结果会决定是继续迁移，还是回到映射表调整规则。字段迁移的取舍标准始终是业务流程是否完整，而不是旧数据的数量多少。
