Cover migration method, device, equipment, medium and product of campus internet-of-things platform

Abstract

The invention relates to the technical field of data processing, and provides a cutover migration method, device, equipment, medium and product of a campus Internet of Things platform, the campus Internet of Things platform comprises a first-level platform, a second-level platform and a plurality of hardware terminals connected with the first-level platform, and the method comprises the following steps: synchronizing service data in the first-level platform to the second-level platform; switching the plurality of hardware terminals from being connected with the first-level platform to being connected with the second-level platform in batches; when the hardware terminal is successfully connected with the secondary platform for the first time, triggering an incremental data synchronization task for the hardware terminal; when the incremental data synchronization task is executed, incremental data which is associated with the hardware terminal and generated after service data synchronization is obtained from the first-level platform, and the incremental data is synchronized to the second-level platform. According to the method, the service data of the first-level platform is synchronized to the second-level platform, and then the incremental data is synchronized, so that the data integrity is guaranteed, the hardware cutover success rate is improved, and no perception of a user in the whole cutover upgrading process can be guaranteed.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to methods, apparatus, equipment, media and products for cutover and migration of campus IoT platforms. Background Technology

[0002] Electronic student ID cards are educational smart hardware devices that add functions such as calling and location tracking to the traditional student ID card. The electronic student ID card platform is a system comprised of software, IoT hardware, and both consumer (C-end) and business (B-end) users.

[0003] Currently, there are two main cutover solutions for electronic student ID platforms. The first involves issuing a prior announcement informing users that the system will cease service on a specified date to avoid generating new data. During the downtime, database migration, program upgrades, and verification testing are carried out sequentially, followed by the launch of the new system and the decommissioning of the old system. The second solution aims to reduce the difficulty of testing the new CRM system by using an Nginx host for specific page routing, redirecting requests to both the old and new system pages based on their type.

[0004] However, these solutions have certain drawbacks. While disabling platform services can reduce cutover complexity and ensure stability, preventing new data input from interfering with the cutover process, it sacrifices platform availability, forcing users to be unable to use the platform for a period of time. This downtime can be quite long, especially during large-scale platform cutovers. Furthermore, for purely software or purely hardware cutovers, depending on the amount and complexity of platform data, completing the entire cutover between the old and new systems can take months or even years. Summary of the Invention

[0005] This application provides a method, apparatus, equipment, medium, and product for the cutover and migration of a campus IoT platform, in order to solve the technical problems in the prior art of low cutover efficiency and long downtime of hardware IoT platforms, which cause inconvenience to users.

[0006] This application provides a cutover and migration method for a campus IoT platform. The campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. The cutover and migration method includes: synchronizing business data from the primary platform to the secondary platform; switching multiple hardware terminals from connecting to the primary platform to connecting to the secondary platform in batches; triggering an incremental data synchronization task for the hardware terminal when it successfully connects to the secondary platform for the first time; and when executing the incremental data synchronization task, obtaining incremental data associated with the hardware terminal generated after the business data synchronization from the primary platform and synchronizing the incremental data to the secondary platform.

[0007] According to the cutover and migration method for a campus IoT platform provided in this application, business data in the primary platform is synchronized to the secondary platform, including: exporting all data from the data tables in the primary platform; setting an auto-incrementing ID start value for the data table corresponding to the primary platform in the secondary platform; wherein the auto-incrementing ID start value is the sum of the maximum ID of the corresponding data table in the primary platform and a preset security interval value; and importing the exported data into the data table of the secondary platform based on the auto-incrementing ID start value.

[0008] According to the cutover and migration method for a campus IoT platform provided in this application, multiple hardware terminals are switched from connecting to a primary platform to connecting to a secondary platform in batches, including: establishing a priority queue based on the preset attributes of the hardware terminals; selecting a set of hardware terminals to be switched from the priority queue based on the real-time status of the hardware terminals; determining the number of hardware terminals to be switched this time based on the historical switchover success rate and the current load; determining the target hardware terminal from the set of hardware terminals to be switched based on the number of hardware terminals, and issuing a switchover command to the target hardware terminal; the switchover command is used to switch the connection of the target hardware terminal from the primary platform to the secondary platform.

[0009] According to the cutover and migration method of a campus IoT platform provided in this application, the preset attributes include the activity level of the hardware terminal, and the real-time status includes the online status of the hardware terminal and / or network quality; after issuing the switching instruction to the target hardware terminal, the method also includes: for hardware terminals that fail to respond to the switching instruction, an exponential backoff strategy is adopted to retry.

[0010] According to the cutover and migration method of the campus IoT platform provided in this application, it further includes: before the hardware terminal successfully connects to the secondary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cutoverdone, the user request is redirected to the secondary platform, and a corresponding operation interface is provided according to the cutover status of the hardware terminal.

[0011] According to the cutover and migration method of the campus IoT platform provided in this application, it further includes: before the hardware terminal successfully connects to the primary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cutoverdone, the user request is redirected to the secondary platform, and an operation interface for the first binding is provided.

[0012] This application also provides a cutover and migration device for a campus IoT platform. The campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. The cutover and migration device for the campus IoT platform includes: a business data synchronization module for synchronizing business data from the primary platform to the secondary platform; a terminal switching module for batch switching multiple hardware terminals from being connected to the primary platform to being connected to the secondary platform; a terminal triggering module for triggering an incremental data synchronization task for the hardware terminal when the hardware terminal successfully connects to the secondary platform for the first time; and an incremental data synchronization module for obtaining incremental data associated with the hardware terminal and generated after the business data synchronization from the primary platform when executing the incremental data synchronization task, and synchronizing the incremental data to the secondary platform.

[0013] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the cutover and migration method of any of the above-described campus IoT platforms.

