把校园上网计费系统从旧平台迁到新平台，最容易被低估的工作不是系统部署，也不是接口对接，而是数据清洗。做得不好，新系统上线第一天学生就会发现账单对不上、套餐失效、欠费状态显示错误，投诉工单直接涌过来。

见过几个做得比较糟糕的迁移案例，回溯起来问题几乎全都集中在数据清洗阶段。把这些情况整理出来，供做类似项目的同行参考。

旧系统的数据质量通常比想象的要差。大多数高校的校园上网计费系统跑了五年以上，里面的数据是多轮历史操作的累积结果。早期建档时可能没有统一规范，时间戳有的用本地时间有的用UTC时间，字段格式不一致；中间经历过几次版本升级，每次升级时数据结构小改了但历史数据没有统一处理，遗留了一批格式异常的旧记录；还有一些数据是手工录入的，比如教职工免费宽带账号的设置，在计费规则里是一个特殊状态。

开始清洗之前，建议先做一次数据普查，统计出：总账号数，其中活跃账号多少、休眠账号多少、状态异常账号多少；历史计费记录的时间跨度；套餐种类和各套餐绑定账号数量；欠费账号的数量和欠费金额区间。这个普查结果能帮你判断清洗的工作量，也是后期和新系统做数据校验的基线。

毕业生账号和离职教职工账号的处理是最容易漏掉的。旧系统跑了几年，里面一定有大量已经不在校的学生账号。这批账号从技术上看是"历史数据"，从财务上看是"余额可能需要退款的资产"，从等保上看是"需要按学籍状态确认是否应该保留上网权限"的数据。迁移时，这批账号有三种处理方式：全部标记为停用状态迁移到新系统；只迁移有余额的账号，其余直接清理；完全不迁移，只保留历史查询接口。三种方式各有合理性，但不能不决策就默认走一种方式，每种方式对财务、对等保、对可能的退款申诉，都有不同的影响。

有一个学校在迁移时默认把所有历史账号都迁了过去，包括三年前毕业的学生账号，迁过来之后发现新系统里有大量账号的套餐状态是"已过期但有余额"，新系统按照自己的逻辑给这些账号发了套餐过期通知，结果毕业好几年的学生收到了欠费提醒短信，投诉打到学校客服，还有人打到12345。这个问题完全可以在迁移前做好账号状态清洗来避免。

历史套餐变更记录的迁移需要逐条映射，不能批量覆盖。旧系统里的套餐结构，很可能和新系统完全不一样。旧系统可能有"包月基础带宽包"、"暑期特惠包"、"教职工免费包"，新系统里的套餐是按带宽档位重新设计的。迁移时需要做一个套餐映射表，把每种旧套餐对应到新系统的哪个套餐，差价如何处理，有效期如何折算。这个映射表必须由学校财务处、网络中心、新系统厂商三方确认并签字，因为任何一方对映射规则理解不一致，都会在后续产生账单争议。见过一个项目，映射规则是厂商自己定的，上线后财务发现旧套餐折算方式和他们理解的不一致，要求全部回退重算，那批账单回退的工作量比整个迁移项目还麻烦。

欠费账号的迁移要保留完整的欠费历史，不能清零。旧系统里有欠费记录的账号，迁到新系统后，欠费状态必须完整保留。不能因为"方便迁移"就把欠费记录清零，或者把欠费账号统一设置成"余额为0"状态。原因是：欠费记录是财务审计的依据，如果历史欠费在迁移后消失了，财务在做年度审计时对不上账，这是一个严重的财务风险。另外，有些学生欠费是因为离校前没有结清，学校有权利在他们需要开具在校证明或其他手续时核查欠费情况。迁移完成后，要做一次欠费账号的核对：新系统里的欠费账号数量、总欠费金额和旧系统的历史数据必须完全一致，不允许存在差值。

实际项目中，系统切换不是某天零点旧系统关、新系统开。通常有一个两到三周的并行期，旧系统承担正式认证计费，新系统做测试和数据追赶。这段时间里，用户在旧系统里发生的充值、套餐变更、欠费销账，要同步到新系统，否则正式切换时新系统里的数据就是滞后的。这个同步机制的设计，应该在项目方案评审阶段就明确下来：谁来维护同步脚本、同步频率是多少、同步失败时的报警和补救流程是什么、并行期结束前要做几次数据一致性核验。如果这些没有明确，并行期就会变成一个混乱的状态，切换那天的数据不一致风险极高。

数据清洗的工作量没法在项目签约阶段精确估算，但这件事必须给它足够的时间和资源。把数据清洗当成可以压缩的工期，是高校信息化项目里最常见的决策失误之一。