Network migration method, system, electronic device, storage medium and program product
By employing an AI-based multi-agent collaborative network migration method, the problems of service interruption and potential performance degradation during the migration of traditional networks to SDN networks have been solved. This method enables an automated and reliable network migration process, improving migration efficiency and security.
Patent Information
- Application Number
- CN202611106498.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-24
- Publication Date
- 2026-08-25
AI Technical Summary
When migrating from a traditional network to an SDN network, existing technologies can easily cause service interruptions due to traffic switching. Furthermore, the migrated network can only be verified after the migration is completed, making it difficult to detect potential performance degradation defects in a timely manner, resulting in hidden damage and inefficiency.
An AI-based multi-agent collaborative network migration method is adopted. This method generates a migration plan, establishes a transition tunnel, deploys initial security group policies, and adjusts the traffic switching step size based on performance indicators and policy accuracy to achieve an automated and reliable network migration process.
It automates and improves the reliability of the network migration process, minimizes human intervention, reduces migration risks, ensures business reliability and security, and improves network migration efficiency and security.
Smart Images

Figure CN122640316A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet technology, specifically to network migration methods, systems, electronic devices, storage media, and program products. Background Technology
[0002] As enterprises deepen their digital transformation, they need to migrate their business systems from traditional networks based on technologies such as VLAN (Virtual Local Area Network) and ACL (Access Control List) to SDN (Software-Defined Networking) networks, which offer richer functionality and more flexible management.
[0003] Current methods for migrating traditional networks typically employ a one-time or coarse-scale phased switching approach when switching traffic between the traditional and SDN networks. This makes it difficult to accurately assess the impact of traffic migration, and the instantaneous switching can easily lead to service interruptions. Verification of the migrated network can only be performed after the migration is complete, and verification methods are usually limited to simple network connectivity tests. These methods cannot effectively measure the actual Service Level Objectives (SLOs) of the migrated network, such as application response latency and transaction success rate. Consequently, many potential performance degradation defects in the traditional network only become apparent after the migration, causing hidden damage to services. Summary of the Invention
[0004] This invention provides a network migration method, system, electronic device, storage medium, and program product to solve the problems that traffic switching during the migration of traditional networks can easily lead to service interruptions, and that the migrated network can only be verified after the migration is completed, making it difficult to detect potential performance degradation defects in traditional networks in a timely manner.
[0005] In a first aspect, this application provides a network migration method, the method comprising: Upon receiving a network migration request, obtain network-related information, first configuration information of the network to be migrated, and second configuration information of the target network, and generate a migration plan for the network to be migrated based on the network migration request, network-related information, first configuration information, and second configuration information. A transition tunnel is established between the network to be migrated and the target network, wherein the transition tunnel is used to generate network traffic on the first network interface card corresponding to the target network; An initial security group policy is generated based on the network traffic on the first network interface card (NIC). The initial security group policy is then deployed to the first NIC, and the performance metrics of the target network and the policy accuracy of the initial security group policy are obtained. When the performance indicators are within the preset baseline range and the policy accuracy reaches the corresponding gating threshold in the migration plan, the traffic switching step size is determined according to the preset weight adjustment policy, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. After the network traffic switching for the network to be migrated is completed, clean up the network to be migrated and the transition tunnel, and update the third configuration information for the target network.
[0006] Secondly, this application provides a network migration system, which includes: an orchestrator and multiple intelligent agents; The orchestrator connects to the agents via an event bus and is used to coordinate and control the agents; Multiple intelligent agents are used to perform the network migration method described in the first aspect above or any of its corresponding embodiments.
[0007] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the network migration method described in the first aspect or any corresponding embodiment.
[0008] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to perform the network migration method described in the first aspect or any corresponding embodiment thereof.
[0009] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the network migration method described in the first aspect or any corresponding embodiment thereof.
[0010] This application generates a migration plan for the network to be migrated based on a network migration request, network-related information, first configuration information of the network to be migrated, and second configuration information of the target network. A transition tunnel is established between the network to be migrated and the target network, and network traffic is generated on the first network interface card (NIC) corresponding to the target network. An initial security group policy is generated based on the network traffic, deployed to the first NIC, and the performance metrics of the target network and the policy accuracy of the initial security group policy are obtained. If the performance metrics are within a preset baseline range and the policy accuracy reaches the corresponding threshold in the migration plan, a traffic switching step size is determined according to a preset weight adjustment policy, and network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. After the switch is completed, the network to be migrated and the transition tunnel are cleaned up, and the third configuration information corresponding to the target network is updated. This method solves the problems that traffic switching during traditional network migration easily leads to service interruptions, and that the migrated network can only be verified after migration, making it difficult to detect potential performance degradation defects in the traditional network in a timely manner. This method transforms the network migration process into an automated process measured in days or even hours, minimizing manual intervention throughout the entire process and greatly improving the overall efficiency of network migration. By introducing a series of verification mechanisms, migration risks are minimized. The traffic switching step size is determined based on performance metrics and policy accuracy, enabling the system to anticipate risks before each round of network switching. This ensures that the switching process is dynamically adjusted based on real business feedback, providing ultimate security assurance for the entire process and guaranteeing high business reliability. Furthermore, this method synthesizes entirely new initial security group policies by learning from the network traffic of the first network interface card. This process eliminates potential risks from historically accumulated rules, achieving an endogenous improvement in network security. Attached Figure Description
[0011] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies 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 from these drawings without creative effort.
[0012] Figure 1 This is a flowchart illustrating a network migration method according to an embodiment of this application; Figure 2 This is a general architecture diagram of a network automated migration system based on multi-agent cooperation according to an embodiment of this application; Figure 3 This is a structural block diagram of a network migration system according to an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0013] The technical solutions of the embodiments 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0014] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0015] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0016] Currently, migrating business systems from traditional networks based on technologies such as VLANs and ACLs (Access Control Lists) to more feature-rich and flexible SDN networks mainly relies on manual or semi-automated methods. These methods have the following technical problems: 1. Low automation and inefficiency: Preparatory work before migration, such as application dependency analysis and network policy analysis, heavily relies on manual verification of configurations and traffic logs. This process is cumbersome, time-consuming, and prone to errors. The execution process also often relies on engineers writing and executing numerous temporary scripts, lacking standardization and reusability. 2. Uncontrollable risks and frequent business interruptions: Traditional migration methods typically use one-time switching or coarse batch partitioning, making it difficult to accurately assess the impact of network changes. Due to the lack of special handling for complex business scenarios such as long connections, traffic switching can easily lead to business interruptions. Once a problem occurs, manual rollback operations are required, further prolonging fault recovery time. 3. Insufficient verification, making performance degradation difficult to detect: Post-migration verification methods are often limited to simple network connectivity tests (such as Ping or port probing), failing to effectively measure real-world service level objectives, such as application response latency and transaction success rate. This leads to many potential performance degradation issues only being exposed after migration, causing hidden harm to the business. 4. Migrating security vulnerabilities, missing optimization opportunities: To simplify operations, existing technologies tend to directly migrate outdated, broad, and ambiguous access control list rules from traditional networks to the new SDN environment. This not only brings past security debt into the new environment but also misses valuable opportunities to leverage SDN's fine-grained management capabilities to improve security levels. 5. Difficult auditing and traceability, lack of process transparency: The entire migration process lacks systematic documentation. Decision-making basis, operational steps, verification results, and other information are scattered across emails, meeting minutes, and personal documents. Once problems arise, effective review and accountability are difficult to conduct, and it fails to meet stringent compliance audit requirements.
[0017] In addition, there are currently script-based automated network migration tools and migration tools provided by some cloud service providers. While script-based tools improve the execution efficiency of some operations, they are essentially instruction-based, lacking dynamic environmental awareness, closed-loop feedback, and intelligent decision-making capabilities, and cannot adapt to complex and ever-changing real-world environments. Cloud service provider tools are usually deeply tied to their own platforms, focusing on virtual machine migration, and have limited support for in-depth network-level modifications, policy optimization, and smooth transitions between heterogeneous environments, thus failing to provide the end-to-end, intelligent, and highly secure network migration solution of this invention.
[0018] Based on the above, this application provides a network migration method, which is an AI multi-agent collaborative method for automatically migrating a traditional network to an SDN network. This method first constructs an intelligent system with autonomous planning, environmental awareness, closed-loop execution, continuous monitoring, and automated auditing capabilities. This system can smoothly complete the migration from a traditional network to a modern SDN network with the goals of minimizing service interruption and maximizing security and compliance. By introducing a series of key technological improvements, such as semantic network differential, multimodal dependency graph self-verification, shadow policy hit rate gating, session-aware reversible rerouting, counterfactual decision-making based on digital twins, SLO-aware adaptive switching, bridging tunnel self-shaping, negative example synthesis verification, and auditable evidence packets, this method significantly improves the automation level, security, and reliability of network migration. This method can solve the problems of low automation, uncontrollable risks, insufficient verification, and difficulty in auditing and tracing in existing network migration processes.
[0019] According to an embodiment of this application, a network migration method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, for example, a computer, a server, etc., and although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0020] This embodiment provides a network migration method. Figure 1 This is a flowchart of a network migration method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Upon receiving a network migration request, obtain network-related information, first configuration information of the network to be migrated, and second configuration information of the target network, and generate a migration plan for the network to be migrated based on the network migration request, network-related information, first configuration information, and second configuration information.
[0021] Specifically, the network migration method in this embodiment is executed by a network automated migration system based on multi-agent cooperation, such as... Figure 2As shown, the system includes an orchestrator, agents, and a tool adaptation layer. It also incorporates several core innovative algorithms, such as semantic network scoring algorithms, session-aware routing algorithms, digital twin decision-making algorithms, adaptive weight ramping algorithms, and evidence packet auditing algorithms. The system's data sources include configuration management databases, application performance monitoring, and network monitoring systems. The migration execution process includes identification and planning, transitional environment deployment, connectivity verification, switchover execution, cleanup phase, and archiving auditing. The system adopts an architecture centered on the orchestrator, with multiple highly specialized agents working collaboratively. This architecture decomposes complex migration tasks into independent, manageable sub-tasks, each handled by a different agent, and communicates and coordinates through a unified event bus, forming a complete closed-loop control system. The orchestrator is the central coordination and control unit for the entire migration task but does not directly execute specific network operations.
[0022] Each agent is a functional entity undertaking specific tasks, possessing a certain degree of autonomous decision-making ability, and jointly completing the migration under the coordination of the orchestrator. For example: the planning agent is configured to integrate data from at least one configuration management database (CMDB), application performance monitoring (APM) system, or network monitoring system to construct a multimodal dependency graph representing the dependencies between various IT assets; and to analyze the configuration differences between the source legacy network and the target software-defined network (SDN) to generate a migration plan that includes batch partitioning, execution order, and verification objectives; the policy synthesis agent is configured to synthesize a least privilege security policy suitable for the target SDN network based on actual business traffic learned in the transition environment, and to verify it in shadow mode; the execution agent is configured to perform atomic and idempotent infrastructure operations, including but not limited to mounting / unmounting virtual machine network cards, application security policies, and updating routing tables, according to the migration plan; the security agent is configured to make decisions to roll forward, pause, slow down, or roll back during traffic switching execution based on monitoring of service level objectives (SLOs) and prediction of potential risks.
[0023] Users first submit a network migration request via API (Application Programming Interface) or a graphical interface, defining the scope of virtual machines to be migrated, the target SDN network environment, and the desired Service Level Objectives (SLOs). Upon receiving the request, the Orchestrator activates the Planner Agent.
[0024] The network to be migrated is, for example, a non-SDN network built on basic functions such as VLANs, ACLs, and static routes. The target network is, for example, an SDN network.
[0025] Upon receiving a network migration request, the planning agent acquires network-related information. For example, it actively pulls network-related information from multiple authoritative data sources, such as the enterprise's Configuration Management Database (CMDB), Application Performance Monitoring (APM) system, and network monitoring systems (e.g., the NetFlow analytics platform). This network-related information includes service instances, their virtual machine information in the CMDB, and their IP (Internet Protocol) addresses. The planning agent also acquires the first configuration information of the network to be migrated and the second configuration information of the target network. For example, the first configuration information includes the VLANs and ACLs of the network to be migrated, while the second configuration information includes the VPCs and security group configurations of the target network.
[0026] The planning agent generates a migration plan for the network to be migrated based on the network migration request, network-related information, first configuration information, and second configuration information. For example, the planning agent associates service instances tracked by APM with their virtual machine information and IP addresses in the CMDB, and combines this with real communication records in the network flow logs to construct a "multimodal dependency graph" with multi-source evidence and confidence scores. Simultaneously, it parses the VLAN and ACL configurations of the source network and the VPC and security group design of the target SDN network, executes the "semantic network differential" algorithm, and generates a precise "differential repair list." Finally, based on the topology sorting results of the dependency graph, it performs scientific batch partitioning and integrates all information to generate a structured migration plan file. This file is published to the event bus for approval.
[0027] Step S102: Establish a transition tunnel between the network to be migrated and the target network, wherein the transition tunnel is used to generate network traffic on the first network interface card corresponding to the target network.
[0028] Specifically, after the migration plan is approved manually or automatically by the system, the orchestrator begins executing tasks according to the maintenance window and batch order defined in the plan. For the virtual machines in the current batch, the Executor Agent calls the underlying cloud platform's API to attach a first network interface card (NIC) connected to the target network to each virtual machine, at which point the virtual machine is in a "dual NIC" state. Simultaneously, the Bridge Manager Agent establishes a transition tunnel between the network to be migrated and the target network as needed, such as a VXLAN (Virtual Extensible LAN) overlay network tunnel, ensuring that the dual NIC virtual machines can communicate seamlessly with other resources in both networks. At this time, all service traffic still runs on the second NIC in the network to be migrated. The transition tunnel ensures that dual NIC virtual machines can communicate with resources in both networks simultaneously.
[0029] Step S103: Generate an initial security group policy based on the network traffic on the first network card, deploy the initial security group policy to the first network card, and obtain the performance indicators of the target network and the policy accuracy of the initial security group policy.
[0030] Specifically, the Policy Synthesizer Agent begins monitoring network traffic on the first network interface card (NIC). Based on this network traffic, it generates an initial security group policy, for example, learning the network traffic and synthesizing an initial security group (SG) policy that conforms to the principle of least privilege. This initial security group policy is then deployed to the first NIC, for example, in "shadow mode," where it only logs matches without actually blocking traffic.
[0031] An initial security group policy might be a whitelist of rules that only allow necessary communication. The process of generating this initial security group policy produces just the right amount of policy, effectively cleaning up and optimizing existing, broad, and useless rules.
[0032] Obtain the target network's performance metrics and the policy accuracy of the initial security group policy. Performance metrics include SLO metrics (such as application response time RTT), and policy accuracy includes the hit rate (match_rate) and false block rate (false_block_rate) of the initial security group policy for legitimate service traffic.
[0033] Step S104: When the performance indicators are within the preset baseline range and the policy accuracy reaches the corresponding gating threshold in the migration plan, determine the traffic switching step size according to the preset weight adjustment policy, and switch the network traffic corresponding to the network to be migrated to the target network according to the traffic switching step size.
[0034] Specifically, the preset baseline range is, for example, an application response time (RTT) of less than 0.1 seconds, and the corresponding gating thresholds in the migration plan are, for example, a hit rate of more than 98% and a false interception rate of less than 1%.
[0035] Once performance metrics are within the preset baseline and policy accuracy reaches the corresponding gating threshold in the migration plan, the core traffic switching phase begins. The orchestrator instructs the Safeguard Agent and the Executor Agent to work collaboratively. The switching is not completed in one step, but rather employs an SLO-aware adaptive weighted ramping method.
[0036] The system determines the traffic switching step size based on a preset weight adjustment strategy and switches the network traffic corresponding to the network to be migrated to the target network according to the traffic switching step size. For example: First, the security agent performs a counterfactual assessment based on its digital twin model to predict the risks that an initial, small traffic switching step size (e.g., 10%) may bring. If the risk score is lower than the threshold, the execution agent redirects 10% of new connections to the first network interface card of the SDN at the virtual machine kernel level through session-aware reversible rerouting technology, while existing long connections remain on the second network interface card until they terminate naturally. The system enters a short "cooling-off observation period" during which the verification agent closely monitors changes in SLO. After the observation period ends, the security agent reassesses: if the SLO is stable and the risk of the next incremental counterfactual assessment is low, the switching step size is dynamically increased; if the SLO deteriorates, the step size is decreased or the switching is paused. If the SLO deteriorates severely, the security agent will immediately issue a rollback command, and the execution agent will use a pre-stored "rollback token" to restore the routing table to its pre-switching state, achieving second-level service recovery. This "application-observation-evaluation-decision" cycle repeats continuously until 100% of the traffic is smoothly and securely switched to the first network card.
[0037] Step S105: After the network traffic switching for the network to be migrated is completed, clean up the network to be migrated and the transition tunnel, and update the third configuration information for the target network.
[0038] Specifically, after the network traffic switching for the network to be migrated is complete, the orchestrator can wait for the target network to stabilize for a period of time (e.g., 24 hours) before initiating the cleanup process. This cleanup process cleans the network to be migrated and the transition tunnel, and updates the third-party configuration information for the target network. For example, the execution agent unloads the network interface card (NIC) connecting the virtual machine to the network to be migrated, and the bridge manager agent dismantles the temporary tunnel established for this migration. The execution agent also triggers operations such as ARP cache refresh to ensure eventual consistency of the network state and notifies the CMDB to update asset information. The third-party configuration information includes, for example, the ARP cache and asset information for the target network.
[0039] The network migration method provided in this embodiment generates a migration plan for the network to be migrated based on a network migration request, network-related information, first configuration information of the network to be migrated, and second configuration information of the target network. A transition tunnel is established between the network to be migrated and the target network, and network traffic is generated on the first network interface card (NIC) corresponding to the target network. An initial security group policy is generated based on the network traffic, deployed to the first NIC, and the performance metrics of the target network and the policy accuracy of the initial security group policy are obtained. If the performance metrics are within a preset baseline range and the policy accuracy reaches the corresponding threshold in the migration plan, a traffic switching step size is determined according to a preset weight adjustment policy, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. After the switch is completed, the network to be migrated and the transition tunnel are cleaned up, and the third configuration information corresponding to the target network is updated. This method transforms the network migration process into an automated process measured in days or even hours, minimizing manual intervention throughout the process and greatly improving the overall efficiency of network migration. By introducing a series of verification mechanisms, migration risks are minimized. Determining the traffic switching step size based on performance metrics and policy accuracy allows the system to anticipate risks before each round of network switching, ensuring dynamic adjustments based on real business feedback during the switching process. This provides ultimate security assurance for the entire process and guarantees high business reliability. Furthermore, this method synthesizes entirely new initial security group policies by learning from the network traffic of the first network interface card (NIC). This process eliminates potential risks from historically accumulated rules, achieving an endogenous improvement in network security. It also addresses the problems of traffic switching during traditional network migration easily causing service interruptions and the inability to promptly detect potential performance degradation defects in traditional networks, which can only be verified after migration is complete.
[0040] As an optional embodiment, a migration plan for the network to be migrated is generated based on the network migration request, network-related information, first configuration information, and second configuration information, including: Based on the network migration request, obtain the gating threshold; Based on network-related information, service instance information, virtual machine information, address information, and network flow logs are obtained. Based on the service instance information, virtual machine information, address information, and network flow logs, a dependency graph is generated. The first configuration information is compared with the second configuration information, and a differential repair list is obtained based on the comparison results and the semantic network differential algorithm. A migration plan is generated based on the gating threshold, dependency graph, and differential repair list.
[0041] Specifically, when a user submits a network migration request containing the migration scope and advanced policies via API or UI, the Planner Agent obtains the gating thresholds based on the network migration request, such as a hit rate of over 98% and a false interception rate of less than 1%.
[0042] Virtual machine information includes, for example, the virtual machine ID, and address information includes, for example, the virtual machine's IP address. Based on network-related information, service instance, virtual machine information, address information, and network flow logs are obtained. For example, data is pulled from multiple sources such as CMDB, APM, and network monitoring. Through data correlation analysis, the service instance ID in APM is associated with the virtual machine ID in CMDB, constructing the aforementioned "multimodal dependency graph." This graph not only shows "who calls whom" but also quantifies the confidence level of the dependency.
[0043] The planning agent performs semantic network differential analysis: comparing the configurations of the network to be migrated and the target network, a "differential repair list" is generated. This involves comparing the first configuration information with the second configuration information, and based on the comparison results and the semantic network differential algorithm, obtaining the differential repair list. The differential repair list explicitly indicates the subnets that need to be created, the routing policies that need to be adjusted, and the ACL rules that need to be transformed.
[0044] Based on gating thresholds, dependency graphs, and differential repair lists, a migration plan is generated. For example, topology sorting is performed based on the dependency graph to group interdependent virtual machines into the same or adjacent migration batches, avoiding service interruptions due to improper migration order. Combining semantic differential results, gating thresholds, and user-defined policies, a detailed and executable migration plan file is generated, including batches, checkpoints, and verification targets.
[0045] A migration plan is far more than just a list of virtual machines. It's a comprehensive, declarative execution blueprint that includes detailed batch partitioning, execution order, self-verifying dependencies, precise SLO targets, pre-defined rollback checkpoints, and initial policy recommendations based on environment analysis (such as traffic switching modes and bridging schemes). For example, this embodiment uses a declarative domain-specific language (DSL) to define migration tasks, enabling users to clearly express migration intentions, strategies, and constraints. Based on this, the migration plan might look like this: yaml plan_id: mp-2025-08-31-001 policy: Service level targets serve as a benchmark for validation and adaptive switching. slo_targets: { rtt_ms: 50, loss_pct: 0.5, http_5xx: 0.2} Entry barriers for shadow security strategies shadow_sg_gate: { match_rate_min: 0.98, false_block_max: 0.005} Traffic switching strategy cutover: mode: adaptive `adaptive` mode represents adaptive climbing, `fixed` mode represents fixed step size. min_step: 10 Minimum switching step size (percentage) max_step: 35 Maximum switching step size (percentage) cool_down: 120-second cooldown observation period after each switch. bridge: Transitional bridging mode mode: vxlan Service quality control qos: { max_mbps: 800, mtu_auto: true} Virtual machine migration batch definition vm_batches: - name: batch-1 This batch of maintenance windows window: 2025-09-01T02:00:00Z / 2025-09-01T05:00:00Z vms: - vm_id: i-001 target_subnet: subnet - a target SDN network subnet keep_ip: false Whether to retain the original IP address Connectivity verification target verify_targets: - { type: tcp, host: db.internal, port: 3306} - { type: icmp, host: api.internal} Preset rollback checkpoints checkpoints: [ after-attach-nic, after-sec-apply, before-cutover ] Exception handling strategy exceptions: on_sg_block: { widen_rules: true} If the security group blocks incorrectly, try to relax the rules. on_ip_conflict: { auto_remap: true} If there is an IP conflict, automatically reassign IPs. `on_long_conn: { drain_grace: 300s}` grants a 300-second grace period for draining long-lived connections. on_arp_stale: { refresh_neighbor: true} If the neighbor cache expires, actively refresh it. This DSL structure makes complex migration strategies explicit and structured, enabling the AI Agent to accurately parse and execute user intents, while also providing a clear configuration baseline for auditing.
[0046] In this embodiment, a multimodal dependency graph with confidence can be automatically constructed, and an accurate network repair list can be output through semantic differential. Combined with gating thresholds, a standardized DSL migration plan can be generated, which can scientifically divide migration batches, avoid service interruptions, greatly reduce manual sorting, and improve planning efficiency and reliability.
[0047] As an optional embodiment, after switching the network traffic corresponding to the network to be migrated to the target network according to the traffic switching step size, the method further includes: Obtain the switching process data of the network traffic corresponding to the network to be migrated; Generate an evidence package based on the switching process data, dependency graph, migration plan, initial security group policy, and performance metrics. Based on the evidence package, generate a migration summary report and a compliance report.
[0048] Specifically, this embodiment is used for archiving and auditing. After the cleanup phase is completed, the telemetry agent collects data from the entire process of this migration task from planning to completion, such as obtaining the handover process data of the network traffic corresponding to the network to be migrated. Based on the handover process data, dependency graph, migration plan, initial security group policy, and performance indicators, the telemetry agent generates an evidence package. That is, the telemetry agent collects data from the entire process of this migration task from planning to completion and packages it into an independent evidence package that can be used for auditing.
[0049] The telemetry agent can also automatically generate migration summary reports and compliance reports based on the evidence package, quantifying and displaying various acceptance indicators. This provides complete and reliable data support for operational review, management decision-making, and compliance audits.
[0050] The telemetry agent collects all data from the event bus throughout the entire process, including the final migration plan, dependency graph, policy evolution records, SLO monitoring curves, switchover decision logs for each instance, and manual approval records. This data is packaged into an immutable, digitally signed "evidence package" and stored in an archiving system for future auditing, review, and knowledge accumulation. Therefore, the evidence package includes the final migration plan, dependency graph, policy evolution records, SLO monitoring curves, switchover decision logs for each instance, and manual approval records.
[0051] In this application embodiment, comprehensive auditing and compliance capabilities are provided. A unique evidence package mechanism is employed to solidify data throughout the entire migration lifecycle (from planning basis to execution trajectory, verification results, and approval records) into an immutable archive. This provides precise on-site information for post-event review, quantitative decision support for management, and a one-stop, robust chain of evidence for stringent compliance reviews in industries such as finance and healthcare.
[0052] As an optional implementation, a dependency graph is generated based on service instances, virtual machine information, address information, and network flow logs, including: The service instance, virtual machine information, and address information are matched, and the node information and edge information are obtained based on the matching results. Generate the confidence level of the edge information based on the network flow logs and edge information; Based on node information, edge information, and confidence level, an initial graph is obtained, and the initial graph is topologically sorted to obtain a dependency graph.
[0053] Specifically, the planning agent does not generate a simple list of dependencies, but a weighted directed graph, which serves as the dependency graph.
[0054] The system matches service instances, virtual machine information, and address information, and obtains node information and edge information based on the matching results. For example, the planning agent uses complex association analysis to match service instances, virtual machine information, and address information, and unifies information from different dimensions onto the nodes (representing applications, virtual machines, services, etc.) and edges (representing dependencies) of the graph, obtaining node information and edge information respectively.
[0055] The planning agent employs an evidence-driven and confidence-quantified strategy. Each dependency edge in the dependency graph must be accompanied by an auditable set of evidence and a quantified confidence level. For example, a dependency from a web server to a database might have an evidence set including service attribution records in the CMDB (Content Management Database) and TCP (Transport Control Protocol) connection information in the network flow log. The confidence level is dynamically calculated based on the strength, diversity, and consistency of the evidence. This fundamentally changes the unreliable model of relying on manual interviews and guesswork to sort out dependencies. Based on network flow logs and edge information, the confidence level of the edge information is generated. For example, information such as service attribution records in the CMDB and TCP connection information in the network flow log is obtained, and different dependencies, such as a dependency from a web server to a database, are determined based on the edge information.
[0056] By integrating the node information, edge information, and confidence levels described above, an initial graph is obtained. This initial graph is then topologically sorted to obtain a dependency graph. Ultimately, the dependency graph forms the basis for all subsequent planning. By topologically sorting it, the agent can scientifically group interdependent virtual machines into the same or adjacent migration batches, thus preventing service interruptions caused by improper migration order from the outset.
[0057] In this embodiment, a dependency graph with auditable evidence and quantified confidence is generated by integrating multi-source data, replacing manual sorting and eliminating guessing errors; migration batches are scientifically divided through topological sorting to avoid business interruptions caused by disordered migration order from the source.
[0058] As an optional embodiment, the first configuration information is compared with the second configuration information, and a differential repair list is obtained based on the comparison result and the semantic network differential algorithm, including: A first initial graph model is generated based on the first configuration information, and a second initial graph model is generated based on the second configuration information. First semantic labels are applied to the nodes and edges in the first initial graph model to obtain the first graph model; second semantic labels are applied to the nodes and edges in the second initial graph model to obtain the second graph model. Using the semantic network difference algorithm, the differences between the first graph model and the second graph model are identified; A differential repair list is generated based on the difference information. The differential repair list includes at least one of the following: subnet to be created, routing policy to be adjusted, and rule to be converted.
[0059] Specifically, the planning agent uses the "semantic network difference" algorithm, which abstracts the network configuration into a set of semantic attribute graphs.
[0060] The first configuration information is, for example, a snapshot of the network configuration to be converted (routing table, ACL, firewall rules). The second configuration information is, for example, the design document of the target network (subnet definition, routing table, network ACL, security group).
[0061] The planning agent generates a first initial graph model based on the first configuration information and a second initial graph model based on the second configuration information. The two network configurations are then parsed into graph models respectively. Nodes can be hosts, subnets, routing domains, tenants, etc., and edges represent reachability, routing relationships, and allow / deny policies.
[0062] The planning agent assigns first semantic labels to the nodes and edges in the first initial graph model to obtain the first graph model, and assigns second semantic labels to the nodes and edges in the second initial graph model to obtain the second graph model. For example, assigning semantic labels to nodes and edges means that an ACL rule "deny tcp any 10.0.1.5:3306" is labeled as "prohibit any address from accessing the database instance".
[0063] The Semantic Network Differential (SND) algorithm is used to identify differences between the first and second graph models. For example, the SND algorithm searches for the maximum common subgraph between the two graph models and identifies structural and attribute differences. For instance, it might find that "in the source network, the application layer subnet can directly access the database subnet, but in the target SDN network, they belong to different routing domains and need to communicate through specific routing tables and network ACLs." Another example of this difference is that in the network to be migrated, application A and application B can communicate via a Layer 3 switch, but in the new SDN environment, they reside in different VPCs and need to establish peering connections.
[0064] Generate a differential repair list based on the discrepancy information. For example, a structured "differential repair list" such as `{"type":"route_missing","from":"subnet-app","to":"subnet-db"}` or `{"type":"acl_mismatch","rule_id":"rule-123","semantic":"web_to_db_access"}`. This list serves as precise input for subsequent automated operations. The differential repair list precisely identifies at least one of the subnets that need to be created, the routing policies that need to be adjusted, and the ACL rules that need to be transformed, providing accurate and executable input for subsequent policy synthesis and verification.
[0065] In this embodiment, the planning agent abandons the inefficient practice of comparing IP address lists line by line in traditional migration, and instead adopts an innovative semantic network differential algorithm. To achieve a smooth evolution from traditional networks to SDN, a deep understanding of the fundamental differences between the two in terms of network strategy and architecture is essential.
[0066] As an optional embodiment, establishing a transition tunnel between the network to be migrated and the target network includes: A transition tunnel is established between the network to be migrated and the target network, wherein the transition tunnel is used to connect the network to be migrated and the target network into a temporary unified communication domain. Obtain the health parameters of the transition tunnel; If the performance of the transition tunnel is determined to be degraded based on health parameters, the service quality parameters of the transition tunnel shall be adjusted.
[0067] Specifically, the Bridge Manager agent is used for dynamic tunnel management and tunnel self-shaping.
[0068] When performing dynamic tunnel management, the Bridge Manager agent automatically establishes and manages overlay network tunnels, such as VXLAN, between the network to be migrated and the target network to address the isolation issue of new networks to be migrated. These overlay network tunnels serve as transition tunnels. Transition tunnels connect the network to be migrated and the target network into a temporary unified communication domain. This allows virtual machines that have not yet been migrated to seamlessly access virtual machines that have been migrated to the SDN network, and vice versa. It is responsible for creating and destroying tunnels for specific batches of virtual machines according to the migration plan and managing the lifecycle of cloud vendor-specific connectivity services (such as the generalized abstraction of ClassicLink).
[0069] The bridging manager agent performs tunnel self-healing. To ensure the transition tunnel does not become a performance bottleneck, the agent continuously monitors the transition tunnel's health parameters (such as latency, packet loss rate, and bandwidth utilization). Transition tunnel quality of service (QoS) parameters include data transfer rate, maximum transmission unit (MTU), and traffic priority. If health parameters indicate performance degradation or congestion in the transition tunnel, the agent adjusts its QoS parameters, such as dynamic rate limiting, modifying the MTU to reduce fragmentation, and adjusting traffic priority. By adjusting QoS parameters, the transition tunnel self-heals, ensuring service stability during migration.
[0070] In addition, the Bridge Manager agent can also perform L4 proxy deployment. For services highly sensitive to IP address changes, such as databases, or special resources that cannot be directly bridged via tunnels, this agent provides Layer 4 proxy capabilities. It can automatically configure and deploy a proxy service to transparently forward access requests to the network address to be migrated to its new address in the SDN network without the application's awareness, ensuring service continuity.
[0071] In this embodiment, a VXLAN transition tunnel is automatically built to connect the new network to be migrated, enabling bidirectional communication between virtual machines in different batches; health indicators such as tunnel latency and bandwidth are monitored in real time, and service quality parameters are automatically adjusted to self-heal when performance deteriorates, avoiding tunnel bottlenecks and ensuring business stability during migration.
[0072] As an optional embodiment, before determining the traffic switching step size according to a preset weight adjustment strategy, the method further includes: Obtain negative test traffic and inject it into the first network interface card; Determine whether the initial security group policy on the first network interface card blocks negative test traffic; If the initial security group policy blocks negative test traffic, the traffic switching step size is determined according to the preset weight adjustment policy.
[0073] Specifically, after the transition environment deployment is complete, the verification agent begins executing the verify_targets probes defined in the plan and continuously monitors the SLO metrics of real business operations. The calculated "SLO deviation" is continuously published to the event bus. The policy synthesis agent continuously analyzes the logs of the shadow policy and updates metrics such as match_rate (match rate) and false_block_rate (false block rate).
[0074] In addition, the policy synthesis agent performs negative example synthesis tests. The agent acquires negative example test traffic and injects it into the first network interface card (NIC). The verification agent confirms whether this traffic is correctly blocked by the initial security group policy on the first NIC. If the initial security group policy blocks the negative example test traffic, the policy is appropriate, and the system will proceed to the next stage, adjusting the policy according to preset weights to determine the traffic switching step size. Otherwise, the data blocking policy in the initial security group policy needs to be adjusted.
[0075] In this embodiment, a novel security group policy adhering to the "least privilege" principle is synthesized by learning from real business traffic. Furthermore, negative example synthesis testing ensures the robustness of the new policy, achieving an intrinsic improvement in network security.
[0076] As an optional embodiment, the traffic switching step size is determined according to a preset weight adjustment strategy, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size, including: The first risk score is predicted based on the initial switching step size by the security agent. If the first risk score is less than the first preset threshold, the initial switching step size is used as the traffic switching step size, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. Obtain the current and historical service quality metrics for the target network; The flow switching step size is adjusted according to the preset step size to obtain the intermediate switching step size, and the second risk score corresponding to the intermediate switching step size is predicted according to the security intelligent agent. If the difference between the current service quality index and the historical service quality index is less than the second preset threshold, and the second risk score is less than the first preset threshold, the intermediate switching step size is used as the traffic switching step size, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. The process begins by obtaining the current and historical service quality metrics for the target network, and continues until the traffic switching step size equals the third preset threshold, at which point it ends.
[0077] Specifically, the initial switching step size is, for example, 10%, 15%, 20%, or other values. This initial switching step size is input into the safety agent, which predicts the first risk score corresponding to that initial switching step size. The initial switching step size is a small value, and subsequent switching step sizes are gradually increased.
[0078] This embodiment utilizes an SLO-aware adaptive weighted ramping algorithm to replace the traditional fixed step size switching of "20%, 50%, 80%, 100%", thereby achieving closed-loop control based on real system feedback.
[0079] The security agent predicts the first risk score corresponding to the initial handover step size. For example, the security agent uses a lightweight digital twin model to perform counterfactual inference for the initial handover step size. This digital twin model integrates dependency graphs, current SLO status, and resource capacity information. The security agent simulates scenarios such as "what will happen to the system if the traffic of the initial handover step size is switched over next" based on the initial handover step size, and predicts possible counterfactual assessment results, such as service level degradation (predicted_loss) and potential blast radius. Based on the counterfactual assessment results, combined with the current real-time SLO deviation, a comprehensive risk score, i.e., the first risk score, is calculated. The first risk score represents the risk that adopting the initial handover step size may bring.
[0080] The first preset threshold is, for example, 0.6, 0.7, or other values that meet actual needs. If the first risk score is less than the first preset threshold, the initial switching step size is used as the traffic switching step size. Based on this step size, the network traffic corresponding to the network to be migrated is switched to the target network. For example, the executing agent, at the virtual machine kernel level, uses session-aware reversible rerouting technology to redirect newly established connections of the traffic switching step size to the first network interface card (NIC) of the SDN, while existing long-lived connections remain on the second NIC until they terminate naturally.
[0081] Service quality metrics, such as Service Level Requirement (SLO). Obtain the current and historical service quality metrics for the target network. Determine the change in the service quality metric, such as the change in SLO, based on the difference between the current and historical service quality metrics.
[0082] The preset step size is, for example, 10%. The traffic switching step size is adjusted based on the preset step size to obtain the intermediate switching step size. For example, if the traffic switching step size is 10%, and the system state is stable and the predicted risk is low, the traffic switching step size is increased by the preset step size, resulting in an intermediate switching step size of 20%. The second risk score corresponding to the intermediate switching step size is predicted based on the security agent. For example, the same process as predicting the first risk score is used to predict the second risk score corresponding to the intermediate switching step size.
[0083] The second preset threshold is, for example, 2%, 3%, 5%, or other values. If the difference between the current service quality index and the historical service quality index is less than the second preset threshold, and the second risk score is less than the first preset threshold, the intermediate switching step size is used as the traffic switching step size, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size.
[0084] The process begins by obtaining the current and historical service quality metrics for the target network, and continues until the traffic switching step size equals a third preset threshold, at which point it ends. The third preset threshold is, for example, 100%.
[0085] In this embodiment, connectivity checks are no longer limited to the network layer; instead, the application layer's Service Level Objective (SLO) is used as the gold standard for measuring migration success. By continuously monitoring and verifying the SLO of real services throughout the migration process, it is ensured that not only is the network reachable, but more importantly, application performance and user experience are not compromised, thus guaranteeing the final quality of services.
[0086] As an optional embodiment, the second risk score corresponding to the intermediate switching step size predicted by the security agent includes: Based on a preset transfer function, predict the change in service quality indicators corresponding to intermediate handover steps; Based on the dependency graph, identify the affected nodes corresponding to the intermediate switching steps, and determine the system impact range corresponding to the intermediate switching steps based on the affected nodes; Based on the preset resource model, determine the resource reserve corresponding to the intermediate switching step size; The second risk score is obtained based on the change, the scope of system impact, the remaining resources, and the preset weighting function.
[0087] Specifically, the preset transfer function is, for example, the SLO transfer function. The service quality metric is, for example, SLO.
[0088] Input information is generated based on the intermediate switching step size. For example, if the intermediate switching step size is 20%, the input information is that 20% of the traffic will be switched in the next step. This input information is then fed into the security agent.
[0089] The security agent predicts the change in service quality indicators corresponding to intermediate handover steps based on a preset transfer function. For example, based on the SLO transfer function, it predicts how the intermediate handover step will affect the SLO of directly related services and the possible change in SLO.
[0090] Based on the dependency graph, the affected nodes corresponding to the intermediate switching steps are identified, and the system impact range corresponding to the intermediate switching steps is determined based on the affected nodes. For example, a security intelligence can use a weighted dependency graph to identify the nodes that are directly affected; starting from the nodes that are directly affected, it can deduce how the impact will propagate along the dependency chain, thereby calculating the potential blast radius. The blast radius can represent the possible system impact range.
[0091] The default resource model describes the capacity limits of critical components, such as the CPU, memory, and connection limits of virtual machines, as well as the bandwidth and latency thresholds of transitional bridging tunnels. The default resource model is used to determine whether increased traffic will overwhelm system resources.
[0092] The security agent assesses resource availability and determines the resource availability corresponding to the intermediate switching step size based on the preset resource model. For example, the security agent may query the preset resource model to assess whether the capacity of the transition network (such as a bridging tunnel) and the resource availability of key nodes are sufficient to handle the increased traffic, i.e., the resource availability corresponding to the intermediate switching step size.
[0093] Taking into account all factors (the aforementioned changes, the system's impact range, and resource reserves), a quantified comprehensive risk score (risk_score) is calculated using a preset weighting function, serving as the second risk score (e.g., 0.72). The preset weighting function, for example, assigns equal weight to each parameter; for instance, the weight ratio for changes, the system's impact range, and resource reserves is 1:1:1. The factors are then weighted and summed according to this weight to calculate the second risk score. The number of parameters and the weight ratios between different parameters are set according to actual needs.
[0094] In this embodiment, the counterfactual assessment capability based on digital twins enables the system to anticipate risks before execution. By relying on digital twin counterfactual assessment, combined with SLO propagation, dependency graphs, and resource models, multi-dimensional weighted quantification of switching risks allows for early prediction of performance degradation and the scope of fault impact, proactively mitigating migration failures and balancing migration efficiency with business stability.
[0095] As an optional embodiment, after predicting the second risk score corresponding to the intermediate switching step size based on the security agent, the method further includes: If the difference between the current service quality index and the historical service quality index is greater than the fourth preset threshold, or the second risk score is greater than the fifth preset threshold, a target rollback token is determined from a preset number of rollback tokens. The rollback token is generated before the preset operation is executed based on the status snapshot of the target operation corresponding to the preset operation. A rollback instruction is generated based on the target rollback token, wherein the rollback instruction is used to instruct the executing agent to perform a rollback operation on the target network based on the target rollback token.
[0096] Specifically, the execution agent generates a "rollback token," which is a key mechanism for ensuring security. Before performing any critical, state-changing pre-defined operation (such as updating routes or applying security groups), the execution agent first captures a state snapshot of the target of the pre-defined operation (e.g., the complete routing table before the change, security group rule ID), generates a rollback token based on the state snapshot of the target of the pre-defined operation, and associates and records this state snapshot with a unique rollback token.
[0097] During network handover, the verification agent closely monitors changes in SLO. After the observation period, the security agent re-evaluates. A fourth preset threshold is used, for example, 10%, 15%, or other values; a fifth preset threshold is used, for example, 0.9%, 0.95, or other values.
[0098] If the difference between the current service quality index and the historical service quality index is greater than the fourth preset threshold, or the second risk score is greater than the fifth preset threshold, it indicates that the SLO has seriously deteriorated. The security agent needs to immediately issue a rollback command. The execution agent uses the pre-stored "rollback token" to restore the routing table to the state before the switchover, achieving second-level service recovery.
[0099] When a security agent issues a rollback command due to a detected risk, it attaches a "rollback token" to which the rollback should be performed. Upon receiving this token, the execution agent does not need to perform complex judgments; it simply restores the previous state snapshot precisely based on the token, thus achieving a fast and error-free one-click undo.
[0100] The target rollback token is determined from a preset number of rollback tokens. A rollback instruction is generated based on the target rollback token. The rollback instruction instructs the execution agent to perform a rollback operation on the target network based on the target rollback token. For example, the execution agent uses the pre-stored "rollback token" to restore the routing table to the state before the switchover, achieving second-level service recovery.
[0101] In addition, this embodiment adopts a session-aware reversible rerouting algorithm. To address the impact of traditional routing switching on long connections (such as database connections and WebSockets), a refined rerouting mechanism based on kernel data plane programming technology is used. For example, the underlying implementation of this algorithm can be achieved through generalized abstractions such as eBPF (Extended Berkeley Packet Filter).
[0102] A lightweight program is mounted on the virtual machine's network protocol stack to monitor the establishment of TCP / UDP (User Datagram Protocol) sessions. When a new session (uniquely identified by its 5-tuple) is created, its information is recorded in a persistent pinned map and associated with its current outgoing interface (second network interface card).
[0103] During the handover, for sessions already in the mapping, all subsequent packets are forced to be sent through the old interface they are recorded on, i.e., "sticky forwarding," which ensures session continuity.
[0104] For new sessions that do not exist in the mapping, they are sent from the new SDN network interface card according to the updated master routing table in the virtual machine.
[0105] The system monitors sessions with sticky forwarding and removes them from the mapping when a session closes naturally. For sessions that do not close after the preset grace period (drain_grace), a gentle forced interruption can be implemented.
[0106] In the event of a rollback, simply update the primary routing table to point back to the second network interface card (NIC) and clear the kernel mappings. Since the new session is established on the first NIC for a very short time, the impact is minimal, while the old long-lived connection is never interrupted, thus achieving a near-lossless rollback.
[0107] In this application embodiment, the counterfactual assessment capability based on digital twins enables the system to anticipate risks before execution; the SLO-aware adaptive switching algorithm ensures that the switching process is dynamically adjusted according to the actual feedback from the business, avoiding the impact of a one-size-fits-all approach; the session-aware reversible rerouting technology ensures the continuity of long-connection services; and the one-click, precise rollback mechanism provides the final security guarantee for the entire process, ensuring the high reliability of the business.
[0108] As an optional embodiment, adjusting the flow switching step size according to a preset step size to obtain an intermediate switching step size includes: If the first risk score is greater than the first preset threshold, or the difference between the current service quality index and the historical service quality index is greater than the second preset threshold, the intermediate switching step size is obtained by subtracting the preset step size from the traffic switching step size. If the first risk score is less than or equal to the first preset threshold, and the difference between the current service quality index and the historical service quality index is less than or equal to the second preset threshold, the intermediate switching step size is obtained by adding the preset step size to the traffic switching step size.
[0109] Specifically, if the first risk score is greater than the first preset threshold, or the difference between the current service quality index and the historical service quality index is greater than the second preset threshold, it indicates that the predicted risk is too high, or the actual SLO has deteriorated. In this case, the system will reduce the next switching step size and become more conservative. Therefore, the intermediate switching step size is obtained by subtracting the preset step size from the traffic switching step size.
[0110] In addition, a minimum step size can be set. If the step size is switched to the minimum step size in the middle and the first risk score is still greater than the first preset threshold, or the difference between the current service quality index and the historical service quality index is greater than the second preset threshold, the system will trigger an automatic rollback operation.
[0111] If the first risk score is less than or equal to the first preset threshold, and the difference between the current service quality index and the historical service quality index is less than or equal to the second preset threshold, it indicates that the system is stable and the predicted risk is low. The system will then appropriately increase the switching step size to accelerate the migration process more proactively. Therefore, the intermediate switching step size is obtained by adding the traffic switching step size to the preset step size.
[0112] In addition, the increased preset step size is proportional to the system's stability (real_slo_delta), meaning the more stable the system, the larger the preset step size.
[0113] This achieves a dynamic balance between efficiency and safety.
[0114] In this embodiment, a digital twin counterfactual assessment is adopted, which integrates SLO changes, fault impact range, and resource reserves into a multi-dimensional weighted quantification of switching risks. This allows for the early prediction of business degradation and fault propagation, proactive avoidance of migration accidents, and a balance between migration efficiency and business stability.
[0115] As an optional embodiment, the process includes cleaning up the network to be migrated and the transition tunnel, and updating the third configuration information corresponding to the target network, including: Uninstall the second network interface card (NIC) corresponding to the network to be migrated from the virtual machine and remove the transition tunnel; Trigger a cache refresh operation for the target network. The cache refresh operation is used to maintain the consistency of the routing table and domain name system resource records between the network to be migrated and the target network. The routing table and domain name system resource records are contained in the third configuration information. Update the virtual machine's network configuration information for the target network. This network configuration information is included in the third configuration information.
[0116] Specifically, during the cleanup and final state confirmation phase, the orchestrator initiates the cleanup process.
[0117] The execution agent unloads the network interface card (NIC) connecting the virtual machine to the network to be migrated, while the bridge manager agent dismantles the temporary tunnel established for this migration. The execution agent also triggers operations such as ARP cache refresh to ensure eventual consistency of the network state and notifies the CMDB to update asset information.
[0118] The execution agent unloads the second network interface card (NIC) from the virtual machine to connect to the legacy network. The bridging manager agent dismantles any temporary tunnels or connections established for this migration. The execution agent triggers a refresh of neighbor protocol (such as ARP) caches and ensures eventual consistency of routing tables and DNS records. The CMDB is notified to update the virtual machine's network configuration information. Finally, the migration is complete, and the system reaches its target final state.
[0119] This embodiment also provides a network migration system for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the systems described in the following embodiments are preferably implemented in software, hardware implementations, or a combination of software and hardware, are also possible and contemplated.
[0120] This embodiment provides a network migration system, such as Figure 3 As shown, it includes: an orchestrator and multiple intelligent agents; The orchestrator connects to the agents via an event bus and is used to coordinate and control the agents; Multiple intelligent agents are used to perform the above steps S101 to S105, as well as the network migration method in any embodiment.
[0121] Specifically, the orchestrator is the central coordination and control unit for the entire migration task, but it does not directly execute specific network operations. Its core responsibilities include: task state machine management, approval gate, concurrency and window control, event bus, metric aggregation, and global view.
[0122] Task state machine management includes maintaining the lifecycle state of each migration plan, such as "Planning," "Deploying Transition Environment," "Verifying," "Switching," "Cleanup," "Completed," "Failed," and "Rollback." State transitions are driven by the execution results of each agent or external approval events. Approval gating includes setting pause points at key process nodes (such as "Start Switching" and "Execute Cleanup") and interfacing with external work order systems or manual approval platforms. The task process can only continue after receiving a clear approval signal, ensuring the compliance and controllability of the change operation. Concurrency and window control include precisely controlling the task start time and the number of virtual machine batches executed simultaneously based on the maintenance window and parallelism parameters defined in the migration plan, avoiding changes during peak business periods or impacting the underlying infrastructure due to excessive instantaneous changes. The event bus serves as the communication hub between agents, employing a highly reliable message queue (such as one based on Kafka or similar technologies) or a structured log stream (JSONL) mechanism. All agent behaviors, discoveries, decisions, and results are published to the bus as events, allowing other agents to subscribe and respond, and providing a complete record of the entire chain for subsequent auditing.
[0123] The metrics aggregation and global view are used to subscribe to and aggregate Key Performance Indicators (KPIs) and Service Level Objectives (SLOs) data generated by telemetry agents. KPIs primarily measure the efficiency and quality of the migration process itself, such as "average migration time for a single virtual machine" or "first-time success rate of migration tasks." SLOs, on the other hand, are quantitative commitments to the quality of service experienced by end users and serve as the gold standard for judging whether business operations are impaired; examples include "response latency for core transaction applications must not exceed 100 milliseconds" or "network packet loss rate for database services must be below 0.01%." By aggregating these two types of core data, the system forms a global health view of migration tasks, providing data support for manual monitoring and high-level decision-making.
[0124] Multiple agents, such as: policy synthesis agent, bridge manager agent, execution agent, verification agent, security agent, and telemetry agent.
[0125] The core objective of the policy synthesis agent is to adapt and upgrade implicit or explicit access control policies in the network environment to be migrated to explicit, precise, and rigorously validated "least privilege" security group (SG) policies in the SDN network environment. The policy synthesis agent must ensure that after migration, all legitimate business access is maintained (those that were previously accessible must remain accessible), while blocking all unintended access (those that should not have been accessible must be blocked).
[0126] The workflow of the policy synthesis agent includes: During the transition deployment phase, it monitors the actual, legitimate service traffic connected to the first network interface card (NIC) of the SDN. Based on the learned real traffic, it generates a set of "whitelist"-style security group rules that only allow necessary communication. The policy synthesis agent uses shadow policies to evaluate the correctness of the security group rules. By analyzing shadow logs, it ensures that the security group rules have a high hit rate—all "legitimate access" is correctly covered by the new policy, ensuring service connectivity—and a low false positive rate—no "legitimate access" is wrongly denied by the new policy, avoiding service interruption. The policy synthesis agent performs negative example synthesis tests, actively injecting "illegal access" traffic and verifying that this traffic is indeed marked as "denied" by the new policy (in the logs). This ensures that the new policy is not too lenient and can effectively resist unexpected access. Only when various indicators (such as match_rate_min, the minimum match rate threshold) reach preset thresholds, proving that the new policy can perfectly and securely meet the service's access control requirements, will the agent send a "permit switch" signal to the orchestrator.
[0127] The core responsibility of the Bridge Manager agent is to provide a temporary "bridge" for virtual machines in a "semi-migrated" state (i.e., simultaneously possessing two network cards connecting the network to be migrated and the target network) during the migration process. This ensures that the service link between the two networks is not interrupted due to network inconsistencies when some virtual machines have already migrated to the target network while others remain on the network to be migrated. To achieve this, the Bridge Manager agent performs the following three key tasks: Dynamic tunnel management: To address the isolation issue of the new network to be migrated, the agent automatically establishes and manages overlay network tunnels such as VXLAN, connecting the network to be migrated and the target network into a temporary unified communication domain. This allows virtual machines that have not yet migrated to seamlessly access virtual machines that have migrated to the SDN network, and vice versa. It is responsible for creating and destroying tunnels for specific batches of virtual machines according to the migration plan and managing the lifecycle of cloud vendor-specific connectivity services (such as the generalized abstraction of ClassicLink). Tunnel self-shaping: To ensure that this temporary "highway" does not become a performance bottleneck, the agent continuously monitors the health status of the transition tunnel (such as latency, packet loss, and bandwidth utilization). Once congestion or performance degradation is detected, it self-heals by automatically adjusting Quality of Service (QoS) parameters (such as dynamic rate limiting, modifying MTU to reduce fragmentation, and adjusting traffic priorities) to ensure service stability during migration. For L4 proxy deployment, targeting services highly sensitive to IP address changes, such as databases, or special resources that cannot be directly bridged via tunnels, this agent provides Layer 4 proxy capabilities. It can automatically configure and deploy a proxy service, transparently forwarding access requests to the network address to be migrated to its new address in the SDN network without the application's awareness, ensuring service continuity and achieving a smooth transition with the same address.
[0128] The executing agent is responsible for translating all abstract plans into precise, secure, and reversible atomic operations on the underlying infrastructure. It does not make decisions but acts as an executor of instructions from the orchestrator or other agents; its core value lies in the reliability and accuracy of the operations.
[0129] The execution agent interacts with heterogeneous virtualization platforms (KVM, VMware, etc.) and network devices through a unified tool adapter layer, ensuring decoupling between upper-layer logic and lower-layer implementation. All actions of the execution agent strictly adhere to two principles: Atomicity, ensuring that each operation unit (such as "mounting the network card and configuring the IP") either succeeds completely or fails completely and rolls back, leaving no intermediate state and thus avoiding system inconsistencies caused by partial failures; and Idempotency, guaranteeing that the same operation, executed once or multiple times, yields identical results. This allows the system to safely retry in the event of transient network failures or API call timeouts without worrying about duplicate resources or misconfigurations, greatly enhancing the robustness of the migration process.
[0130] The core capabilities and actions of the execution agent include: infrastructure state changes; network interface card (NIC) management: mounting (vm.attach_nic_sdn) and unmounting (vm.detach_nic) virtual machine SDN network NICs, which is the physical basis for building the transition environment and final cleanup; security policy application: precisely applying the least privilege security group (sec.apply_sg) verified by the Policy Synthesizer Agent to the specified virtual machine NIC; fine-grained control of traffic paths; and session-aware route updates, performing the most critical and granular traffic switching action in the entire migration process. It is not simply a matter of switching the default route, but rather implementing "session-aware reversible rerouting" (vm.update_route) at the virtual machine kernel level. This means it can identify and maintain existing long-lived connections on the network to be migrated without breaking them, while guiding new connections to the first network interface card (NIC) of the SDN, achieving a smooth switch with minimal impact on services; local network bridging, when virtual machines are in the dual NIC transition phase, establishes temporary local bridges (bridge.ensure_transit) as needed to ensure that traffic between different NICs within the virtual machine can be forwarded correctly, maintaining service connectivity; system state snapshots and recovery; generating rollback tokens, which is a key mechanism for the execution agent to ensure security. Before performing any critical, state-changing operations (such as updating routes or applying security groups), it first captures a "state snapshot" of the current operation target (e.g., the complete routing table and security group rule ID before the change), and associates and records this snapshot with a unique "rollback token"; performing precise rollback, when the Safeguard Agent issues a rollback command due to detected risk, it attaches the "rollback token" to which it needs to roll back. After receiving this token, the execution agent does not need to perform complex judgments, but only needs to accurately restore the previous state snapshot based on the token, thereby achieving fast, error-free one-click undo.
[0131] The verification agent continuously verifies network connectivity and quality of service (QoS) at each stage of the migration. The verification agent's tasks include: proactive probing, periodically initiating Internet Control Message Protocol (ICMP) and TCP port probes based on the `verify_targets` defined in the migration plan to confirm basic connectivity; passive monitoring, interfacing with the APM system and underlying network monitoring to obtain SLO metrics for real-world business traffic, such as application response time (RTT) and network packet loss rate; SLO deviation calculation, comparing the real-time monitored SLO metrics with the SLO targets (slo_targets) defined in the plan to calculate the "SLO deviation." This deviation value is a key input driving adaptive switching and rollback decisions; and negative example verification, working with the policy synthesis agent to confirm whether negative example test traffic is blocked as expected during the verification phase.
[0132] The security agent is responsible for making decisions that best promote system stability in the event of anomalies. The agent's tasks include: Counterfactual assessment: Before performing traffic switching, a lightweight digital twin model is used to perform counterfactual inferences. This model integrates dependency graphs, current SLO status, and resource capacity information. The security agent simulates scenarios such as "what will happen if 20% of traffic is switched over next," predicting potential service level degradation (predicted_loss) and potential blast radius (blast_radius). Risk scoring: Based on the counterfactual assessment results and the current real-time SLO deviation, a comprehensive risk score is calculated. Roll-forward / rollback decision: When the risk score exceeds a threshold or the SLO deviation deteriorates significantly, the security agent makes a decision. Unlike traditional single rollback solutions, it selects the optimal strategy based on the risk assessment: Rollback: If the risk is too high, a rollback token generated by the execution agent is immediately used to restore the system to the previous stable checkpoint. Roll-forward: If the assessment determines that the current problem is temporary or can be resolved through adjustments (e.g., temporary network jitter), it may choose to pause, retry, or continue "rolling forward" in smaller steps. Telemetry Agent: The "recorder" of history and auditing. Responsible for collecting, organizing, and archiving all data throughout the migration process, ensuring process traceability and measurable results.
[0133] In addition, the system includes a Tool Adapter Layer. This layer defines a unified, abstract Domain-Specific Language (DSL) interface, such as `vm.inspect`, `sec.apply_sg`, and `bridge.ensure_transit`. For different virtualization platforms (such as private clouds based on KVM, VMware, or Xen) or network devices, simply implementing the corresponding adapter plugin translates these standard commands into platform-specific API calls. This gives the invention excellent platform independence and extensibility.
[0134] The network migration system provided in this embodiment transforms the network migration process into an automated process measured in days or even hours, minimizing manual intervention throughout and significantly improving overall network migration efficiency. By introducing a series of verification mechanisms, migration risks are minimized. The traffic switching step size is determined based on performance indicators and policy accuracy, enabling the system to anticipate risks before each round of network switching. This ensures that the switching process is dynamically adjusted based on real business feedback, providing ultimate security assurance and guaranteeing high business reliability. Furthermore, this method synthesizes entirely new initial security group policies by learning from the network traffic of the first network interface card. This process eliminates potential risks from historically accumulated rules, achieving an endogenous improvement in network security. It solves the problems of traffic switching during traditional network migration easily causing service interruptions and the inability to promptly detect potential performance degradation defects in traditional networks, which can only be verified after migration is complete.
[0135] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0136] In this embodiment, the network migration system is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit), a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.
[0137] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.
[0138] The following is a detailed reference. Figure 4This diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.
[0139] Typically, the following devices can be connected to the I / O interface 405: input devices 406 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 407 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; memory devices 408 including, for example, magnetic tape, hard disk, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.
[0140] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 409, or installed from a memory 408, or installed from a ROM 402. When the computer program is executed by the processor 401, it performs the functions defined in the network migration method of the embodiments of the present invention.
[0141] Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.
[0142] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the network migration method embodiments described above when running.
[0143] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0144] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the network migration method embodiments described above.
[0145] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the network migration method embodiments described above.
[0146] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.
[0147] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0148] The foregoing has provided a detailed description of a network migration method, system, electronic device, storage medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A network migration method, characterized in that, The method includes: Upon receiving a network migration request, the system obtains network-related information, first configuration information of the network to be migrated, and second configuration information of the target network, and generates a migration plan for the network to be migrated based on the network migration request, the network-related information, the first configuration information, and the second configuration information. A transition tunnel is established between the network to be migrated and the target network, wherein the transition tunnel is used to generate network traffic on the first network interface card corresponding to the target network; An initial security group policy is generated based on the network traffic on the first network interface card (NIC), the initial security group policy is deployed to the first NIC, and the performance indicators of the target network and the policy accuracy of the initial security group policy are obtained. When the performance indicators are within the preset baseline range and the policy accuracy reaches the corresponding gating threshold in the migration plan, the traffic switching step size is determined according to the preset weight adjustment policy, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. After the network traffic switching corresponding to the network to be migrated is completed, the network to be migrated and the transition tunnel are cleaned up, and the third configuration information corresponding to the target network is updated.
2. The method according to claim 1, characterized in that, The step of generating a migration plan for the network to be migrated based on the network migration request, the network-related information, the first configuration information, and the second configuration information includes: The gating threshold is obtained based on the network migration request; Based on the network-related information, service instances, virtual machine information, address information, and network flow logs are obtained. Based on the service instances, virtual machine information, address information, and network flow logs, a dependency graph is generated. The first configuration information is compared with the second configuration information, and a differential repair list is obtained based on the comparison results and the semantic network differential algorithm. The migration plan is generated based on the gating threshold, the dependency graph, and the differential repair list.
3. The method according to claim 2, characterized in that, After switching the network traffic corresponding to the network to be migrated to the target network according to the traffic switching step size, the method further includes: Obtain the switching process data of the network traffic corresponding to the network to be migrated; An evidence package is generated based on the switching process data, the dependency graph, the migration plan, the initial security group policy, and the performance metrics. Based on the evidence package, a migration summary report and a compliance report are generated.
4. The method according to claim 2, characterized in that, The step of generating a dependency graph based on the service instance, the virtual machine information, the address information, and the network flow logs includes: The service instance, the virtual machine information, and the address information are matched, and node information and edge information are obtained based on the matching results; Based on the network flow logs and the edge information, generate the confidence level of the edge information; Based on the node information, the edge information, and the confidence level, an initial graph is obtained, and the initial graph is topologically sorted to obtain the dependency graph.
5. The method according to claim 2, characterized in that, The step of comparing the first configuration information with the second configuration information, and obtaining a differential repair list based on the comparison result and the semantic network differential algorithm, includes: A first initial graph model is generated based on the first configuration information, and a second initial graph model is generated based on the second configuration information. First semantic labels are applied to the nodes and edges in the first initial graph model to obtain the first graph model; second semantic labels are applied to the nodes and edges in the second initial graph model to obtain the second graph model. The semantic network difference algorithm is used to identify the differences between the first graph model and the second graph model. The differential repair list is generated based on the difference information, wherein the differential repair list includes at least one of the following: subnet to be created, routing policy to be adjusted, and rule to be converted.
6. The method according to claim 1, characterized in that, Establishing a transition tunnel between the network to be migrated and the target network includes: A transition tunnel is established between the network to be migrated and the target network, wherein the transition tunnel is used to connect the network to be migrated and the target network into a temporary unified communication domain; Obtain the health parameters of the transition tunnel; If the performance of the transition tunnel is determined to be degraded based on the health parameters, the quality of service parameters of the transition tunnel shall be adjusted.
7. The method according to claim 1, characterized in that, Before determining the traffic switching step size according to the preset weight adjustment strategy, the method further includes: Obtain negative test traffic and inject the negative test traffic into the first network interface card; Determine whether the initial security group policy on the first network interface card blocks the negative test traffic; If the initial security group policy blocks the negative test traffic, the traffic switching step size is determined according to the preset weight adjustment policy.
8. The method according to claim 2, characterized in that, The step of determining the traffic switching step size according to a preset weight adjustment strategy, and switching the network traffic corresponding to the network to be migrated to the target network according to the traffic switching step size, includes: The first risk score is predicted based on the initial switching step size by the security agent. If the first risk score is less than the first preset threshold, the initial switching step size is used as the traffic switching step size, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. Obtain the current and historical service quality indicators for the target network; The flow switching step size is adjusted according to the preset step size to obtain the intermediate switching step size, and the second risk score corresponding to the intermediate switching step size is predicted according to the security agent. If the difference between the current service quality indicator and the historical service quality indicator is less than the second preset threshold, and the second risk score is less than the first preset threshold, the intermediate switching step size is used as the traffic switching step size, and the network traffic corresponding to the network to be migrated is switched to the target network according to the traffic switching step size. The subsequent steps begin from obtaining the current and historical service quality indicators corresponding to the target network and continue until the traffic switching step size equals the third preset threshold, at which point the process ends.
9. The method according to claim 8, characterized in that, The step of predicting the second risk score corresponding to the intermediate switching step size based on the security agent includes: Based on a preset transfer function, predict the change in the service quality index corresponding to the intermediate switching step size; Based on the dependency graph, determine the influencing nodes corresponding to the intermediate switching step size, and determine the system influence range corresponding to the intermediate switching step size based on the influencing nodes; Based on the preset resource model, determine the resource reserve corresponding to the intermediate switching step size; The second risk score is obtained based on the change amount, the system's impact range, the resource reserve, and a preset weighting function.
10. The method according to claim 8, characterized in that, After predicting the second risk score corresponding to the intermediate switching step size based on the security agent, the method further includes: If the difference between the current service quality indicator and the historical service quality indicator is greater than the fourth preset threshold, or the second risk score is greater than the fifth preset threshold, a target rollback token is determined from a preset number of rollback tokens, wherein the rollback token is generated based on the state snapshot of the operation target corresponding to the preset operation before the preset operation is executed; A rollback instruction is generated based on the target rollback token, wherein the rollback instruction is used to instruct the executing agent to perform a rollback operation on the target network based on the target rollback token.
11. The method according to claim 8, characterized in that, The step of adjusting the flow switching step size according to a preset step size to obtain an intermediate switching step size includes: If the first risk score is greater than the first preset threshold, or the difference between the current service quality index and the historical service quality index is greater than the second preset threshold, the intermediate switching step size is obtained by subtracting the preset step size from the traffic switching step size. If the first risk score is less than or equal to the first preset threshold, and the difference between the current service quality index and the historical service quality index is less than or equal to the second preset threshold, the intermediate switching step size is obtained by adding the preset step size to the traffic switching step size.
12. The method according to claim 1, characterized in that, The step of cleaning up the network to be migrated and the transition tunnel, and updating the third configuration information corresponding to the target network, includes: Uninstall the second network interface card corresponding to the network to be migrated from the virtual machine, and remove the transition tunnel; Trigger a cache refresh operation for the target network, wherein the cache refresh operation is used to maintain the consistency of the routing table and domain name system resource records between the network to be migrated and the target network, and the routing table and the domain name system resource records are included in the third configuration information; Update the network configuration information of the virtual machine for the target network, wherein the network configuration information is included in the third configuration information.
13. A network migration system, characterized in that, The system includes: an orchestrator and multiple intelligent agents; The orchestrator is connected to the agent via an event bus and is used to coordinate and control the agent. The plurality of said agents are used to perform the network migration method according to any one of claims 1 to 12.
14. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the network migration method according to any one of claims 1 to 12.
15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the network migration method according to any one of claims 1 to 12.
16. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the network migration method according to any one of claims 1 to 12.