宿舍上网计费系统用久了，总会走到要换的一天：旧设备过保、厂商不维护了、新平台功能更全。但割接比新建更难，因为它是带着运行中的业务换引擎，几千个学生正在用，换的过程中不能大面积断网。我们做过几次割接保障，踩过的坑比新建多。这篇讲从旧设备割接到新平台，哪些点想清楚能少掉几层皮。

先盘点旧系统的真实资产

割接前第一件事，是把旧系统里到底有什么理清楚：多少账号、绑了哪些设备、房间对应关系、历史账单存在哪、有没有手工改过的脏数据。很多学校旧系统跑几年，数据早已和最初不一致，不盘点直接迁，迁过去就是一团乱。我们建议先做一轮全量导出和核对，把异常记录挑出来先修。盘点花的时间往往比割接本身长，但这步省了，后面天天在脏数据里救火。旧资产清点，是割接的地基。

新旧并行比一刀切稳

最危险的割接是某个晚上直接关旧开新，一旦新平台出问题，全楼断网没退路。我们建议新旧并行一段时间：新平台先接进来跑真实流量，旧系统保留兜底，哪栋楼新平台不稳就切回旧。并行会增加短期复杂度，但给了犯错的空间。我们见过一所学校直接切换，新平台认证接口有bug，凌晨全宿舍连不上，维修到天亮。并行虽然麻烦，却是割接里最便宜的保险。

账号和账单映射要一次对清

新旧系统字段往往不一样，学号、房间号、余额的对应关系要在迁移前映射清楚。映射错一个，学生过来发现余额没了或者房间不对，投诉直接爆。我们建议做一张映射表，全量跑一遍迁移脚本后，抽样核对几百条，确认账号、绑定、余额都对得上再放开。历史账单最好原样归档，能查就行，不一定要转成新格式。映射是割接最容易翻车的地方，对清了后面才顺。

切换窗口选在学生最少的时段

即便并行，最终切到新平台主导也要选窗口。最好的窗口是假期或者考试周之后，学生不在宿舍的高峰。我们建议避开开学、选课、考试这些敏感期，提前发通知告诉学生某时段可能短暂波动。切换当天留足人手，新旧两边都盯着，出问题立刻回退。窗口选错，比如选在选课周，一点点波动都会被人放大成事故。割接的窗口，是和校历博弈出来的，不是随便挑个深夜。

旧系统保留只读期再下线

新平台跑稳之前，旧系统别急着拆。我们建议保留一个只读归档期，比如三个月，既防回退也能应对查询和审计。这期间如果学生质疑某笔历史扣费，旧数据还在，说得清。确认新平台账单、认证、对账都无异常，再正式归档下线。很多学校割接完立刻删旧系统，结果一周后财务要查一笔老账，什么都找不回。留一手的成本极低，删早了的代价极高。

割接后做一轮全量体检

切完不是结束，要跑一轮体检：认证成功率、对账差异、同步延迟、带宽余量，全看一遍，和割接前 baseline 对比。我们建议体检持续一到两周，每天看趋势，异常立刻查。割接后的头两周是最脆弱的，旧问题可能没清干净、新配置可能漏一项。把体检做成固定动作，割接才算真正收尾。很多事故不在切换那一刻，在切换后没人看的那几天。

回退预案要比割接方案先写好

割接最怕的是新平台出问题却回不去。我们建议回退预案和割接方案一起出，甚至先写回退：什么信号触发回退、回退到哪、旧系统怎么接手、学生端要发什么通知，全列清楚，并且在并行期演练一次。很多团队只盯怎么切过去，没想怎么切回来，真出事时手忙脚乱。回退要快、要可逆，数据不能因回退丢。演练不一定真回退，但要走一遍流程确认能执行。预案写在本子上是纸，演练过才是真保险。割接的稳妥，七分在准备，三分在执行。

割接也要写复盘

割接完建议做一次复盘，哪步卡了、哪步比预期顺、回退演练有没有用上，记下来留给下次。学校网络演进是常态，这次的经验是下一次的预案。复盘不用长，把关键教训写进运维手册就值。

宿舍上网计费系统从旧设备割接到新平台，本质是带着运行中的业务换引擎。盘点资产、新旧并行、映射对清、选对窗口、留档旧系统、割接后体检，这几步做到，替换就能悄无声息地完成，师生几乎感觉不到变化。迁移的最高境界，就是没人发现你迁过了。