建站周期，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e04d7b23c6a4.html
📄
建站周期，旧系统字段无法完整迁入时怎样决定保留项
先按“业务是否仍需要、历史数据是否必须可读、迁移成本是否可控”三项给每个字段打标记，而不是先问能不能全部搬过去。只要有一个字段同时满足业务仍用、历史记录必须可查、且没有替代来源，就应进入保留清单；反之，先考虑改写或退出。决定保留项的关键不是字段数量，而是它在旧系统关闭后是否还会被真实使用。
先判断字段是“活数据”还是“历史痕迹”
旧系统里很多字段看起来重要，实际只是当年流程留下的痕迹。判断方法很直接：如果新站上线后，运营、客服、财务或仓储人员仍会按这个字段筛选、导出或对账，它就是活数据；如果只是偶尔有人翻旧记录，且不影响当前业务动作，它更接近历史痕迹。
活数据字段应优先保留，并明确迁移后的字段类型、长度和空值处理。历史痕迹字段则不必强行进入主表，可以改为归档查询、附件留存或只读备注。这里有一个假设例子：旧系统用 customer_level 记录客户等级，新站只做展示不做分群，那么把它降级为备注文本即可；但如果新站仍按等级发优惠，就必须保留为可筛选字段，并补上等级变更记录。
动作与结果：先让实际使用字段的人标出“每周至少用一次”的字段。如果某个字段没人标，下一步就不应进入开发排期，而应进入抽样核对，确认它是否只是历史痕迹。这个结果会直接影响迁移范围，避免把建站周期耗在无人使用的字段上。
保留、改写、退出分别适用什么前提
保留适用于字段语义清晰、取值稳定、后续仍参与业务判断的情况。改写适用于旧字段含义过时、但信息本身仍有价值的情况，例如把多个旧状态合并成新状态，或把自由文本拆成结构化选项。退出适用于字段已无业务用途、没有合规留存要求、且旧系统关闭后不会有人依赖它做判断的情况。
三种处理不能只按技术难度决定。一个字段迁移困难，但如果它是财务对账依据，就不能因为麻烦而退出；一个字段迁移容易，但业务已经不用，也不应为了“完整”而保留。更稳妥的做法是给每个字段写一句保留理由，写不出理由的，先进入退出候选，而不是默认保留。
- 保留：字段仍参与筛选、统计、通知、对账或权限判断。
- 改写：字段本身过时，但值可以映射到新模型，且映射规则可验证。
- 退出：字段无当前用途、无强制留存依据、旧系统关闭后无查询需求。
如果旧系统字段无法完整迁入，优先保证保留项和改写项可验证；退出项要留下字段清单和退出原因，便于以后追溯。
用抽样验证代替“全量迁完再发现例外”
个别样本成立，不代表规模化后仍成立。旧系统里常见的情况是：少量记录字段完整，大量记录字段为空、格式不一或含义漂移。此时不能拿几条干净样本证明迁移方案可行，而应按字段做分层抽样，至少覆盖正常值、空值、异常值和历史遗留值。
验证时重点看三件事：迁移后能否还原业务判断、空值是否被误当成有效值、改写后的字段是否还能对回旧记录。假设旧系统有 1000 条记录，其中 50 条字段完整、950 条为空，那么“字段可迁”这个结论只对这 50 条成立，不能直接推广到全部。下一步应决定：是只保留这 50 条对应的字段，还是把空值也作为状态保留，或者直接退出该字段。
动作与结果：对每个候选保留字段跑一次抽样对照，记录无法映射的比例和原因。如果无法映射集中在某类旧记录，就应缩小保留范围或增加改写规则；如果无法映射分散且无业务影响，就可以退出。这个结果会决定建站周期中迁移开发的工作量，而不是等到上线前才返工。
把决定写进迁移清单，避免反复推翻
字段取舍最怕口头决定。建议在迁移清单里固定四列：字段名、处理方式、保留或退出理由、验证结果。处理方式只写保留、改写、退出三种之一，不写“尽量保留”这类模糊表述。验证结果要能指向具体样本或核对记录，而不是“看起来没问题”。
对于改写项，还要写清映射规则和回退方式。例如旧字段 status 的取值 A、B、C 分别映射到新字段的启用、停用、待审核，如果出现未知值，是进入待确认队列还是直接置空。这个规则一旦确定，就会影响后续数据清洗、接口开发和验收标准。建站周期是否可控，往往取决于这些规则是在开发前定好，还是在开发中反复补。
最后，保留项不等于永久保留。上线后可以按实际查询频率复查，长期无人使用的字段再退出。但退出前要确认旧系统是否仍可查、归档是否完整、业务方是否确认不再需要。只有把保留、改写、退出的前提写清楚，旧系统字段无法完整迁入时才不会变成无限期拖延。
