一套校园网WiFi网络计费系统用了七八年，到了不得不换的时候。原因通常是多个叠加在一起的：老系统的厂商不再维护、硬件已经停产买不到备件、新的合规要求（比如IPv6支持、新的实名认证规范）老系统实现不了。这时候学校会启动一个"迁移项目"。迁移听起来简单，但实际上比全新部署麻烦多了，因为你要在不中断现有用户服务的前提下完成系统替换。

迁移前最容易被忽视的准备工作

大部分迁移项目在启动时，采购部门和IT部门的注意力都放在"新系统有哪些功能"上，而忽略了一个更基础的问题：老系统里现在存着什么数据，哪些需要迁移，哪些可以不迁？

校园网计费系统通常存有几类数据：用户账号（学号/工号、密码、角色）、计费记录（历史流量、余额、账单）、上网日志（认证日志、IP分配日志）、设备配置（AP信息、AC关联、VLAN配置）。这四类数据的迁移难度和必要性完全不同。

用户账号基本上必须迁移，否则每个用户都要重新注册或者重新绑定，开学季集中迁移会产生海量的运维请求。计费记录如果学校有历史账务查询的需求（比如某个学生补缴网费需要查历史记录），也需要迁移；如果历史账务已经结清且无需查询，可以归档而不是实时迁移。上网日志必须保留（合规要求），但不一定要迁到新系统里——可以在老系统上保留只读查询权限，或者导出归档存储。设备配置通常不能直接迁移，因为新系统可能用完全不同的配置格式，要重新配置。

这个数据盘点的工作，最好在签合同之前就做，而不是等到项目启动之后。因为数据量和数据质量会直接影响迁移工期。我见过一个案例，学校以为用户账号数据"很整齐"，等迁移工程师拿到数据导出文件才发现：里面有大量重复账号（同一个学号注册了三四次）、大量已离校学生的账号（没有及时注销）、部分账号的手机号字段是乱填的（比如"11111111111"）。光是数据清洗就花了两周时间。

迁移窗口的选择

校园网的迁移不能在任意时间进行。服务中断对学生的影响很大，必须选择影响最小的时间窗口。通常有几个可选时间：

暑假期间，学生大量离校，在校人数最少。这是理想的迁移窗口，网络流量低、用户投诉少、出了问题有时间慢慢修。但要注意：暑假期间也有暑期生、教职工、后勤人员在用网络，不能完全停服。

某个工作日的凌晨到清晨（比如周二的00:00-6:00）。如果迁移只需要短暂中断（2到4小时），选这个窗口可以在学期中执行，减少对正常学期的影响。但风险是如果出了意外，中断时间超过预期，凌晨处理问题的人力资源有限。

总的来说，大规模迁移（涉及整个认证服务停机）首选暑假；小范围配置切换（比如只换Portal前端）可以选凌晨窗口。千万不要在开学季、期末考试周或者选课期间做迁移，这些时间段任何网络中断都会被无限放大。

并行运行期的管理

迁移不是一个"一刀切"的动作，成熟的做法是有一个并行运行期：新旧系统同时在线，先把一小部分用户（比如某栋宿舍楼的学生）迁移到新系统，观察运行情况，没有问题再逐步扩大范围，最后全量切换。

并行运行期的管理要注意几个点。第一是双写问题：并行期间用户的认证日志要写到哪里？如果新旧系统各写各的，后续的合规查询会很麻烦；最好是在新系统里做，同时把新系统的日志同步备份到一个统一存储。第二是账号同步：如果在并行期间有新生入学或者有用户修改了密码，这些变动要同步到两个系统里，否则切换时会出现账号不一致。第三是回滚预案：如果新系统在某个环节出了严重问题，必须能快速回滚到老系统。回滚的操作步骤要在迁移前就写好、演练过，不能等到需要回滚的时候才开始想怎么做。

迁移后的验收不能走形式

很多迁移项目的验收是"学生能上网了，系统能登录了，走个流程签个字"。这种验收太浅，埋下了大量隐患。

迁移后的验收应该覆盖几个维度：功能验收（认证方式、带宽策略、时段控制等核心功能是否按预期工作）、性能验收（在接近峰值并发的情况下，响应时间和成功率是否达标）、合规验收（实名认证链路是否完整、日志是否在写入且格式正确）、数据迁移验收（抽样核查迁移后的用户账号数据是否完整、历史日志是否可查）。

最后一条尤其容易被忽视：老系统上的历史数据要不要做可查性验收？如果公安来检查，要求查一条六个月前的认证记录，你能在哪里查到？这个问题如果没有在迁移项目里明确定义，验收签字之后再来补，责任就不好认定了。

迁移项目的最终目标不只是"换了一个新系统"，而是在不中断服务、不丢失历史数据、不降低合规水位的前提下，让新系统顺利接管所有工作。做到这三个"不"，才算是一次合格的迁移。