[0014] This application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the cutover and migration method of the campus IoT platform as described above.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the cutover and migration method for the campus IoT platform as described above.

[0016] This application provides a cutover and migration method, apparatus, equipment, medium, and product for a campus IoT platform. The campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. The cutover and migration method includes: synchronizing business data from the primary platform to the secondary platform; switching multiple hardware terminals from connecting to the primary platform to connecting to the secondary platform in batches; triggering an incremental data synchronization task for the hardware terminal when it successfully connects to the secondary platform for the first time; and, during the execution of the incremental data synchronization task, obtaining incremental data associated with the hardware terminal generated after the business data synchronization from the primary platform and synchronizing the incremental data to the secondary platform. Through this method, this application first synchronizes the business data from the primary platform to the secondary platform, and then synchronizes the incremental data, ensuring data integrity, improving the hardware cutover success rate, and guaranteeing a seamless experience for users throughout the entire cutover and upgrade process. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the cutover and migration method for the campus IoT platform provided in this application embodiment.

[0019] Figure 2 This is a schematic diagram illustrating the process of using the electronic student ID provided in the embodiments of this application.

[0020] Figure 3 This is a schematic diagram of state machine transitions provided in an embodiment of this application.

[0021] Figure 4 This is a schematic diagram of the cutover process for first-level card-binding users provided in the embodiments of this application.

[0022] Figure 5 This is a schematic diagram of the cutover process for a Level 1 user without a card binding, as provided in an embodiment of this application.

[0023] Figure 6 This is a schematic diagram of the secondary platform cutover process provided in the embodiments of this application.

[0024] Figure 7 This is a schematic diagram of the data incremental synchronization processing based on a chain-type business flow processor provided in an embodiment of this application.

[0025] Figure 8 This is a schematic diagram of the service flow processor provided in an embodiment of this application.

[0026] Figure 9 This is a schematic diagram of the cutover and migration device for the campus IoT platform provided in the embodiments of this application.

[0027] Figure 10 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0030] It should be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0031] This application provides a cutover and migration method for a campus IoT platform, which can be applied to electronic student ID card platforms and can specifically solve the following problems: (1) The cutover process does not sacrifice the normal availability of the system, retains the user's old and new entry usage habits, and has corresponding pre-set processing procedures regardless of the user and terminal status, thereby improving the success rate of hardware IoT system cutover.

[0032] It supports gray-scale cutover management of IoT platforms including hardware terminals. While cutting over platform data, it also cuts over smart terminal devices (such as electronic student ID cards) to the new system. The cutover process automatically synchronizes terminal data, reducing the cost of manual intervention.

[0033] Please see Figure 1 , Figure 1 This is a flowchart illustrating the cutover and migration method for the campus IoT platform provided in this application embodiment.

[0034] In this embodiment, the campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. The cutover and migration method of the campus IoT platform may include steps S110 to S140, each step of which is as follows: S110: Synchronize business data from the primary platform to the secondary platform.

[0035] Business data synchronization can be based on data replication technology, such as using the replication function provided by the database management system or a custom data synchronization program.

[0036] Optionally, in the campus IoT platform, the databases of the primary and secondary platforms have the same data structure. During synchronization, the business data tables of the primary platform can be scanned, the data in the tables can be extracted according to certain rules, such as full copying, and then transmitted to the secondary platform via the network, where the data is then inserted into the corresponding database tables of the secondary platform.

[0037] This step ensures that the secondary platform has the same business data foundation as the primary platform before the cutover and migration begins, providing accurate data support for subsequent hardware terminal switching and business processing; subsequently, only incremental data generated after business data synchronization needs to be processed, reducing the workload and complexity of data synchronization and improving the efficiency of the cutover and migration.

[0038] S120: Switches multiple hardware terminals from connecting to the primary platform to connecting to the secondary platform in batches.

[0039] This step is based on hardware terminal management and network connection control technology. Specifically, multiple hardware terminals can be grouped, and each batch of hardware terminals can be processed sequentially according to preset batching rules.

[0040] For each hardware terminal, a connection switching command can be sent to it. After receiving the command, the hardware terminal will disconnect from the network connection with the primary platform and then attempt to connect to the secondary platform.

[0041] Optionally, during the connection process, the secondary platform will authenticate and authorize the hardware terminal to ensure that only legitimate hardware terminals can access the network.

[0042] This step, by switching connections in batches, avoids the instantaneous high load impact on the secondary platform caused by all hardware terminals switching connections simultaneously, reducing the risk of system crash and ensuring the stable operation of the secondary platform.

[0043] S130: When the hardware terminal successfully connects to the secondary platform for the first time, an incremental data synchronization task for the hardware terminal is triggered.

[0044] This step relies on hardware terminal connection status monitoring and task triggering mechanisms. The secondary platform monitors the connection status of hardware terminals in real time. When a hardware terminal successfully connects for the first time, it automatically triggers an incremental data synchronization task. This task is added to the task queue, awaiting subsequent scheduling and execution.

[0045] Based on this, this step ensures that the hardware terminal can obtain the latest incremental data in a timely manner after switching connections, maintaining consistency with the data of the primary platform; timely incremental data synchronization enables the hardware terminal to accurately execute various business operations.

[0046] S140: When performing incremental data synchronization tasks, obtain incremental data associated with hardware terminals that is generated after business data synchronization from the primary platform, and synchronize the incremental data to the secondary platform.

[0047] This step utilizes data change tracking and data transmission technologies. Specifically, the primary platform can track changes to business data in real time and record incremental data generated after business data synchronization.

