一个学校用了六七年的计费系统，终于决定换新的了。采购谈完了，新系统的合同也签了，然后就是迁移。迁移这件事听起来简单，实际上比重新部署一套新系统麻烦得多——新系统的数据是空的，但老系统里有几年的学生账号、充值记录、套餐订购记录，这些数据怎么搬过去，是整个迁移项目里最容易出问题的环节。

先搞清楚老系统里有什么数据

迁移之前，第一步是把老系统的数据库结构摸清楚。老系统通常不会主动提供数据库文档，要么自己去数据库里看表结构，要么让厂商提供数据字典。如果老厂商已经不在了或者不配合，就只能自己啃。

重点需要确认的数据表包括：账号表（学号、姓名、密码散列值、账号状态）、余额表（当前余额、充值记录）、套餐表（已订购的套餐类型、有效期、已消耗量）、上网记录表（如果要迁移历史日志的话）。

每张表里要特别留意字段类型和编码。老系统有些是GB2312编码，新系统是UTF-8。姓名字段如果直接迁移，少数民族姓名中的特殊字符可能乱码。学号字段如果是varchar但存了数字型学号，要确认两边的长度定义一致，避免前导零被截掉。

密码迁移是个难题

账号密码通常是散列值存储，老系统可能用MD5，新系统可能用更安全的算法。直接把散列值迁移过去，新系统可能不认。

处理方式有两种：一是让新系统兼容老系统的散列格式，验证时先用老格式验证，成功后在后台静默升级为新格式；二是把所有账号的初始密码重置为统一规则（比如学号后六位），迁移完成后统一通知学生修改。

第一种方式对用户无感，但需要新系统厂商配合，有额外开发成本。第二种方式简单粗暴，但会带来一波集中的密码修改需求，客服压力会比较大。学校的管理员要在两者之间选，没有绝对的对错，看学校实际情况和可用资源。

还有一种更麻烦的情况：老系统密码是明文存储的。这种情况下直接迁移密码是不安全的，而且说明老系统的安全性本身就有问题。迁移时应该强制要求所有账号在第一次登录新系统后修改密码，不要把明文密码直接导入新系统。

余额迁移要加校对机制

学生账号里的余额是真实的钱，迁移时出了差错会直接引起投诉甚至纠纷。余额迁移必须加校对机制：迁移完成后，从老系统导出一份所有账号余额的快照，再从新系统里导出一份，两份数据做逐行对比，确认每个账号的余额一致，没有误差。

对比结果里如果有差异，逐条核查原因。常见的差异原因有：数据类型精度问题（老系统存的是两位小数，新系统四位小数，导入时精度丢失）、字段映射错误（老系统的"实时余额"和"冻结余额"是分开存的，迁移时只导了其中一个）、迁移期间有充值操作导致数据变化。

建议在迁移窗口期暂停充值服务，等数据校对通过后再恢复。提前在学校的通知渠道上告知学生，通常提前一到两天发通知就够了。

迁移期间的在线账号处理

迁移通常选在凌晨进行，但凌晨不代表没有账号在线。高校宿舍里，凌晨仍然有大量学生在上网。如果直接切换，在线账号的会话可能在老系统里还存在，但新系统里不认，导致学生在切换后直接断线。

处理方式是在迁移前提前强制所有在线账号下线，或者在切换完成后，新系统扫一遍哪些账号在迁移前是在线状态，把这些账号的会话数据在新系统里初始化，允许它们直接恢复上网而不需要重新认证。不同系统支持的方式不同，切换前要跟新系统厂商确认好方案。

迁移后的验收要有足够的测试周期

迁移完成后的第一天最关键。要安排管理员在现场或者远程盯着，关注认证失败率、充值异常、余额显示错误等问题，发现了立即处理。这个时候还在测试阶段，哪怕有问题回滚代价也比较小；等过了两三天学生大量使用之后再出问题，回滚的代价就很高了。

建议迁移后设置一周的密集观察期，关注指标包括：每日认证失败次数（和迁移前相比有没有明显变化）、充值成功率、客服收到的相关投诉数量。这三个指标如果都在正常范围，说明迁移基本成功。

老系统不要急着下线。建议保留一到两个月的只读访问权限，以便在出现历史数据核查需求时还能查到。等新系统运行稳定、没有明显问题之后，再正式停掉老系统。

迁移完成不是终点，是另一个系统生命周期的开始。把迁移这段经历里遇到的问题记录下来，形成学校的内部迁移经验文档，将来下次换系统时会省掉很多不必要的弯路。