前年接了一个高校的升级改造项目，旧认证计费系统跑了八年，版本太老，厂商都不支持了。客户想升级到新版本，但旧系统不能停——每天一万多人上网，停了就是教学事故。这种"业务不停顿升级"，是老旧系统改造里最难的一种。

先搞清楚"为什么要升级"

升级改造不是"因为版本老所以要升级"，一定要有明确的驱动因素。常见的驱动因素有：旧版本不再受厂商支持（安全补丁没人管了）、旧版本不支持新功能（比如新的认证协议、新的计费模式）、旧版本性能不够（用户量增长了，系统快撑不住了）、或者就是合规要求（等保测评要求用新版本）。

驱动因素不同，升级方案的设计重点也不一样。如果是因为"安全补丁没人管"，那升级的核心目标是"把安全漏洞补上"，功能可以不变，升级方案要尽量保守。如果是因为"要支持新功能"，那升级就要考虑新功能的配置和测试，方案可以激进一点。

我一般会先跟客户聊清楚：这次升级，最想解决的是什么问题？如果升级后发现有功能变了，能不能接受？这两个问题聊清楚，后面方案设计就不会跑偏。

新旧系统并跑的"数据迁移"难题

老旧系统升级，最麻烦的是数据迁移。用户账号、计费记录、上网日志，这些数据少则几十万条，多则上亿条，要从旧系统的数据库迁移到新系统。迁移不是简单的"倒数据"，因为新旧系统的数据模型可能不一样——旧系统里用户表的字段，新系统里可能改了名字或者拆分成了两个表。

我经历过的项目，数据迁移一般分三步走。第一步是"结构对齐"：把旧系统的数据模型研究清楚，然后做一个映射表，列出"旧系统的哪个字段对应新系统的哪个字段"。第二步是"试迁移"：拿一小部分数据（比如一个院系的用户）做迁移测试，看迁移后数据对不对。第三步是"全量迁移"：在业务低峰期（比如寒暑假），做全量数据迁移，然后切系统。

但"业务低峰期迁移"也有风险：如果迁移失败，回滚也要时间，而业务低峰期可能不长（比如暑假只有两个月，但迁移和测试可能要三周）。所以有些项目会选择"新旧系统并跑"方案：旧系统继续服务，新系统逐步接入，等新系统稳定了再切过来。这个方案风险小，但实施周期长。

升级过程中的"用户无感知"要求

很多单位对认证计费系统升级的要求是"用户无感知"——升级的时候，用户不要重新输账号密码，不要重新下载客户端，不要感觉到任何变化。这个要求合理，但实现起来有难度。

实现"用户无感知"，一般要做几件事：第一，用户账号和密码要能迁移到新系统，而且密码加密方式要兼容（如果新旧系统用的加密算法不一样，那用户的密码就要重置，这就不是"无感知"了）。第二，认证客户端（如果有的话）要能兼容新旧系统，或者提前推送新版本给所有用户。第三，认证成功后的网络权限要跟旧系统一致，不能用户升级完后发现"原来能访问的地址现在访问不了了"。

我一般会建议客户：如果"用户无感知"要求很高，那升级方案就要设计得保守一点——先升级后台系统，前端用户体验暂时不变；等后台稳定了，再逐步升级前端。

新旧系统切换的"回滚预案"

升级项目最怕的是"升级后出问题，而且短时间内解决不了"。这时候，能不能快速回滚到旧系统，就非常重要。

回滚预案一般要包括这几个部分：旧系统的全量备份（升级前做）、旧系统运行环境的保留（比如旧服务器先不要格式化或者下线）、回滚操作步骤的文档化（出问题了，按文档操作就能回滚）、回滚后的验证方案（回滚后怎么确认旧系统是正常的）。

我见过一个项目，升级后新系统频繁崩溃，决定回滚，但发现旧系统的数据库已经被新系统的迁移工具改过了（迁移工具为了做兼容，改了旧数据库的某些表结构），结果旧系统也起不来了。最后只能熬夜修复新旧两个系统，非常被动。这个案例的教训是：数据迁移前，一定要做全量备份，而且备份要能独立恢复，不能被迁移工具改坏。

升级后的"功能对齐"测试

旧系统跑了多年，上面可能有很多"非标准配置"——比如客户自己定制的报表、自己写的脚本、自己配的特殊策略。升级到新系统后，这些"非标准配置"能不能在新系统上继续用，要仔细测试。

我一般会做一个"功能对齐清单"：列出旧系统上所有的功能点（包括那些"非标准"的），然后一项一项测试新系统上能不能实现。有些功能，新版本可能不支持了（比如厂商觉得某个功能没人用，就在新版本里去掉了），那就要么找替代方案，要么说服客户放弃这个功能。

还有一个点：旧系统上可能积累了Discovery很多"临时配置"——比如某次活动临时开了个白名单，活动后没删。这些临时配置，升级的时候要梳理一遍，该删的删，该保留的保留。我见过升级后，有些用户的上网权限跟旧系统不一样，查下来就是因为旧系统上有个临时配置没被迁移过来。

项目管理上的"多部门协调"

老旧系统升级改造，一般不是网络中心一个部门的事。要跟财务处协调（如果涉及计费策略变更）、要跟信息化办公室协调（如果涉及等保测评）、要跟各院系协调（如果要安排用户做升级配合测试）。

这种多部门协调的项目，最关键的是"项目时间表要跟各部门的关键时间点对齐"。比如，有些学校寒暑假期间要封楼装修，那系统升级就要避开封楼时间；有些单位年底要做预算结算，那如果升级涉及新的采购，就要赶在预算审批前完成。

我一般会建议客户：升级改造项目，最好成立一个"项目组"，把相关部门的联系人都要纳入进来，定期开进度会。不要等到要配合了才去找人，那时候可能对方已经有别的工作安排，配合不上。

升级改造后的"知识转移"

新系统上线后，旧系统的运维经验可能不适用了。这时候要做"知识转移"：让运维团队学会新系统的管理操作、故障排查、日常维护。

知识转移一般通过几种方式：厂商提供培训（现场或者远程）、提供详细的管理手册和操作视频、安排一段时间的驻场支持（有问题可以现场问）。我一般会建议客户：培训不要只安排一次，因为一次培训大家吸收不了那么多内容。最好能分几次，每次讲一部分，而且要有"实操环节"——光听讲课没用，要上手操作才能学会。

另外一个建议是：新系统上线后的头三个月，要保留旧系统的运行环境（哪怕只是测试环境），万一新系统有解决不了的问题，还能临时切回旧系统救急。

老旧系统升级改造，技术难度不是最大的，项目管理难度才是最大的。要协调的部门多、要测试的功能点细、要准备的预案全。但反过来想，能把升级改造项目做好，对后续系统稳定运行的好处是长期的。我一般会跟客户说：升级改造这次麻烦一点，后面三五年就省心了；如果这次图省事，后面可能要更频繁地升级。