[0048] When the incremental data synchronization task is executed, the secondary platform sends a request to the primary platform to retrieve incremental data associated with specific hardware terminals. Upon receiving the request, the primary platform filters out the relevant incremental data based on the hardware terminal identifier and transmits it to the secondary platform via the network. After receiving the incremental data, the secondary platform merges it into its local database, thereby achieving the cutover and migration of the campus IoT platform.

[0049] This step ensures the integrity and real-time nature of data related to hardware terminals in the secondary platform, enabling the secondary platform to accurately reflect the latest business status of the campus IoT platform; hardware terminals can carry out business normally on the secondary platform based on the latest data, and the continuity of business will not be affected by data inconsistency.

[0050] The above embodiments of this application provide a cutover and migration method for a campus IoT platform, where the secondary platform possesses the same basic business data as the primary platform. Subsequently, when hardware terminals switch connections and execute incremental data synchronization tasks, they can obtain incremental data generated after business data synchronization from the primary platform and synchronize it to the secondary platform. Multiple hardware terminals are switched from connecting to the primary platform to connecting to the secondary platform in batches, avoiding the system impact and risks that might result from simultaneous switching of all hardware terminals. When a hardware terminal successfully connects to the secondary platform for the first time, an incremental data synchronization task for that hardware terminal is triggered. This mechanism ensures that the hardware terminal can obtain the latest data promptly after switching connections. Since incremental data is generated after business data synchronization, it is crucial for the normal operation and business processing of the hardware terminal.

[0051] The above-described cutover and migration method employs a process of first synchronizing data, then switching hardware terminals in batches, and finally synchronizing incremental data. Each step is carried out systematically and in coordination with the others. This orderly approach avoids chaos and duplication of work, improving the efficiency of the cutover and migration. Compared to traditional one-time cutover and migration methods, this method can complete the campus IoT platform cutover and migration in a shorter time, reducing the impact on campus IoT services and enabling the campus IoT platform to resume normal operation as quickly as possible.

[0052] Through the aforementioned data synchronization and hardware terminal switching methods, the campus IoT platform maintained high stability during the cutover and migration process. Complete data synchronization and timely updates ensured the system could accurately handle various business requests, while batch switching of hardware terminals reduced system load and the likelihood of failures. After the cutover and migration was completed, the secondary platform smoothly took over the business of the primary platform.

[0053] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the process of using the electronic student ID card provided in this application embodiment. Specifically, it may include the following steps: 1. Activate and open an account for the SIM card: First, you need to activate and open an account for the SIM card for your electronic student ID.

[0054] 2. Issuance of electronic student ID terminals: After activating the SIM card, issue electronic student ID terminals to students.

[0055] 3. Binding the SIM card to the electronic student ID platform: Bind the SIM card to the terminal on the electronic student ID platform.

[0056] 4. Associate and bind students with terminal serial numbers: Associate and bind students' personal information with terminal serial numbers on the platform.

[0057] 5. Insert the SIM card into the electronic student ID terminal and turn it on: Insert the SIM card into the electronic student ID terminal and turn it on.

[0058] 6. The terminal initiates a login request to the platform: After the terminal is powered on, it initiates a login request to the platform.

[0059] 7. Successful terminal login and synchronization of platform association configuration: Based on the card binding information, the platform verifies the terminal login. If the verification is successful, the terminal logs in and synchronizes the platform's association configuration.

[0060] 8. Parents can log in to the H5 page to view the information reported by the terminal device: Parents can log in to the H5 page to view the information reported by the terminal device.

[0061] 9. Students can use the electronic student ID terminal for various functions: Students can use the electronic student ID terminal for various functions.

[0062] The electronic student ID platform is a specific application of the aforementioned campus IoT platform. The primary and secondary platforms represent different hierarchical structures within the campus IoT platform. The primary platform is typically the existing, active core platform used for the main data processing and management of campus IoT services. The secondary platform is a newly built platform designed to handle the services migrated from the primary platform. The data and services of the electronic student ID platform will transition from the primary platform to the secondary platform during the migration.

[0063] This application's embodiments can solve the problem of cutover from a primary platform to a secondary platform for electronic student ID cards. When upgrading from an old primary platform to a new secondary platform, in addition to the data cutover of the platform itself, some embodiments may also involve the cutover of student ID card hardware terminals via a long TCP connection to the platform. In this case, this embodiment can achieve mutual adaptation between platform data cutover and connected hardware cutover, reduce manual intervention in the cutover process, improve the success rate of hardware cutover, and ensure that users are completely unaware of the entire cutover and upgrade process.

[0064] In some embodiments, the step of synchronizing business data from a primary platform to a secondary platform may specifically include: Export all data from the data tables in the primary platform; in the secondary platform, set the starting value of the auto-incrementing ID for the data table corresponding to the primary platform; the starting value of the auto-incrementing ID is the sum of the maximum ID of the data table corresponding to the primary platform and the preset security interval value; based on the starting value of the auto-incrementing ID, import the exported data into the data table of the secondary platform.

[0065] As described above, this step-by-step data synchronization method in this embodiment—first exporting data, then setting the auto-incrementing ID start value, and finally importing data—makes the data migration process more orderly and efficient. Compared to some complex data migration methods, this approach is simple to operate, easy to implement, and easy to maintain. Furthermore, by setting the auto-incrementing ID start value, complex ID mapping and conversion during data import can be avoided, further improving migration efficiency.

[0066] Synchronizing business data from the primary platform to the secondary platform can be seen as the initial data synchronization process, as illustrated below: During the initial cutover operation, all data from the primary platform is exported and imported into the secondary platform, including MySQL and MongoDB data.

