湘潭企业网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ae87f9ca0955.html
📄
湘潭企业网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入新站时，默认保留“新站前台或后台业务动作必须读取的字段”，其余字段先导出留档而不迁入。这个判断成立的前提是，新站已经确定主要用户任务和内容模型；一旦字段承担的是历史检索、审计或外部对接职责，即使前台不显示，也不能按这个默认规则删掉。
先按“是否被业务动作读取”分三层
把旧字段逐个过一遍，不要按字段名或旧栏目位置决定去留。更可操作的做法是分三层：
- 第一层，新站运行必需。例如标题、正文、发布状态、所属栏目、作者、发布时间。缺少它们，新站无法正常展示或发布，必须迁入并做映射。
- 第二层，后台管理或检索需要。例如旧系统里的内部编号、审核备注、标签、地区分类。前台可能不显示，但编辑检索、批量处理或对接时仍会用到，应评估是否保留为自定义字段。
- 第三层，只对旧站有意义。例如旧模板专用标记、已废弃的排序值、旧版页面缓存标识。这类字段迁入后无人读取，通常导出留档即可。
判断动作可以很具体：打开新站的内容模型和前台模板，逐个字段问“哪个页面、哪个后台操作、哪个接口会读它”。没有任何读取方的字段，不进入迁移清单；有读取方但读取方尚未确定的字段，先标记为待定，而不是直接删。
一个反例会让默认规则失效
假设某湘潭制造企业的旧站里有一个“产品旧编号”字段，前台早已不显示，按上面的规则应归入第三层。但如果销售部门用这个编号与ERP、报价单或经销商目录对应，它就不是展示字段，而是业务主键。迁移时若直接丢弃，后续对账和外部系统匹配都会断链。
这说明默认规则失效的条件是：字段被站外流程、历史档案或人工习惯持续引用。此时不能只看新站前台是否显示，而要先确认引用方是否还存在、是否愿意改用新编号。若引用方仍在用，保留字段并同步维护；若引用方已停用，才回到导出留档的处理。
用一组可区分原因的证据来定去留
字段无法迁入的原因不同，处理方式也不同。可以先收集这几类证据：
- 结构不兼容。旧字段是自由文本，新模型要求枚举值。此时不是删字段，而是先决定映射表，例如把常见旧值归入新选项，无法归类的进入“其他”并人工复核。
- 长度或格式超限。旧字段允许长文本，新字段长度较短。应判断该内容是否影响业务动作；影响则调整新模型，不影响则截断并保留原文导出。
- 字段语义重叠。旧系统有多个相似字段，新系统只保留一个。此时要确认哪个字段被最多流程读取，再决定合并规则，而不是按字段出现顺序保留第一个。
- 迁移工具不支持。这只是技术限制，不构成删除理由。可以先用导出文件补录，再在后台逐条核对，而不是因为工具报错就放弃字段。
这些证据的作用是区分“不能迁”和“不值得迁”。前者需要改模型或补录，后者才进入留档范围。
决定保留项之后，下一步做什么
确定保留清单后，先做一次小范围试迁：选几十条覆盖不同栏目和字段组合的记录，迁入后检查前台展示、后台检索和外部对接是否正常。若试迁发现某个字段在多个流程中被读取，就把它从待定提升为必留；若发现某字段迁入后无人使用，再降级为留档。
这个动作的结果会直接影响后续批量迁移的范围和字段映射表。试迁通过后再全量执行，比一次性迁完再回滚更容易控制字段取舍的边界。对于湘潭企业网站制作项目，如果旧系统年代较久、字段命名混乱，保留项清单应由熟悉旧后台和现行业务流程的人共同确认，而不是只由开发按数据库结构决定。
