先不要按“字段新旧”决定去留,而要先确定每个字段在业务上承担什么角色。更稳妥的做法是:把旧系统里所有字段先分成三类——必须原样保留、可以合并或改写、可以放弃并改为人工备注。分类依据不是字段数量,而是它是否影响后续查询、对账、通知或责任追溯。如果某个字段只用于旧后台展示、没有下游动作,它通常不值得占用新结构的位置。
选一个最常用的业务页面,例如咨询记录、报名信息或订单详情,把它当前实际显示和实际提交的字段全部列出来。注意区分三种东西:页面上看得见的字段、数据库里存着的字段、以及后台人员真正会去查的字段。很多旧系统的字段数量远大于实际使用量,迁移困难往往来自“历史遗留但无人使用”的部分。
对每个字段问四个问题:
完成这一步后,你会得到一张带判断依据的字段表,而不是一张凭感觉勾选的清单。
一个字段值得保留,通常是因为它会影响某个具体动作。比如“意向产品”会影响分配给谁跟进,“提交时间”会影响响应顺序,“来源页面”会影响后续复盘渠道。反过来,如果某个字段填了以后没有人看、没有规则依赖它、导出后也不参与筛选,那它更像是旧系统留下的装饰。
可以按下面的顺序决定:
这里的关键动作是:对每个拟放弃的字段,写一句“放弃后由什么替代”。如果写不出替代方案,就暂时保留;如果能写出替代方案,例如改为人工备注、合并进描述字段、或由后续沟通补齐,就可以进入放弃清单。
假设旧系统里有“固定电话”“手机”“微信号”“邮箱”四个联系字段,而新页面只准备保留两个。不要直接删掉两个,而要先看实际使用情况:如果历史记录中固定电话大多为空,邮箱只用于少数旧客户,那么可以把手机作为主联系方式,微信号作为备选,固定电话和邮箱合并进“其他联系方式”备注。这样既不会丢失已有数据,也不会让新表单继续背负四个输入框。
再假设旧系统里有“客户等级”和“累计消费”两个字段。如果新流程没有自动计算累计消费,也没有按等级分配跟进人,那么保留“累计消费”却没有计算来源,只会让数据越来越旧。此时更合理的决定是:保留“客户等级”作为人工标记,把“累计消费”改为历史备注,并明确它不参与新流程判断。这个例子的重点不是照搬结论,而是说明一个判断方法——字段是否有持续的数据来源和下游用途。
在正式迁移前,选一小批旧记录做试跑,把字段按初步清单导入测试环境。试跑后检查三件事:
试跑结果会直接影响下一步:如果某字段格式错误率高但业务上必须保留,就应先制定清洗规则,而不是先上线;如果某字段格式正确但无人使用,就把它移入备注或历史表,减少新页面的输入负担。这样做的结果是,保留项不是一次性拍板,而是经过小范围验证后收敛。
字段取舍完成后,至少保留一份简短说明:哪些字段进入新结构,哪些合并,哪些放弃,放弃后的替代方式是什么。这样当后续有人问“为什么旧系统里的某个信息不见了”,你能指出它被合并到哪个字段或转入了备注,而不是重新翻旧系统猜测。对遵义做网站而言,旧系统迁移的难点通常不在技术导入,而在于业务角色没有提前说清。先完成字段盘点和试跑,再决定保留项,后续的表单设计、后台查看和导出对账都会少很多返工。