[0067] To differentiate between newly developed business data and transition data on the secondary platform, the primary key auto-incrementing ID of the MySQL tables on the secondary platform needs to be set to a new number range. This new number range is automatically allocated through an ID migration middleware deployed at the application layer. It obtains and records the maximum ID (max_id_old) of each table on the primary platform by reading database metadata interface 2, and then recalculates and allocates the auto-increment starting value new_auto_increment for the corresponding tables on the secondary platform. Here, new_auto_increment = max_id_old + delta, where delta is a reserved safety interval and must be sufficiently large, such as 10000.

[0068] After the initial allocation of number segments is completed, the middleware provides a continuous ID conflict detection and compensation mechanism: if the primary platform continues to generate data, when the maximum value of the primary platform is close to the starting value of the secondary platform, new_auto_increment, the auto-increment starting value of the primary platform is readjusted to old_auto_increment, where old_auto_increment = the maximum ID of the secondary platform + delta, and then the new auto-increment starting value of the secondary platform is adjusted to old_auto_increment + delta.

[0069] A terminal cutover table is created on the secondary platform to store the cutover status and associated information of terminal devices. Specifically, it includes the basic information fields of the terminal on the primary platform, the cutover status, the cutover success time, the user activity identifier, and the user's most recent active time.

[0070] The terminal database data of the primary platform needs to be exported to the terminal cutover table. The subsequent terminal cutover process can be monitored through this table to determine the success or failure of the terminal cutover, analyze the user activity of the primary platform, and control the cutover progress.

[0071] Please see Figure 3 , Figure 3 This is a schematic diagram of state machine transitions provided in an embodiment of this application.

[0072] Cutover states include Pre-Cutover (initially not cutovered), In-Cutover (cutover in progress), Post-Cutover (cutover successful), and Cutover Failed (cutover failed). The switchover process includes: ①Pre-Cutover to Post-Cutover: After the upgrade command is remotely issued, the secondary platform receives the terminal login command and passes the login verification.

[0073] ②Pre-Cutover to Cutover Failed: After the upgrade command is remotely issued, the secondary platform does not receive the terminal login command within 30 minutes, and / or the secondary platform receives the terminal login command but fails the login verification.

[0074] ③Pre-Cutover to In-Cutover: Users actively choose to upgrade on the upgrade guide page.

[0075] ④ In-Cutover to Post-Cutover: The secondary platform receives the terminal login command and passes the login verification.

[0076] ⑤In-Cutover to Cutover Failed: The secondary platform did not receive a terminal login instruction within 30 minutes, and / or the secondary platform received a terminal login instruction but failed the login verification.

[0077] ⑥ Cutover Failed to Post-Cutover: Remotely issue upgrade commands and perform remote OTA software upgrades. Through these two methods, the secondary platform receives the terminal login command and passes the login verification.

[0078] Among them, the cutover success time is the time when the terminal successfully logs into the secondary platform for the first time through the TCP connection; the user activity identifier and activity time are the time when the parent enters the H5 guide upgrade page through the mobile terminal and is identified as active, and the most recent activity time is recorded.

[0079] In some embodiments, the cutover and migration method for the campus IoT platform further includes: Before the hardware terminal successfully connects to the secondary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cut over, the user request will be redirected to the secondary platform, and the corresponding operation interface will be provided according to the cutover status of the hardware terminal.

[0080] During hardware cutover, users do not need to manually switch platforms; user requests can be automatically redirected to the secondary platform, avoiding inconvenience caused by platform cutover. Simultaneously, a corresponding user interface is provided based on the cutover status, allowing users to clearly understand the cutover progress.

[0081] By redirecting user requests, it is ensured that user service requests can be processed in a timely manner during hardware terminal cutover. Even when the hardware terminal is being cut over from a Level 1 platform to a Level 2 platform, user operations will not be interrupted, guaranteeing the continuity of campus IoT platform services.

[0082] In some embodiments, the cutover and migration method for the campus IoT platform further includes: Before the hardware terminal successfully connects to the primary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cut over, the user request will be redirected to the secondary platform, and the operation interface for the first binding will be provided.

[0083] In this embodiment, the hardware terminal is a new terminal that has not been bound to the campus IoT platform before. At this time, if the system is in a cutover period and the hardware terminal accesses the old primary platform, the system can automatically redirect the user request to the secondary platform, and at the same time provide an initial binding operation interface to guide the user to complete the initial binding with the hardware terminal on the secondary platform and re-establish the association relationship.

[0084] For example, the parent user entry points for the electronic student ID on the primary platform and the secondary platform are different, corresponding to H5 menus on two different official accounts. Parent users need to bind their cards before using the electronic student ID; only after binding can they use it normally. During the transition period, the card binding status and usage habits of each user need to be considered to ensure that regardless of the user entering each entry point, there is a corresponding pre-set redirect process, minimizing the user's perception of the platform upgrade. User card binding status and entry point usage include the following three categories: primary platform card-bound users transition, primary platform unbound users transition, and secondary platform transition.

[0085] Please see Figure 4 , Figure 4 This is a schematic diagram of the cutover process for first-level card-binding users provided in the embodiments of this application.

[0086] ① Cutover for Level 1 Card-Bound Users: For users who have already bound their cards and are logging in to the primary platform, the system checks if the user is a primary platform user to be migrated. If so, the primary platform user requests a route and is directly redirected to the secondary platform. Otherwise, the primary platform page is used.

[0087] The secondary platform determines whether the user's associated terminal has successfully completed the transition. If the transition is successful, the user can use the device normally on the secondary platform page. If the transition is unsuccessful, the user is redirected to an upgrade page with prompts and event tracking. If the user chooses not to upgrade for now, they can be redirected to the primary platform page for normal use. Users who have event tracking here are considered active users and will be given priority for transition processing in the future.

[0088] Users can also choose to upgrade immediately. If the upgrade fails, a page will be provided with contact information for manual support to upgrade, and the user will be redirected to the primary platform for normal use. If the upgrade is successful, the user can use the secondary platform page normally.

