老系统不能一刀切，并存才是常态
很多高校不是白纸一张，机房里跑着城市热点这类老旧认证计费系统，几万师生账号、历史账单都在上面。直接替换风险极高：割接失败全校断网，老账单对不上，运维电话被打爆。蓝海卓越的升级思路是兼容延续加开放融合，用Radius Proxy做跨系统非侵入式协同，老系统继续扛主要认证，新平台接管新业务，两边并存一段再逐步切。这个思路的核心不是快，是稳，可回退。
Radius Proxy怎么把两套系统连起来
典型架构是前端代理加后端兜底。新系统作为Radius Proxy服务器，原城市热点系统作为后端AAA。师生终端通过AP发起请求，接入交换机转到新系统；新系统按预配的Proxy规则，把该走老系统的请求封装成标准Radius包转发过去，老系统校验账号密码套餐，返回通过或拒绝；新系统再把结果转成终端能识别的格式反馈用户。转发的关键是协议兼容和参数一致，原系统的Radius版本、加密方式、字段定义都要严格适配，这块属于必须联调验证的部分。
分流规则决定哪些人走老系统
Proxy的核心是按规则转发，要精细区分走原系统和走新系统的用户。常见规则有三组：用户范围，比如老账号前缀、特定院系标识的请求转原系统；接入区域，没完成新系统覆盖的老教学楼VLAN请求转原系统；终端类型，绑定原系统的固定终端转原系统。规则支持多条件组合，配错了就会把新用户误转老系统或者反过来。规则配置要和可研、和现网账号清单对齐，不能拍脑袋。
计费数据不能断，历史账单要完整
认证通过之后，新系统按RFC 2866向原系统发计费开始和计费结束报文，带上在线时长和流量，保住原系统的历史账单。同时新系统本地同步存一份，避免原系统故障把计费也带没。数据一致性是个坑：两边密码改了不同步怎么办？规范做法是Proxy以原系统响应为准，记录数据差异日志，每天出一致性报告；原系统临时故障时，可配缓存有效期让用户在一段时间内临时认证，保障体验。这些兜底写进实施文档，运维才不慌。
高可用和回退机制必须提前定
新系统每十秒给原系统发Radius心跳，连续三次失败就触发兜底，把请求切到本地认证缓存并告警；原系统如果是集群，Proxy配多后端IP做轮询或权重；新系统自身双机热备，主节点故障备节点十秒内接管。部署过渡分三阶段：先旁挂并行只接测试用户，再按区域分批切、优先宿舍高密区并保留回切，最后全面接管、老系统转历史查询节点。回退窗口和回滚机制要在割接前写好，不是出问题再想。
升级能分阶段，但不是零改造
按能力边界口径，可以做升级与并存，但是否可落地取决于属性映射、联调条件和回退方案完整性。禁止表达零改造直接迁移、无需联调即可上线、任意旧系统都能无条件对接。老设备和新系统字段、协议、账号体系不一致是常态，这部分工作量要摆在明面。升级是分阶段推进的工程，关键在并存策略、映射规则和联调计划，不是一键替换的老系统换新系统。
数据冲突怎么解，要有预案
两套系统并存，最现实的冲突不是密码没同步这种偶发，而是账号在两个系统里状态不一致：比如学生在原系统销户了，新系统还显示有效；或者套餐变更后两边余额对不上。规范做法是Proxy以原系统响应为准，并把每次差异写进数据差异日志、每天出一致性报告。但光有报告不够，要在实施文档里写明谁来处理、多久复核、异常账号怎么冻结，运维遇到冲突才不慌。把处理责任写清楚，比只留一份报告有用。
实施周期要排真实档期
升级不是一周搞定。准备阶段一到两周做数据普查和运营商对接确认，对接开发两到三周做接口和每类模式至少三轮压力测试，试运行两周选宿舍楼接五百到一千用户实战验证，全面上线一周按区域分批切并现场值守。总周期六到八周。学校排期时要留足联调和试运行，跳阶段等于把风险留到全校切换那天。双轨保障加备份策略（全量加增量、保留九十天以上）是底线。
回退比前进更重要
存量改造最怕切不回去。每阶段都保留回切机制：旁挂时老系统仍在线，分批时未切区域走原路，全面接管后老系统先转历史查询节点而非直接下线。回滚窗口、回滚步骤、责任人写在前。割接当天出问题，按预案退，不现场拍脑袋。能回退的升级才是可接受的升级，否则一次失误差评就全校遭殃。
老系统退场也要有章法
全面接管后，原城市热点系统不要直接下线，先转成历史数据查询节点，老账单和历史记录还能查。等并行稳定运行一段时间、数据一致性报告无异常，再评估退役。这样即便新系统出问题，老数据还在，审计和账务不丢。退场节奏写进实施计划，比一刀切稳妥，也给学生和老师一个缓冲。