The campus network WiFi network billing system took seven or eight years, and it was necessary to change. The reason is usually multiple systems: old system manufacturers no longer maintain, hardware has been out of production and spare parts are not available, new compliance requirements (e.g. IPv6 support, new real name certification code) are not realized."Relocation Project". The migration sounds simple, but it's actually much more complicated than a new deployment because you have to complete system replacement without disrupting the existing user services.
Most vulnerable to neglect prior to relocation
Most of the relocation projects were initiated with the attention of both procurement and IT departments"What are the features of the new system?"Above, and without a more fundamental question: what data are available in the old system, what needs to be migrated and what can not be relocated?
The campus network billing system usually contains several types of data: user accounts (school/work numbers, passwords, roles), billing records (historical traffic, balances, bills), web logs (certification logs, IP distribution logs), device configurations (AP information, AC connections, VLAN configuration). The difficulty and necessity of moving these four categories of data is quite different.
User accounts must be migrated basically because otherwise each user will have to re-register or re-mix, and the centralized migration during the start of school season will generate a huge amount of support requests. The billing records also need to move if the school has a historical account query (e.g. a student's toll on a network requires checking of history records); they can be archived instead of real time if the historical transaction is closed without searching.——You can either keep read-only queries on the old system or export archive storage. The device configuration cannot normally be migrated directly, as the new system may be configured in a completely different configuration format.
This data inventory is best done before the contract is signed, not after the project starts. Because the amount and quality of data will have a direct impact on the migration schedule. I've seen one case where schools think they use user account numbers."It's neat.", when the migration engineer gets the data export file, it is discovered that there are a large number of duplicate accounts (the same school number was registered three or four times), a significant number of outgoing students (not written off in time), and cellular numbers for some accounts are overwritten (e.g.,"11111111111") The data cleansing alone took two weeks.
Migration window selection
The network cannot be moved at any time.
This is the ideal migration window, with low network traffic, few user complaints, and problems that can be addressed slowly. Note that summer holidays also have summer students, teaching staff, logistics personnel, and they are using a network and cannot be completely out of service.
If a relocation takes only a short break (2-4 hours), the window can be selected for implementation during the semester, reducing its impact on normal school terms. But the risk is that if an accident occurs, the interruption exceeds expectations and there are limited human resources to deal with problems in the morning.
In general, large-scale migration (which involves the suspension of the entire certification service) is the preferred summer break; small-scale configuration switching (e.g. only for the front end of Portal) allows for early morning windows to be selected. Do not migrate during school seasons, final examination weeks or classes, and any interruption in these periods will be magnified indefinitely.
Management of parallel periods
Migration is not a"One cut."The move is maturely accompanied by a parallel operating period: both old and new systems are online, with a small number of users (e.g. students in a residential building) being relocated to the new system, operational observations are observed, no problems are encountered before expanding their scope gradually and eventually fully switching.
The management of the parallel running period takes several points into account. First, double-entry: where does the user ' s authentication logs write during the parallel? If the old and new systems are written separately, subsequent compliance queries will be cumbersome; preferably in the new system, while synchronizing the new system logs to a single repository. Second, account synchronization: if there is a new enrolment or a user has changed password during the parallel period, these changes are synchronized to two systems, otherwise discrepancies between accounts occur when switching. Third, rollback pres: if there is a serious problem with the new system at one point, it must quickly roll back to the older system. The rollback process is written and rehearsed before the migration, and cannot wait until it needs to be rolled back.
No acceptance after migration
Many of the migration projects are receiving and inspection"Students can access the Internet, the system can log in."This acceptance is too shallow to bury a lot of hazards.
The migration acceptance should cover several dimensions: functional acceptance (a certification method, bandwidth strategy, time-time control etc.) as expected; performance inspection (a response time and success rate met in close proximity to peaks); compliance inspection (real name authentication chain complete, log in writing and format correctly), data migration receiving (sampled verification of user account number integrity after migration and history logs available).
The last is particularly vulnerable to being ignored: whether historical data on the old system should be checked for admissibility or not. Where can you find a copy of the authentication record six months ago if public security checks are required?
The ultimate goal of the relocation project is not just"Changed the new system."Instead, the new system is allowed to take over all tasks without interruption of service, loss of historical data, and failure to lower compliance levels."No, no.", a qualified migration.