The challenge of switching the old campus network to a new Authentication & Billing system is not a matter of magnitude. New projects are planned and implemented, butSwitching means there's an old system running that can't stop.——Students also have to get on the Internet, teachers have to have regular access to school resources, and there are existing certification strategies and billing data that continue. A break of hours may trigger complaints across the school. So the core of smooth migration is not how advanced technology is, but whether transition strategies are sound enough.
The starting point of the migration must beData count for the old system. The new system must be fully and completely exported from all users in the old system before it is online——This step seems simple, and there are at least three kinds of problems in the exercise: data field definitions for the old system do not correspond exactly to the new system.——Some old systems."user_type"Distinguishing between teaching staff and students, new system"user_role", the migration script must be field mapd; second, full-volume output itself takes time——An old system that has been running for five years may have accumulated more than 100,000 user records and millions of billing records; three are old system databases which may have generated dirty data due to prolonged non-maintenance——For example, duplicate user records, failed but uncleaned bindings, and bills with no matching amount. These dirty data cannot be moved directly to the new system, otherwise it will start online with a bunch of historical baggage.
Recommended one round before data migrationData cleansing——To recreate and complete missing fields, tag abnormal data. Some old users have empty cell phone numbers, which are not working properly when they move to the new system, requiring batches to mark them at the time of migration and requesting them to check in for the first time. For example, some older bills do not match actual balances; this cannot be automatically processed; only tags can be manually checked out.
The safest thing about the migration strategy isPhased transition, instead of a one-time switch. Phase 1: new system deployment with data synchronization and functionality validation only——The old system continues to carry all authentication requests, and the new system synchronizes user and bill data from the old system, running all functional modules of the new system at this stage, including Portal certification, meal set, self-service, etc., but traffic is still on the old system. Phase II: selection of a low risk area for piloting——For example, a college or a dormitory building is first cut and the user-certification traffic in this area is completely new. One to two weeks of trial operation, observing whether certification success rates, user complaints, and bill accuracy are met. Phase III: gradually expanding the scope of conversions by region, with two days after each one. Phase IV: full school switching, keeping historical data queries in the old system and not accepting requests for authentication.
Key premises for phased switchingThe old and the new systems must have a parallel running capability for a while.This."Parallel"It's not just a simple simultaneous turn on, but there's a data synchronization mechanism between the two systems.——The authentication records and billing data generated on the old system are synchronized to the new system in real time, ensuring that the new system is complete when it is cut into the main user system. If there is no two-way synchronization between the new and the old system, when the pilot area is cut over, it will be found that only the user data from the pilot area is available in the new system, and there is no history of the entire school, which would cause a breakdown of the reconciliations and financial statements.
And there's a key transition:A terminal side insensitive switch. If a student needs to re-enter the account code or even re-register after the new and old system is switched, it's a bad experience. The new system must be able to inherit the old system's user authentication documents.——For example, the LDAP synchronised the code number or the Hash value of the password for batch import to the old system before it is connected to the new system. The binding relationship between MAC Seamless Authentication also needs to be synchronized.——If the old system already had a large number of students' MAC addresses, but these ties were not moved, and all students would have to re-accredit for the first time after the new system was online, Seamless Authentication would be in vain.
The emergency retirement program is a part of the relocation plan that cannot be omitted.We must keep one key to the old system.The core of the retreat program is at the web level——The RADIUS server configuration on AC points both to the IP address of the new and the old systems, which normally is first (or priority) in place, and then only needs to be adjusted for priority on the AC when switching. In case of a serious malfunction in the new system, the AC configuration rolls back to the pointer system, and recovery time can be contained within minutes.
Finally, a practical question is raised:User communication during migrationIf students and teachers suddenly find that the authentication page has changed without any psychological expectation, the pamphlet for charging and checking is different from before, there will be a lot of unnecessary advice and complaints.——Business micro-mail, campus portal, public number——Notifications issued in advance"The campus network certification system will be upgraded from one month to the next, with possible short-term implications and new operating guidelines". A simple FAQ page and self-help drainage guide are prepared, which will be displayed on Portal.