乌鲁木齐网站设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c9b56ee63869.html
📄
乌鲁木齐网站设计：旧系统字段无法完整迁入时怎样决定保留项
先把“字段要不要保留”改写成“这个字段支撑哪项已确认的业务动作”。如果一项动作在新站上线后仍要发生，就保留能完成该动作的最小字段；如果动作取消、改由线下完成，或字段只服务于旧系统内部统计，就列入暂不迁入清单。假设有一家乌鲁木齐的商贸企业，旧站记录了客户“意向等级”“首次来源”“跟进人”“历史报价附件”，新站只规划了咨询表单和客户留言，那么保留项应由动作倒推，而不是由旧表字段数量决定。
先确认新站要承接哪些动作，而不是先看旧表有多少字段
旧系统字段无法完整迁入，通常不是技术容量问题，而是新旧系统对同一事实的定义不同。销售认为“意向等级”是客户当前状态，运营认为它是上一次沟通结论，技术看到的是旧表里的一个下拉值。三方说的不是同一件事，直接迁移就会把不同含义压进同一个字段。
把分歧转成可核对项目，可以先做一张动作清单：新站上线后，哪些动作必须由网站承接？例如接收咨询、记录客户留言、让客服回访、让销售查看历史沟通摘要。每个动作后面写清“缺少哪个字段就做不成”。只有写不出动作、或动作已明确取消的字段，才进入待删除讨论。
用假设情境走一遍保留项决策
假设某旧站有十二个客户字段，新站只保留一个咨询表单。团队对“首次来源”是否保留产生分歧：销售认为它影响跟进优先级，运营认为新表单已经带来源参数，技术认为旧值格式不统一、迁入成本高。此时不要投票，而是把字段拆成三个可核对问题：
- 新站上线后，是否仍有人依据“首次来源”决定先联系谁？如果是，保留；如果来源只用于旧报表，改为不迁入。
- 旧值能否对应到新站可识别的来源分类？能对应的保留，不能对应的先留空并记录原因，不强行映射。
- 保留后由谁维护？无人维护的字段会在三个月内变成脏数据，不如不迁。
按这三个问题走，假设结论是：保留“首次来源”，但只保留能对应到新分类的值；不保留“意向等级”，因为新流程改由客服在回访后标注；“历史报价附件”不进入公开表单，改为在内部交接文档中保留索引。这个结论不是最优解，但它把“要不要”变成了“谁在什么动作里用、用完谁维护”。
区分三种无法迁入的原因，处理方式完全不同
字段迁不进去，原因通常落在三类里，混在一起讨论就会反复拉扯。
- 结构不兼容：旧字段是自由文本，新系统要求固定选项。处理方式是先定义新选项，再决定旧值能否归入；不能归入的保留原文备查，不塞进选项。
- 业务含义变化：同一个字段名在新旧流程里指代不同事实。处理方式是改名或拆成两个字段，并在交接文档里注明旧含义，避免后来人误读。
- 无人承接：字段仍有历史价值，但新流程没有角色负责更新。处理方式是只迁入历史快照，标记为只读，不进入新站的日常编辑界面。
这三种原因的区分依据是：字段是否还参与新动作、旧值是否能被新规则解释、有没有明确维护人。三者都否，才进入不迁入清单；只满足其中一项，也要写清限制条件再决定。
把决定写成可核对的交接记录，再进入迁移
决定保留项之后，实际动作是产出一份字段交接记录，至少包含：旧字段名、新字段名或“不迁入”、保留理由、旧值处理方式、维护角色、核对人。记录完成后，让销售、运营、技术各确认一次，确认的不是“同不同意”，而是“这条记录是否准确描述了你看到的事实”。
这份记录会直接影响下一步：迁移脚本按保留项编写，测试用例按动作清单设计，上线验收时逐条核对字段是否支撑了对应动作。如果跳过记录直接迁数据，后面出现字段缺失时，团队只能凭记忆争论，无法判断是迁移漏了还是本来就不该保留。
什么时候可以暂缓决定
如果某个字段对应的业务动作尚未确定，例如新站是否开放经销商查询还没定，就不要为了“迁完整”先迁进去。暂缓项单独列出，注明触发条件：当经销商查询流程确认后，再评估该字段是否进入。暂缓不等于删除，也不等于默认保留，它只是把决定推迟到有依据的时候。对已有经验的团队来说，真正危险的不是少迁一个字段，而是把一个含义不清的字段迁进去，让后来的人以为它仍然有效。
