建站流程指南：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5de84b5ed393.html
📄
建站流程指南：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段能不能迁”来定保留项，而要按“这个字段离开旧系统后，还有没有人用它做决定”来定。有人用它做决定，就保留并补上下文；只有历史留档价值，就改写为静态记录；没人用、也说不清用途，就直接退出。字段迁移失败只是触发这次清理的信号，不是判断依据。
先区分三类字段，再谈保留
旧系统里的字段通常混着三种东西：业务状态、展示文案、历史痕迹。业务状态类字段，比如订单状态、会员等级、合作到期日，一旦缺失，后续流程会断，这类必须优先保留。展示文案类字段，比如旧页面上的短描述、标签、栏目说明，缺了不影响流程，但会影响读者理解，可以改写后保留。历史痕迹类字段，比如旧编号、旧备注、旧审核人，多数只在追溯时才有意义，适合转成只读记录，而不是塞进新系统的可编辑区。
判断时问三个问题：这个字段现在还有谁在维护？它影响哪个下一步动作？如果它消失了，谁会收到投诉或返工？三个问题都答不上来，基本可以退出。
保留、改写、退出的适用前提
保留：字段仍在驱动流程
当字段参与筛选、排序、权限判断或对外承诺时，保留的前提是它能找到新的归属位置，并且有明确的维护人。例如旧系统里有一个“内容负责人”字段，新系统没有对应角色，但每次内容更新仍需要有人确认，那就不该删，而应改成“最后确认人”并限定为内部可见。保留动作的结果是：迁移清单上多一项人工核对，后续发布流程多一步确认。如果没人愿意接这个维护责任，保留就会变成死数据，不如退出。
改写：字段有阅读价值，但不再参与计算
旧页面里的“服务范围说明”“合作背景”这类长文本，往往字段结构复杂，直接迁入会带进大量格式和过期表述。适用前提是：内容仍被读者需要，但不再作为系统判断条件。动作是把它们改成静态段落或独立说明页，去掉旧系统里的状态标记。结果是读者仍能看到信息，系统不再依赖这个字段做逻辑判断。改写后要检查一次：新位置是否还能被站内搜索和栏目导航找到，找不到就等于变相退出。
退出：字段无人使用，且无法说明用途
退出的前提不是“迁移麻烦”，而是“没有实际使用场景”。假设旧系统有一个“旧渠道标记”字段，只用于当年的一次活动统计，活动结束后无人查询，新系统也没有对应报表。这种情况下继续保留，只会让编辑在发布时多填一个不知道填什么的框。退出的实际动作是：在迁移映射表里标记为“不迁”，并保留一份只读导出文件备查。结果是新系统的字段列表变短，编辑决策变快。这里要注意，导出文件是留档，不是让新系统继续读取它。
用一个假设例子走完判断
假设旧系统有四个字段：合作状态、合作备注、旧编号、展示标签。合作状态影响是否继续展示，保留；合作备注里有历史沟通记录，但不再影响当前展示，改写为只读备注，仅管理员可见；旧编号只在旧报表里用过，退出；展示标签仍影响栏目归类，保留但需要重新确认取值。这个例子的重点不是字段数量，而是每个字段都对应一个下一步动作：保留的进入核对清单，改写的进入只读区，退出的进入导出留档。数字只用于说明比较方法，不代表真实项目规模。
迁移前先做一次字段用途盘点
不要直接打开旧数据库逐列决定。先按下面顺序做一次盘点，能减少反复：
- 列出所有字段，并标注它当前是否还在被人工查看或系统读取。
- 对每个字段写出“如果缺失，下一步会怎样”，写不出来的先归入待退出区。
- 把待退出区字段做一次只读导出，确认导出文件能被打开和检索。
- 对待保留字段指定维护人和可见范围，没有维护人的降级为改写或退出。
- 迁移完成后抽查一次：保留字段是否真的出现在新流程里，改写字段是否还能被读者找到。
这个顺序的关键在于：先证明字段还有用，再决定放到哪里。反过来先迁再删，容易把有用字段和死字段一起搬过去，最后谁也说不清哪个该留。
退出旧字段时，别把退出当成删除历史
退出指的是新系统不再维护这个字段，不等于旧记录必须消失。适用条件是：旧记录可能被审计、对账或追溯，但日常运营不再依赖它。动作是保留一份可检索的只读导出，并在新系统里注明“历史数据见导出文件”。结果是日常编辑不再被旧字段干扰，需要追溯时仍有路径。若旧记录本身涉及对外承诺或合同信息，退出前应让实际使用该信息的人确认，而不是由建站执行者单方面决定。
最后检查一次：保留项是否都有维护人，改写项是否都有新位置，退出项是否都有留档。三件事都落实，字段迁移才算完成；只完成数据库搬运，不叫完成。
