The upgrade of the network is a matter for many property and owners. The original system is slowly running out of work, Wi-Fi-5 is replaced by Wi-Fi6, and the operator line has been upgraded from gigabytes to megaconverts. Once the network is upgraded, the billing system usually changes with them.——The old system may not support new bandwidth, or run away with more data, or cannot match the new authentication. But the migration of a billing system is one of the most problematic links, and it can be lost or cut off if there is some carelessness.
Get the old system data clear before moving.
The first error many projects made in relocating the system was that data structures and historical records of the old system were not sufficiently streamlined and were directly configured from scratch on the new system.
The question is clear: what about the contract that is being performed? A tenant who signed a three-year contract last year, agreeing to an amount of $3,000 per month for 200 M bandwidth, has now migrated to the new system, which can easily be misconfigured only by virtue of an industry description if it is not fully documented in the old system.
Core data that need to be exported from the old system prior to migration include: account information for all online tenants, current binding billing strategies and bandwidth parameters, and data on usage during unbilled periods (this is critical if you switch systems in mid-month, first half of the month must be paid out in the old system, and start charging in the new sector system in the second half of the month), historical arrears records (who have outstanding bills).
If the old system supports data export (CSV or Excel), then it will be able to complete a copy of the data. If the older system does not support export, at least manually record key configuration parameters. Any missing messages can become a problem for the carrier after switching.
Select a low-level business to switch
Everyone knows that, but it's often time-condensed."Next Wednesday, we'll upgrade the network and pay for it on Friday with a new billing system."The time left for relocation testing may be only one and a half days.
Ideally, the migration of the system should be selected for the last days of the month to early next. The reason is simple: the current monthly bill can be completed and closed on the old system by the end of the month, and the new cycle starting from zero in the beginning of next year will have the clearest data boundary.
If time does not allow, at least ensure that all uncollected data on the old system are exported and backed up. The first thing after switching is not a fast-tracking strategy, but rather an initial verification of the integrity of the older data on the new system——We'll keep going.
I have experienced a more vexing migration: A requires a mid-month switch because the service contract of an old system manufacturer is due. The switch has revealed that the traffic statistics unit of the new system is different from the older system (the old system uses MB, but contains eight bytes of head), which leads to an overall high billing level for the month. It takes one week to locate the problem and correct it. If the transition is made at the beginning of the month, the monthly checkout will not be affected at least.
Double-tracking is the most effective means of reducing risk.
If conditions permit, the safest mode of relocation is"Double Track Run": The two old and new billing systems run for a period of time (it is recommended that at least one full billing cycle be completed), with cross-references between the costing results.
By: sending traffic data from Authentication Gateway to both old and new systems (if the gateway supports mirrors or double Radius billing reports), or manually exporting raw flow data from a new system from a portal. The key contrasts include total current monthly traffic, average daily traffic, peak bandwidth, and receivable per tenant.
If the result deviations of both systems are within 5% (the small deviation is normal, given differences in statistical calibre and particle size), you can be assured that the new system will be switched to it. If the deviation exceeds 10%, the reason must be identified for retweeting.
The disadvantage of a two-track operation is that it requires both systems to be maintained, with the workload doubling. But the cost of a two-track operation is worth it compared to the time costs of switching faulty after-repair data, billing and explaining to the tenant.
Particular attention should be paid to changes in authentication modalities
Network upgrades often accompany changes in authentication methods. For example, the original Portal certification (web login) is upgraded to 802.1X authentication (client certificate or account password), or Seamless Authentication (MAC address binding + automatic recertification).
The user identification logic of the system is affected by changes in authentication methods. Portal authenticators enter accounts via Web login, which allows accurate tracking of online time and traffic for each account. 802.1X authenticated users are certified through switch level certifications that may not be recorded in the system if there is a user bypassing authentication (e.g., with a private switch or unauthorized access devices)."Away User"The flow.
When migrating, it needs to be confirmed: how does the billing system recognize and attribute traffic to each user under the new authentication? Does all online traffic have to pass Authentication Gateway? Is there any chance that side traffic could bypass the billing?
There is also a situation where promotions have increased"Visitors ' Network"and"Office network"The system needs to be able to manage both channels simultaneously and to show them separately at the time of the checkout.
Switched list of authentications
I make a list of checks that are used in practice:
First, confirm that all tenants’ accounts are correctly created and the strategy is properly tied in the new system.
Second, confirm that the traffic statistics function is normal for online users. Let several test accounts perform some network operations (browsing pages, downloading files, uploading files) and check whether traffic data are growing in real time and moving correctly at the back of the billing system.
Third, confirm that the billing strategy is executed logically. For example, set a test account number to bind"Exceed Speed"Strategy, let this account flow exceed the threshold to check if it is really speed-bound.
Fourth, check the checkout function is normal. Manually trigger on the new system"Simulate the checkout"Checks whether the generated billing data are reasonable and the format meets financial matching requirements.
Fifth, confirm that interfaces with other systems are normal. If the building has a PMS (Hotel Management System), an Property Management System or a Financial Reimbursing System, these interfaces will be re-validated after migration.
The old system's aftercare.
The new system will be able to run a full billing cycle in a stable way. But do not rush to delete data or turn off services. It is recommended that the old system remain online but read-only, for at least three months. There are two reasons why it may need to be retrieved if tenants have questions about their bills for the previous few months; and if the new system finds problems requiring a retreat, the old system can still be quickly cut back.
The historical data of the old system suggests a complete archive (account number, strategy configuration, history billing, traffic raw data) with secure space. These data are evidence in case of future contract disputes or audit needs.
The move is good and no one will remember it, and bad for everyone. It takes two days to prepare and verify, much more than a couple of months to wipe your ass after.