老旧校园网切换新认证计费系统这件事，跟新建一个认证计费系统的难度不是一个量级的。新建项目只要规划好、实施到位就行，但切换意味着有一个正在运行的老系统不能停——学生还要正常上网、老师还要正常访问校内资源、已有的认证策略和计费数据还要延续。中断几个小时可能就引发全校范围的投诉。所以平滑迁移的核心不是技术方案有多先进，而是过渡策略够不够稳妥。

迁移的起点一定是老系统的数据盘点。新系统上线前，必须把老系统里的所有用户数据完完整整地导出来——包括用户列表、套餐信息、账户余额、绑定关系（账号-MAC、账号-运营商账号）和至少过去六个月的历史账单。这一步看起来简单，实操中至少会遇到三类问题：一是老系统的数据字段定义跟新系统不完全对应——有的老系统用"user_type"区分教职工和学生，新系统用"user_role"，迁移脚本必须做字段映射；二是数据量大的话全量导出本身就耗时——一个运行了五年的老系统里可能积累了十多万条用户记录和上百万条账单记录；三是老系统的数据库可能因为长期没维护产生了脏数据——比如重复的用户记录、失效但没清理的绑定关系、金额对不上的账单。这些脏数据不能直接迁到新系统里，否则新系统一开始上线就带着一堆历史包袱。

数据迁移之前建议做一轮数据清洗——去重、补全缺失字段、标记异常数据。比如有些老用户的手机号字段是空值，迁到新系统后实名认证功能就没法正常工作，需要在迁移时批量标记这些用户并要求他们首次登录时强制补全手机号。再比如有些老账单的状态跟实际余额对不上，这种没法自动处理，只能标记出来人工逐条核对。

迁移策略上最稳妥的做法是分阶段过渡，而不是一次性切换。第一阶段：新系统旁挂部署，只做数据同步和功能验证——老系统继续承担所有认证请求，新系统从老系统同步用户数据和账单数据，在这个阶段把新系统的所有功能模块跑通，包括Portal认证、套餐计费、自助运营等，但流量还是走老系统。第二阶段：选取一个低风险区域做试点——比如先切一个学院或者一栋宿舍楼，这个区域的用户认证流量全部走新系统。试运行一到两周，观察认证成功率、用户投诉量、计费准确性是否达标。第三阶段：按区域逐步扩大切换范围，每批切换之后观察两天再切下一批。第四阶段：全校切换完毕，老系统保留做历史数据查询，不再承接认证请求。

分阶段切换的关键前提是新老系统必须有一段时间的并行运行能力。这个"并行"不是简单的同时开机，而是两个系统之间要有数据同步机制——老系统上产生的认证记录和计费数据要实时同步到新系统，保证新系统在被切为用户主系统的时候数据是完整的。如果新老系统之间没有做双向同步，等试点区域切过来之后发现新系统里只有试点区域的用户数据，没有全校的历史数据，那代拨对账和财务报表就全乱了。

还有一个关键的过渡环节是终端侧的无感切换。如果新老系统切换之后学生需要重新输入账号密码甚至重新注册，那体验就太差了。新系统必须能够继承老系统的用户认证凭据——比如通过LDAP同步保证学号密码一致，或者在新系统上线前批量导入老系统的密码哈希值。MAC无感知认证的绑定关系也需要同步——如果老系统上已经绑定了大量学生的MAC地址，但这些绑定关系没有被迁过来，新系统上线后所有学生都要重新做首次认证，无感知认证就形同虚设了。

应急回退方案是迁移计划里绝对不能省略的内容。不管前期测试做了多少轮，必须保留一键回退到老系统的能力。回退方案的核心是在网络层面——AC上的RADIUS服务器配置同时指向新老两个系统的IP地址，正常情况下老系统IP放在第一位（或者设置优先级），等切换的时候只需要在AC上调整优先级顺序。一旦新系统出现严重故障，AC配置回滚到指向老系统，恢复时间可以控制在几分钟内。

最后提醒一个实际问题：迁移期间的用户沟通。如果学生和老师在完全没有心理预期的情况下突然发现认证页面变了、充值的入口换了、查账的菜单跟以前不一样了，一定会产生大量不必要的咨询和投诉。应该在切换前通过学校官方渠道——企业微信、校园门户、公众号——提前发布通知，告知"某月某日起校园网认证系统将进行升级，期间可能的短暂影响和新的操作指南"。同时准备好一份简洁的FAQ页面和自助排障指引，挂在Portal页面上显眼的位置。做好了这些沟通工作，迁移期间的投诉量可以减少一大半。