[0089] Please see Figure 5 , Figure 5 This is a schematic diagram of the cutover process for a Level 1 user without a card binding, as provided in an embodiment of this application.

[0090] ② Cutover for Level 1 users without linked bank cards: When a user on the primary platform who has not bound a card logs in, the system checks if the user is a primary platform user to be cutoverdone. If so, the primary platform user requests a route and is directly redirected to the secondary platform. If not, the primary platform user binds a card and uses it.

[0091] The secondary platform performs a second card binding check on the user. Users who bind their cards on the secondary platform can use the service on the secondary platform page. If the user does not have card binding information, the secondary platform will perform the card binding operation. Once the card binding is completed, the user can use the service normally. If the user is a newly acquired user on the secondary platform, the platform will identify the user as having already bound their card and redirect them to the user page.

[0092] In addition, the card binding operation also needs to determine whether the entered serial number is the terminal to be cut over. If it is, the card binding is successful; otherwise, a page will be provided with contact information for manual service support upgrades.

[0093] Please see Figure 6 , Figure 6 This is a schematic diagram of the secondary platform cutover process provided in the embodiments of this application.

[0094] ③ Secondary platform cutover: New users can directly bind their cards and use the service on the secondary platform; users who successfully migrated from the primary platform can continue to use the service on the secondary platform; users who failed to migrate from the secondary platform can repeat the above steps to return to the primary platform for normal use.

[0095] Specifically, when a user logs in to the secondary platform, it checks whether a card has been bound. If not, the user binds the card on the secondary platform and uses it on the secondary platform page. If the card has been bound, it further checks whether the device is a terminal to be cutoverdone. If not, the user uses it on the secondary platform page.

[0096] If the terminal is to be cutoverdone, the user will be redirected to an upgrade guide page. If the upgrade is not performed immediately, the user will use the service on the primary platform page. If the upgrade is performed immediately and successfully, the user will use the service on the secondary platform. If the upgrade fails, a page will be provided with contact information for human support.

[0097] In some embodiments, the step of switching multiple hardware terminals from connecting to a primary platform to connecting to a secondary platform in batches may specifically include: A priority queue is established based on the preset attributes of the hardware terminals; a set of hardware terminals to be switched is selected from the priority queue based on the real-time status of the hardware terminals; the number of hardware terminals to be switched this time is determined based on the historical switch success rate and the current load; the target hardware terminal is determined from the set of hardware terminals to be switched based on the number of hardware terminals, and a switch command is issued to the target hardware terminal; the switch command is used to switch the connection of the target hardware terminal from the primary platform to the secondary platform.

[0098] In this embodiment, by establishing a priority queue to prioritize the processing of critical hardware terminals, the continuity of critical services can be ensured. Simultaneously, by filtering hardware terminals to be switched based on real-time status, switching over devices performing critical tasks or exhibiting malfunctions is avoided, reducing the possibility of switchover failures. Combining historical switchover success rates with current load to determine the number of switches allows for the rational allocation of system resources, further improving the switchover success rate.

[0099] Determining the number of switches based on the current load of the secondary platform avoids overloading the secondary platform due to switching too many hardware terminals simultaneously, thus ensuring system stability. Furthermore, filtering target hardware terminals according to priority and status and issuing switches sequentially makes the hardware terminal switching process more orderly. This orderly switching method facilitates monitoring and management by administrators, allowing for timely detection and handling of problems that arise during the switching process.

[0100] In some embodiments, the preset attributes include the activity level of the hardware terminal, and the real-time status includes the online status of the hardware terminal and / or network quality; the steps following the issuance of the handover instruction to the target hardware terminal may further include: For hardware terminals that fail to respond to switching commands, an exponential backoff strategy is used for retrying.

[0101] This embodiment uses activity level as a preset attribute, prioritizing hardware terminals with high activity levels. This ensures that devices with significant impact on business operations complete the switchover as quickly as possible, guaranteeing the continuity of core services on the campus IoT platform. Simultaneously, it filters devices to be switched based on online status and network quality, increasing the likelihood of a successful switchover and reducing switchover failures due to device offlineness or poor network conditions, thus improving overall switchover efficiency.

[0102] It should be noted that during the handover process, the hardware terminal may fail to respond to the handover command due to various reasons, such as network fluctuations or temporary equipment failures. The retry mechanism of the exponential backoff strategy can, to some extent, resolve these temporary problems and increase the chance of a successful handover. Even under unstable network conditions, multiple retries can enable the hardware terminal to successfully connect to the secondary platform, improving the system's fault tolerance and stability.

[0103] The exponential backoff strategy avoids multiple hardware terminals retrying simultaneously, reducing the risk of network congestion. If all failing devices retry immediately, it would cause a sudden surge in network traffic, potentially worsening an already unstable network situation. The exponential backoff strategy, by distributing retry times, allows network resources to be used more efficiently, improving overall network performance.

[0104] For example, the student ID terminal can use a TCP long connection to the student ID platform, and the student ID terminal connected to the first-level platform needs to be cut off to connect to the second-level platform.

[0105] The methods for terminal cutover and upgrade include the following.

[0106] a. Switch the service address by remotely sending a command to the terminal and specify it as the connection address of the secondary platform server.

[0107] b. For remote OTA firmware upgrades, the device must be powered on, connected to the internet, and have a battery level of 50% or higher.

[0108] c. Users can proactively trigger the upgrade by following the on-screen instructions, or they can contact their account manager to assist with a data flash upgrade at a designated location.

