Legacy Dedicated Lines and VPNs Are Still in Use: How to Connect a Cross-Region Channel First and Migrate Workloads in Batches?

Connecting physical or virtual gateways over existing site broadband to run alongside legacy dedicated lines and firewalls

To bring the new channel online without removing existing dedicated lines or VPNs, we provide access methods matched to on-site conditions at each location to connect headquarters, branch offices, factories, on-premises server rooms, and public clouds:

• Preconfigured physical appliances for offices, factories, and on-premises server rooms: We can ship physical access appliances preconfigured with site information and connection policies to your locations. Once on-site staff plug in power and connect to existing broadband over the public internet, the appliance automatically retrieves its preset configuration to come online, reducing manual debugging at branch sites.
• Virtual gateways for data centre virtualisation and public cloud environments: If your headquarters data centre already has a virtualisation platform or your workloads run on a public cloud, we can deploy our virtual access gateway directly in your existing environment, skipping new hardware procurement and server room cabling; when interfacing with existing encrypted tunnels on your live network is required, IPSec peering with existing gateways is also supported.
• Keep existing primary routers and firewalls: Newly connected physical or virtual appliances can run alongside the routers, firewalls, and legacy dedicated lines already in use without replacing your existing egress gateways at the start of the transition; for critical sites with high availability requirements, dual-appliance backup and multiple transmission paths can also be configured.

When the new channel runs alongside the legacy network, intranet subnet routes and firewall allow rules still need to be configured on the relevant devices—it cannot be assumed that zero configuration changes will be made to the live network. Before connecting, we work with your team or headquarters administrators to confirm the routing entries and access permissions to be adjusted at each site and complete integration during an agreed maintenance window.

Steering traffic to the new channel by designated workload or branch while other systems stay on legacy paths

Once the channel is connected, we steer traffic based on mutually confirmed target subnets, application services, or site scopes, directing only designated cross-region intranet access or outbound public internet requests onto the new channel while unspecified systems continue over legacy dedicated lines or VPNs:

• Migrate daily applications in urgent need of improvement first: For example, first route frequently lagging cross-border video conferences, overseas R&D data transfers, large file exchanges, or newly added cloud applications onto our cross-border transmission channel, while leaving internal systems not yet scheduled for change—such as financial posting or shop-floor scheduling—on the legacy dedicated line until the first batch runs stably.
• Connect individual branches or newly opened offices first: You can start by connecting one or two branch offices experiencing the slowest cross-border access, or let a newly opened office with standard broadband connect back to headquarters and the cloud through our channel first, then roll out progressively to other factories and branches once validated.

When cutting over a workload in batches, administrators on both sides need to coordinate two key items. First, align round-trip routing at both ends: when requests from a branch to a headquarters server are switched to the new channel, return traffic from headquarters to that branch must simultaneously point to the new channel entry so packets do not take the new path outbound and the legacy dedicated line on return, which would cause stateful firewalls along the way to drop them. Second, confirm source IP addresses and allowlist updates: if a target system or external partner restricts source IP addresses, first verify whether the source address changes under the actual forwarding mode once traffic moves to the new channel; if requests exit via the new channel, we can configure an agreed fixed egress IP address according to the solution plan so your team can update the partner's allowlist during the cutover window (the specific egress region, dedicated vs. shared use, and primary/backup failover behaviour are confirmed before signing).

Keeping legacy paths for emergency rollback during transition and scaling sites and bandwidth as workloads grow

As long as legacy dedicated lines or VPNs remain active during the transition period, sites with dual-path capability can retain the legacy line as an agreed emergency rollback/fallback channel. If an internal software parameter needs adjustment during the observation period after a batch of workloads moves onto the new channel, administrators on both sides can follow pre-agreed routing switch steps to point that workload's traffic back to the legacy path (switching paths involves route updates and connection re-establishment, so some active software sessions may require reconnecting or logging in again), and switch back to the new channel once adjustments are complete.

During transitional operation, our network service provides DNS resolution logs and 5-tuple connection logs so you can inspect source and destination addresses, ports, connection start and end timestamps, and upstream and downstream traffic volume to help verify that traffic is taking the new path as planned; whether business documents submit properly and internal permissions and software functions work as expected is confirmed by your users within the actual systems.

As subsequent workload batches and new sites migrate in, if initial channel capacity becomes insufficient, we can scale up service bandwidth on demand based on existing broadband links at each site and regional resources without waiting for physical dedicated line construction, though the maximum speed of each site's local broadband itself remains governed by the local carrier line. Once all workloads have transitioned smoothly onto the new channel, when to decommission legacy dedicated lines or VPNs, how to terminate leases, and how to settle remaining contract fees are handled between your enterprise and the legacy line provider under your respective contracts.