牡丹江建站，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fdc534e21d4c.html
📄
牡丹江建站，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段数量”决定保留项，而要先按字段在新站是否承担可验证的业务动作来分组。凡是影响下单、咨询、会员识别、售后追溯的字段，优先保留并接受人工补录成本；只用于旧后台统计、内部备注、历史分类的字段，可以归档到离线文件而不进新库。判断依据不是字段看起来重不重要，而是它缺失后会不会让某个页面流程断掉。
矛盾现象：字段越多越像“完整迁移”，但新站往往因此更难维护
旧系统运行多年后，字段通常分两类来源：一类是当年业务真实需要的，比如客户等级、安装地址、设备编号；另一类是临时加上的，比如某次活动标记、某位同事的内部备注、已经废弃的分类。迁移时如果全部保留，新站表单会变长，后台列表会变复杂，编辑录入时更容易选错。如果全部不保留，售后查历史记录、老客户识别、订单对账又可能失去线索。
所以真正的问题不是“能不能迁”，而是“哪些字段值得让新站长期背负”。一个字段进入新库后，通常意味着它要出现在录入界面、列表筛选、导出文件或接口返回中，维护成本会持续存在。迁移决策要按这个持续成本来算，而不是按旧库里的字段总数来算。
两种做法都成立，但适用条件不同
做法一：保留字段并做映射，适合字段参与新站流程
如果某个字段在新站仍然会被查询、筛选、触发通知或打印到单据上，就应保留。具体动作是：先列出该字段在新站出现的页面和动作，再决定它进入主表还是扩展表。假设一个牡丹江本地服务类网站，旧库里有“设备安装日期”和“上次回访时间”，新站仍要做回访提醒，那么这两个字段应保留，并明确由谁在什么节点更新。结果是后续回访列表可以直接筛选，不必再翻旧系统。
做法二：不迁入主库，改为归档，适合字段只用于追溯
如果字段只在出现纠纷或审计时才需要查，平时不参与页面展示和业务流程，就不必进入新站主库。可以导出为带主键的离线文件，在新站订单详情里保留一个“查看历史归档”的说明位置，或由人工按编号查询。这样做的代价是查询多一步，收益是新站表单和后台更干净。适用条件是：该字段缺失不会阻断当前流程，且旧数据有稳定主键可以关联。
能区分两种解释的证据：看字段缺失后哪一步会停
判断一个字段该不该保留，可以做一个短推演，而不是凭感觉投票。取三个字段分别问：如果新站没有它，哪个角色会在哪一步停下来？
- 客服无法确认老客户身份，导致重复询问或报错价格——保留，并设为必填或自动带出。
- 编辑无法判断内容该归入哪个旧栏目，但新站已改用新分类——不保留旧分类字段，改为一次性对照表。
- 财务无法核对某笔历史收款对应哪个合同——保留合同编号，但可以只读展示，不进入新建表单。
这个推演的关键是“停下来的角色和动作”。如果没有任何角色会停，只是“以后可能有用”，通常归入归档而不是主库。反过来，只要有一个高频动作会停，就应保留，并接受它带来的表单长度和校验规则。
一个注明假设的短例子：字段保留项如何影响下一步
假设某牡丹江建站项目旧库有 40 个客户字段，新站只规划了 12 个。团队先按“是否出现在新站页面或导出”筛选，剩下 9 个必留、3 个可选、28 个归档。动作是：把 9 个必留字段写成映射表，标注旧字段名、新字段名、是否必填、由谁维护；把 28 个归档字段导出为 CSV，并用旧客户编号作为关联键。结果是新站后台列表只显示 9 个字段，编辑录入时间缩短；当需要查旧备注时，按客户编号在归档文件中检索。下一步不是继续加字段，而是观察一个月内是否出现“必须回查归档”的高频场景，如果有，再把对应字段提升为主库字段。
这个例子里的数字只用于说明比较方法，不代表任何真实项目规模。关键动作是映射表和归档键，它们让保留项的决定可回溯，而不是迁完就说不清。
决定保留项时，先写下不保留的代价
很多迁移争议来自只讨论保留的好处，不讨论保留的代价。更稳妥的做法是给每个候选字段写两行：保留后谁会维护、不保留后谁会受影响。若保留后无人维护，字段很快会变成脏数据；若不保留后只有极低频的查询需求，归档通常足够。对于涉及会员识别、订单状态、售后凭证的字段，宁可保留并设为只读，也不要为了表单简洁而删除。最终原则是：让新站承担当前流程必需的字段，让旧系统承担历史追溯的字段，两者用稳定编号关联，而不是把旧库原样搬进新库。