[0109] In summary, during hardware terminal cutover, the method of sending instructions to the terminal with the lowest user perception should be prioritized. Since user terminals may be powered off or disconnected from the network, to avoid excessively high failure rates due to covering all terminals at once, the cutover should be performed in batches. A "batch task scheduling" algorithm should be used to optimize the batching strategy for terminal cutover.

[0110] Optionally, the batch task scheduling algorithm is implemented as follows: (1) Priority queue initialization: Predict and classify terminal status, and prioritize terminals based on terminal heartbeat monitoring data, historical behavior command analysis, and active user status identifiers in the terminal cutover table: High-priority terminals, such as those that have interacted with commands for several consecutive days or those with active user identifiers, medium-priority terminals, such as those that have interacted with commands only in the last three months, and low-priority terminals, such as those that have had heartbeats only in the last six months, will be processed later.

[0111] The system first sorts the terminals according to high, medium, and low priorities, forming three independent queues. Within each queue, the terminals are pre-sorted according to their historical command response success rate (descending order), which serves as the basic sequence for batch filtering.

[0112] (2) Real-time status filtering: Add a dynamic network status monitoring module to perform the first round of filtering on high-priority queue terminals.

[0113] Specifically, terminals with good network connectivity (latency <100ms, packet loss rate <1%) and online status are retained to form candidate pool A. If the number of terminals in candidate pool A is less than the single batch limit (e.g., 5000 units), terminals with good network connectivity (latency 100-200ms) and "online status" are added from the high-priority queue to form candidate pool B. The total number of candidate pools A and B shall not exceed 5000 units. If the total number of online terminals in the high-priority queue is less than 5000 units, all online terminals will be included in the current batch, and the remaining quota will not be used for the time being (no cross-priority additions).

[0114] (3) Batch size calibration: make secondary adjustments based on historical data.

[0115] Specifically, if the success rate of the previous batch is ≥95% and the current network load rate is <60%, the current batch size is generated at 100% of the total number of candidates (not exceeding 5000 units); if the success rate of the previous batch is between 90% and 95%, or the network load rate is between 60% and 80%, the size is reduced to 80% of the total number of candidates; if the success rate of the previous batch is <90% or the network load rate is >80%, the size is reduced to 50% of the total number of candidates, and only terminals in candidate pool A are retained.

[0116] (4) Batch generation and triggering: After the above screening is completed, the system generates a batch task order containing the terminal serial number ID, the instruction issuance time window (low-activity nighttime period), and network resource reservation parameters, and sends it to the gateway through the scheduling center. At the same time, terminals that are not selected (such as offline or low network quality) are marked as "to be retried" and added to the next round of screening queue.

[0117] (5) Exponential backoff retry mechanism: For terminals that fail to issue instructions in a single batch (such as those that do not respond after timeout or respond abnormally), they are marked as "retry objects" and included in a dedicated retry queue. An exponential backoff strategy is used to plan the retry time. For example, after the first failure, the retry is delayed by 1 hour, the next one is delayed by 2 hours, and so on, with a maximum of no more than 3 retries. Before each retry, the dynamic network status monitoring module will reassess the terminal's network status and only initiate a retry when the terminal is "online", thereby improving the retry success rate.

[0118] In some embodiments, the incremental data synchronization task is executed through a chained business flow processor, which includes multiple processors in a preset order according to business dependencies. Each processor is used to synchronize a preset type of incremental data from a primary platform.

[0119] Chained business flow processors are a design pattern where data processing is broken down into multiple independent steps, each performed by a separate processor. In the incremental data synchronization scenario of a campus IoT platform, these processors are arranged in a pre-defined order according to business dependencies. Business dependencies mean that there are sequential requirements between different types of incremental data.

[0120] When the incremental data synchronization task starts, the chained business flow processors will sequentially call each processor according to a preset order. Each processor will detect incremental data of the preset type from the primary platform. There are various methods for detecting incremental data, such as timestamp comparison or version number comparison. Taking timestamp comparison as an example, the processor will record the time of the last synchronization, and then look for data in the primary platform's data table whose update time is greater than that timestamp; this data is the incremental data. After finding the incremental data, the processor will synchronize it to the secondary platform.

[0121] Because the entire platform cutover process may not be completed in one go due to terminals being powered off or without network access, the cutover process may need to be repeated multiple times depending on the user's terminal's online status. During this period, when changes occur in the user and behavior data of the primary platform, an incremental update strategy must be adopted to ensure the continuity of user data after the cutover and reduce user perception.

[0122] If each subsequent terminal cutover requires manual synchronization of data for specific terminal users, it will inevitably increase the workload of data cutover and the possibility of errors. To solve this problem, the following is the core method for automatically synchronizing incremental data of terminal users after a successful terminal cutover.

[0123] By monitoring the initial login of a primary platform terminal to the secondary platform, various user, behavior, and log data can be retrieved using the terminal's serial number. When the secondary platform server receives a terminal login request, it determines, based on the terminal cutover monitoring table, that the terminal is a primary platform terminal to be cutoverdone and that the login is successful. An asynchronous thread pool is then used to allocate a separate thread to each terminal. Each thread performs incremental data synchronization processing according to predefined chained business flow processors. Once the terminal completes all chained business processing, the cutover is complete, and the user can resume normal operation.

[0124] Please see Figures 7-8 , Figure 7 This is a schematic diagram of the data incremental synchronization processing based on a chain-type business stream processor provided in an embodiment of this application. Figure 8 This is a schematic diagram of the service flow processor provided in an embodiment of this application.

[0125] First, the terminal logs into the secondary platform and passes login verification. Then, it determines whether it is a terminal to be cutoverdone. If not, it responds with a successful terminal login message; if so, it begins allocating asynchronous processing threads, updating the terminal cutover status, notifying the primary platform Processor, and performing user basic data synchronization (Processor), terminal settings data synchronization (Processors), and user behavior data synchronization (Processors).

