长沙网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b97da5dd1776.html
📄
长沙网站开发：旧系统字段无法完整迁入时怎样决定保留项
先按“下游是否依赖”而不是“字段是否漂亮”来分：凡是前台展示、搜索筛选、表单回填、对账或导出中至少有一处必须读取的字段，进入保留清单；只用于历史备注、内部编号且没有任何读取路径的字段，进入封存清单。两条路都成立，区别在于你愿意承担多少数据清洗和回归验证成本。
把待迁字段先变成一张可判定表
不要从数据库表结构开始看，从你手上真正要交付的那个页面或那份导出文件开始。假设旧系统里有一张“客户档案”表，字段包括姓名、手机、来源备注、内部评级、创建时间、最后跟进人。新系统只接受姓名、手机、来源、创建时间。此时不要问“哪些字段重要”，而要逐字段标注三件事：读取位置（哪个页面、哪条接口、哪份报表会用到）、缺失后果（页面空白、筛选失效、无法对账、还是完全无影响）、迁移代价（能否直接映射、是否需要拆分或合并、是否要人工补录）。
这张表的作用是让争论从“这个字段以后可能有用”落到“如果不迁，哪一个具体动作会失败”。如果某个字段没有任何读取位置，缺失后果写“无”，它就不该占用首轮迁移窗口。
保留项优先满足“可验证的下游依赖”
保留不等于原样照搬。对每个进入保留清单的字段，先确认它在新系统里的落点：是独立字段、合并进备注、还是转成标签或分类。判断标准可以简化成一句：迁移后能否用一条可重复的检查证明它没丢。例如来源备注可以合并成“来源+备注”两个字段，只要前台筛选和导出仍能按来源过滤，就算通过；如果合并后筛选条件无法表达，就应保留为独立字段或单独建映射表。
实际动作：拿三条真实旧数据（可脱敏）跑一遍新系统的写入和读取，记录哪些字段在页面上可见、哪些在筛选条件里可命中、哪些在导出文件中出现。这个动作的结果会直接决定下一步——通过则进入批量迁移，不通过则回到字段映射表修改落点，而不是先迁完再补。
封存项要写清“不迁的代价”和恢复路径
不保留的字段不是删除，而是封存在旧库或归档文件中，并记录三件事：封存原因、最后可读取的方式、如果将来需要恢复由谁执行。这样做的好处是避免两种常见损失：一是把仍有对账价值的内部评级直接丢掉，二是把已经无人读取的历史备注拖进新系统，增加字段维护和权限配置的负担。
如果旧字段涉及个人联系信息或内部评级，封存时还要考虑访问权限和保留期限。这里不需要复杂方案，只要在迁移记录里写清楚“该字段不进入新系统，原库保留至某次归档完成”，后续排查时就不会出现“到底迁没迁”的争议。
用一次小范围回归决定是否扩大保留范围
假设你最终保留了姓名、手机、来源、创建时间，封存了内部评级和最后跟进人。上线前用一组旧数据做回归：前台展示是否正常、按来源筛选是否命中、导出文件是否包含保留字段、表单回填是否完整。如果回归发现某个封存字段其实被某条报表间接引用，就把它从封存清单移回保留清单，并重新评估迁移代价；如果没有发现读取路径，就维持封存，不再因为“以后可能有用”而扩大范围。
这个顺序的关键是：先证明依赖，再决定保留；先小范围验证，再批量执行。它不能保证迁移一次成功，但能让每一次字段取舍都有可复查的依据，而不是靠印象拍板。
