做校园网改造项目，最让技术团队头疼的不是新系统怎么搭，而是旧系统的数据怎么迁。老系统跑了五年八年，里面存着几万条用户账号、几十万条计费记录、一堆没人敢动的配置表。业务部门说要平滑过渡不能丢数据，运维团队说老系统根本没人知道里面哪些表还在用，甲方说你看着办但出了问题算你的。校园WiFi网络计费系统的数据迁移，远比装一套新系统复杂得多。

教训一：不要相信老系统的数据是干净的

每一个做了多年校园WiFi网络计费系统运维的人都会告诉你同一件事：老系统的数据一定有脏数据，只是你不知道在哪里。常见的脏数据类型包括：余额为负数的账号（扣费逻辑有bug导致的）、同一个学号绑定了两个账号（不同年份注册的）、套餐已过期但状态还是正常（定时任务没跑）、流量记录里出现负数（计费引擎的溢出bug）。如果你不做数据清洗直接迁移，这些脏数据会跟着进入新系统，而且在新系统里可能触发不同的业务逻辑，导致更严重的问题。比如老系统允许余额为负但只是不让学生上网，新系统发现余额为负直接标记账号异常需要人工处理，结果开学第一天几万个账号被锁。正确的做法是先做一轮数据审计，把所有异常数据筛出来，跟业务方确认每类异常的处理规则，然后按照规则做批量修正，最后再做迁移。这一步至少预留两周时间，因为确认异常数据的处理规则需要跟多个部门来回沟通。

教训二：历史计费记录的迁移要谨慎取舍

校园WiFi网络计费系统里最占存储空间的就是历史计费记录。一个运行了五年的系统，计费流水可能有上千万条，涉及几百个GB的数据。这些数据要不要全量迁移？答案取决于业务需求。如果只是需要最近一年的账单查询功能，那迁移最近12个月的数据就够了，更早的数据可以归档到离线存储。但很多学校的要求是"全部迁"，理由是审计需要。这时候要评估两个风险：一是迁移时间，几百GB的数据全量迁移可能需要几十个小时，期间系统需要停机；二是数据格式兼容性，老系统的计费模型和新系统可能不完全一致，字段映射和单位转换都需要逐一验证。一个折中方案是：最近一年的数据全量迁移并保证在线查询，更早的数据只迁移汇总级别（按月汇总的流量和费用），明细数据做归档备份。这样既满足了审计需要，又不会让迁移窗口拉得太长。

教训三：并行运行期比你想的长

几乎所有的校园WiFi网络计费系统迁移项目都会设一个并行运行期，新老系统同时运行一段时间，确认没问题再切到新系统。但大多数人低估了并行运行期需要多长。理想情况下并行两周就够了，但实际上经常会延长到一两个月甚至更久。原因包括：新系统的计费规则需要跟老系统对齐，跑出来的月账单必须逐项对比；某些边界场景（比如退费、套餐变更、节假日特殊计费）在并行期内不一定能遇到，需要等到下一个计费周期才能验证；用户端的问题反馈有滞后性，学生可能过了一周才发现自己的计费有异常。并行运行期间还有一个隐蔽的坑：两个系统同时记录用户的上网行为，但扣费只在一个系统里执行，如果学生在并行期内的消费记录分散在两个系统里，合并的时候需要对齐时间戳和会话ID，这个对齐工作的复杂度取决于两个系统的会话标识是否兼容。这种事不是理论推演，是被真实项目教训过很多次的结论。

迁移窗口的选择

校园WiFi网络计费系统的数据迁移窗口选择也很有讲究。绝对不要选在学期中间做迁移，因为那个时候系统有持续的在线用户和计费流量，停机迁移会影响正常业务。最佳窗口是寒暑假期间，用户量最低，可以安排计划性停机。但如果你的项目进度拖到了开学前才完成开发，那迁移窗口就非常紧张了——你必须在一个周末内完成数据迁移、系统配置、功能验证和并行启动。这种情况下的建议是：提前两周开始做数据预迁移，把不需要实时同步的历史数据先迁过去，只留下最近一周的增量数据到正式迁移窗口处理。这样可以把正式迁移窗口从48小时压缩到8小时以内。