[0126] The template method design pattern can be used for business flow processors.

[0127] For example, AbstractProcessor is defined as an abstract class that uniformly implements time consumption monitoring and exception handling. Each custom Processor can inherit from AbstractProcessor and implement the abstract methods to handle business logic.

[0128] Custom Processors prioritize tasks based on business dependencies. For example, user basic data synchronization needs to be completed before settings such as family numbers are set. They are divided into four categories in order: ① Notification Processors (notify the primary platform terminal of successful cutover) - ② User Basic Data Synchronization Processors (retrieve user basic data bound to the primary platform terminal) - ③ Terminal Settings Processors (retrieve primary platform settings such as family number settings, classroom mode settings, scenario mode settings, electronic fence settings, interception mode settings, location frequency settings, etc.) - ④ User Behavior Synchronization Processors (retrieve primary platform data such as call logs, SMS collection records, user location records, alarm records, etc.)

[0129] Each type of processor contains one or more business processors to facilitate decoupling. Each processor specifies its priority according to the above four categories through annotations or configuration files.

[0130] After successful terminal login, the asynchronous thread will process the business flow in a chained manner according to the linked list structure composed of Processor priorities. If the processing fails, the Processor will record the reason for the failure and keep it in the exception queue. The system will automatically decide whether to retry based on the context. Administrators can also view the details of failed tasks through the console and manually trigger retries.

[0131] Optionally, if a network communication problem fails, the process will be retried at exponential intervals; if a business verification process fails, the process will be retried at a fixed threshold; if it is detected that the user terminal data processed by the currently failing Processor has been updated in the secondary platform data, the process will no longer be retried and will be removed from the exception queue.

[0132] The User Basic Information and Behavioral Data Synchronization Processor selects incremental synchronization based on changes to the current cutover terminal and such business data on the primary platform (during the initial data synchronization to the current execution process), reducing network bandwidth usage and server load caused by data synchronization interactions and improving processing efficiency.

[0133] The present application proposes a novel approach to IoT platform cutover by combining device terminal cutover with platform data cutover. By automating hardware terminal cutover, various types of user data are simultaneously transferred, reducing the labor costs associated with manual data migration during the cutover process. During the transition between the old and new systems, a multi-batch cutover method is used without interrupting business services. By implementing traffic diversion measures and switching terminal commands, the perceived abnormal experience for end users when using the business platform and hardware terminals can be reduced, ensuring a smooth transition between the old and new platforms. For campus hardware device cutover, this embodiment improves the success rate by supporting various scenarios.

[0134] In summary, the embodiments of this application have the following technical advantages: Firstly, the entire platform cutover process does not require the prolonged or frequent service interruptions of traditional website platforms, effectively improving system availability during the cutover. By implementing user traffic redirection and business logic tracking, the user experience during the cutover is reduced. Simultaneously, the backend can monitor high-frequency users and prioritize their migration.

[0135] Secondly, this mainly targets the cutover of campus IoT platform systems, which differs from most pure software or pure hardware cutovers. During the cutover process, it is necessary to keep the hardware and platform data consistent and synchronized. Hardware cutover drives user platform data cutover, thereby reducing the cost of each manual data cutover.

[0136] This application also provides a cutover and migration device for a campus IoT platform. The cutover and migration device for a campus IoT platform provided in this application will be described below. The cutover and migration device for a campus IoT platform described below can be referred to in correspondence with the cutover and migration method for a campus IoT platform described above.

[0137] Please see Figure 9 , Figure 9 This is a schematic diagram of the cutover and migration device for a campus IoT platform provided in this embodiment. The campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. In this embodiment, the cutover and migration device for the campus IoT platform may include a service data synchronization module 910, a terminal switching module 920, a terminal triggering module 930, and an incremental data synchronization module 940.

[0138] The business data synchronization module 910 is used to synchronize business data from the primary platform to the secondary platform.

[0139] The terminal switching module 920 is used to switch multiple hardware terminals from connecting to a primary platform to connecting to a secondary platform in batches.

[0140] The terminal triggering module 930 is used to trigger an incremental data synchronization task for the hardware terminal when the hardware terminal successfully connects to the secondary platform for the first time.

[0141] The incremental data synchronization module 940 is used to obtain incremental data associated with the hardware terminal and generated after the business data synchronization from the primary platform when performing incremental data synchronization tasks, and synchronize the incremental data to the secondary platform.

[0142] In some embodiments, the business data synchronization module 910 can be specifically used for: Export all data from the data tables in the primary platform; in the secondary platform, set the starting value of the auto-incrementing ID for the data table corresponding to the primary platform; the starting value of the auto-incrementing ID is the sum of the maximum ID of the data table corresponding to the primary platform and the preset security interval value; based on the starting value of the auto-incrementing ID, import the exported data into the data table of the secondary platform.

[0143] In some embodiments, the terminal switching module 920 may specifically be used for: A priority queue is established based on the preset attributes of the hardware terminals; a set of hardware terminals to be switched is selected from the priority queue based on the real-time status of the hardware terminals; the number of hardware terminals to be switched this time is determined based on the historical switch success rate and the current load; the target hardware terminal is determined from the set of hardware terminals to be switched based on the number of hardware terminals, and a switch command is issued to the target hardware terminal; the switch command is used to switch the connection of the target hardware terminal from the primary platform to the secondary platform.

[0144] In some embodiments, the preset attributes include the activity level of the hardware terminal, and the real-time status includes the online status of the hardware terminal and / or network quality; the terminal switching module 920 can also be used for: For hardware terminals that fail to respond to switching commands, an exponential backoff strategy is used for retrying.

