莆田企业建站：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3788c713bd15.html
📄
莆田企业建站：旧系统字段无法完整迁入时怎样决定保留项
先按“这个字段离开旧系统后，还有没有人会用到它”来分，而不是按数据库里能不能导出。能导出但没人用的字段，迁过去只会增加新站的维护负担；导不出但业务仍在用的字段，则要先找到替代承载方式，再决定是否放弃。判断保留项的核心不是技术可行性，而是字段对应的业务动作是否还会继续发生。
业务动作仍在继续的字段：先补替代承载，再迁移
如果某个字段对应的是报价、订单跟进、售后记录这类每天还在产生的动作，那么它的价值不在历史数据本身，而在于新站之后还要继续往里写。此时要问的不是“怎么把这个字段搬过去”，而是“这个动作以后在新站里由谁承载”。
常见做法是把它拆成两部分：历史值以只读方式留档，新值改由新系统的标准字段或独立表单承接。例如旧系统里有一个自由填写的“客户特殊要求”文本字段，新站表单没有对应项。可以保留一个只读的历史备注区，同时在新表单里增加结构化的需求选项。这样做的结果是：老数据仍可查，新数据不再依赖一个无法维护的字段。
实施动作上，建议先列出该字段最近仍在被写入的记录数量，再决定是否需要在新站重建入口。如果近一段时间几乎没有新增，只是历史存量大，那么只读留档就够了，不必为它单独开发录入界面。这一步的判断会直接影响后面的开发量：留档只需导出静态内容，重建入口则涉及表单、权限和校验。
业务动作已经停止的字段：优先舍去，只留有检索价值的摘要
如果字段对应的动作已经不再发生，比如旧系统里某个已停用渠道的登记项、早期活动的临时标记，那么把它整体迁入新站通常得不偿失。它不会有人再写，却会出现在后台、导出和权限配置里，增加误操作和解释成本。
这时可以只保留可检索的摘要，而不是完整字段。例如把旧字段的值合并进一条历史备注，或在迁移清单里注明“该字段已停止使用，原值见备份”。判断依据是：未来是否有人会按这个字段去筛选或核对。如果答案是否定的，就不必让它出现在新站的数据结构里。
需要说明的是，导出记录变少、抓取量下降这类现象，不能单独证明舍弃字段是对的。它们也可能来自访问减少、入口调整或统计口径变化。真正能支撑决定的，是业务方确认该动作已经停止，并且没有下游流程依赖它。
两种条件的分界：谁还会写入，谁只会读取
把字段分成“还会被写入”和“只会被读取”两类，比按新旧程度分更实用。还会被写入的字段，必须在新站有明确的归属位置和责任人；只会被读取的字段，可以用低成本方式留档。两者的取舍条件不同：前者要保证流程不断，后者只要保证查得到。
- 还会写入：评估新站是否有等价字段，没有则先补承载方式，再迁移历史值。
- 只会读取：优先考虑只读留档或摘要合并，避免为它重建完整录入逻辑。
- 两者都不成立：即无人写入也无人读取，可以只保留在旧备份中，不进入新站。
这个分界能避免一种常见错误：把“技术上能导出”当成“业务上需要保留”。导出能力只说明数据拿得出来，不说明它在新站还有位置。
一个假设例子：三种字段的处理顺序
假设某企业旧站后台有三个字段：A 是仍在使用的客户等级，B 是已停用渠道的来源标记，C 是早期活动的一次性编号。按上面的分界，A 属于还会写入，应先确认新站是否有客户等级字段，没有则补上，再迁移历史值；B 属于只会读取，可以合并进历史备注；C 属于两者都不成立，留在备份即可。这个例子的数字和字段名都是假设，用于说明比较方法，不是真实项目记录。
执行时可以先做一张三列表：字段名、最近是否仍有新增、未来谁会按它筛选。填完这张表，保留项基本就清楚了。它带来的下一步影响是：进入迁移脚本编写时，只处理被标记为保留的字段，其余字段不再出现在新站结构里，减少后续核对范围。
例外：合规、对账或合同要求时必须保留
有些字段虽然业务动作已经停止，但出于对账、合同留存或内部审计要求，仍需要可查。这类字段不一定要进入新站前台或日常后台，但要有明确的存放位置和读取方式。处理办法是把它归入“只读留档”，而不是按普通停用字段直接舍弃。
适用条件是：能说明谁会查、多久可能查一次、通过什么方式查。如果这三点都说不清，就不必为它单独设计入口。反之，如果确实存在定期核对需求，就应在迁移说明里写清存放位置，避免日后找不到而重新翻旧系统。
最终决定保留项时，先确认业务动作是否继续，再确认是否有人会读取，最后才考虑技术迁移成本。按这个顺序，字段的去留会有可解释的依据，而不是靠导出是否顺利来拍板。