[0145] In some embodiments, the terminal switching module 920 may also be used for: Before the hardware terminal successfully connects to the secondary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cut over, the user request will be redirected to the secondary platform, and the corresponding operation interface will be provided according to the cutover status of the hardware terminal.

[0146] In some embodiments, the terminal switching module 920 may also be used for: Before the hardware terminal successfully connects to the primary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cut over, the user request will be redirected to the secondary platform, and the operation interface for the first binding will be provided.

[0147] On the other hand, this application also provides an electronic device, please refer to... Figure 10 , Figure 10 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application, such as... Figure 10 As shown, the electronic device may include a memory 1020, a processor 1010, and a computer program stored in the memory 1020 and executable on the processor 1010. When the processor 1010 executes the program, it can implement a cutover and migration method for a campus IoT platform. This method may include: Synchronize business data from the primary platform to the secondary platform; switch multiple hardware terminals from connecting to the primary platform to connecting to the secondary platform in batches; trigger an incremental data synchronization task for the hardware terminal when the hardware terminal successfully connects to the secondary platform for the first time; when executing the incremental data synchronization task, obtain the incremental data associated with the hardware terminal generated after the business data synchronization from the primary platform, and synchronize the incremental data to the secondary platform.

[0148] Optionally, the electronic device may further include a communication bus 1030 and a communication interface 1040, wherein the processor 1010, the communication interface 1040, and the memory 1020 communicate with each other through the communication bus 1030. The processor 1010 can call the computer program in the memory 1020 to execute the cutover and migration method of the campus IoT platform provided by the above methods.

[0149] Furthermore, the logical instructions in the aforementioned memory 1020 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0150] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the cutover and migration method for the campus IoT platform provided by the above methods. The steps and principles of the method have been described in detail in the above methods and will not be repeated here.

[0151] In another aspect, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the cutover and migration method for the campus IoT platform provided by the above methods. The steps and principles of the method have been described in detail in the above methods and will not be repeated here.

[0152] Non-transitory computer-readable storage media can be any available medium or data storage device that can be accessed by a processor, including but not limited to magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MOs), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)).

[0153] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0154] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0155] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for cutover and migration of a campus IoT platform, characterized in that, The campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. The cutover and migration method for the campus IoT platform includes: Synchronize the business data in the primary platform to the secondary platform; The multiple hardware terminals were switched from being connected to the primary platform to being connected to the secondary platform in batches. When the hardware terminal successfully connects to the secondary platform for the first time, an incremental data synchronization task is triggered for the hardware terminal. When executing the incremental data synchronization task, incremental data associated with the hardware terminal and generated after the business data synchronization is obtained from the primary platform, and the incremental data is synchronized to the secondary platform.

2. The cutover and migration method for the campus IoT platform according to claim 1, characterized in that, The step of synchronizing business data from the primary platform to the secondary platform includes: Export all data from the data tables in the primary platform; In the secondary platform, an auto-incrementing ID start value is set for the data table corresponding to the primary platform; wherein, the auto-incrementing ID start value is the sum of the maximum ID of the data table corresponding to the primary platform and a preset security interval value; Based on the auto-incrementing ID starting value, the exported data is imported into the data table of the secondary platform.

3. The cutover and migration method for the campus IoT platform according to claim 1, characterized in that, The step of switching the multiple hardware terminals from connecting to the primary platform to connecting to the secondary platform in batches includes: A priority queue is established based on the preset attributes of the hardware terminal; The set of hardware terminals to be switched is selected from the priority queue based on the real-time status of the hardware terminals. Based on historical handover success rates and current load, determine the number of hardware terminals that need to be switched this time; Based on the number of hardware terminals, a target hardware terminal is determined from the set of hardware terminals to be switched, and a switching instruction is issued to the target hardware terminal; the switching instruction is used to switch the connection of the target hardware terminal from the primary platform to the secondary platform.

4. The cutover and migration method for the campus IoT platform according to claim 3, characterized in that, The preset attributes include the activity level of the hardware terminal, and the real-time status includes the online status of the hardware terminal and / or network quality; after issuing the handover command to the target hardware terminal, the process further includes: For hardware terminals that fail to respond to the switching command, an exponential backoff strategy is used for retrying.

5. The cutover and migration method for a campus IoT platform according to any one of claims 1 to 4, characterized in that, Also includes: Before the hardware terminal successfully connects to the secondary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cut over, the user request is redirected to the secondary platform, and a corresponding operation interface is provided according to the cutover status of the hardware terminal.

6. The cutover and migration method for a campus IoT platform according to any one of claims 1 to 4, characterized in that, Also includes: Before the hardware terminal successfully connects to the primary platform for the first time, if the user accesses the primary platform and it is determined that the hardware terminal associated with the user needs to be cut over, the user request is redirected to the secondary platform, and an operation interface for the initial binding is provided.

7. A cutover and migration device for a campus IoT platform, characterized in that, The campus IoT platform includes a primary platform, a secondary platform, and multiple hardware terminals connected to the primary platform. The campus IoT platform cutover and migration device includes: The business data synchronization module is used to synchronize business data from the primary platform to the secondary platform; The terminal switching module is used to switch the multiple hardware terminals from being connected to the primary platform to being connected to the secondary platform in batches. The terminal triggering module is used to trigger an incremental data synchronization task for the hardware terminal when the hardware terminal successfully connects to the secondary platform for the first time. The incremental data synchronization module is used to obtain incremental data associated with the hardware terminal and generated after the business data synchronization from the primary platform when performing the incremental data synchronization task, and synchronize the incremental data to the secondary platform.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the cutover and migration method of the campus IoT platform as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the cutover and migration method of the campus IoT platform as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the cutover and migration method of the campus IoT platform as described in any one of claims 1 to 6.

Images