Data Centre Relocation or Cross-Cloud Migration: How to Connect Legacy and New Environments with Office Sites During Transition?

Deploying access across the legacy data centre, new cloud environment, and offices for multi-site transition connectivity

Network requirements during a relocation differ from routine fixed networking: the legacy data centre, the new data centre or cloud region, and active branch offices must all be connected on the same network simultaneously, often under tight schedules to start transferring data without time to wait for long traditional physical dedicated line ordering and construction. We can establish cross-region and cross-border transmission channels directly over existing network conditions at both ends:

At existing on-premises server rooms and regional offices, preconfigured physical appliances can be connected to come online directly over existing broadband on the public internet; if the legacy data centre already has an internal virtualisation environment, a virtual access gateway can also be deployed directly. In the target public cloud region or new data centre virtualisation platform, a virtual access gateway can likewise be deployed directly, or peered with existing cloud gateways via IPSec.

Once the channels are connected, we work with your administrators or migration implementation team to configure static routes, source and destination NAT, and access control rules between the legacy and new intranets while keeping existing broadband and LAN structures at each site intact. We provide network connectivity and traffic steering across these locations; server image migration, primary-replica database replication, account directory synchronisation, and application go-live operations are performed by your technical team or migration vendor.

Bulk data replication phase: dedicated migration paths and temporary bandwidth scaling by cycle

Before formal system cutover, large volumes of historical database backups, business attachments, image files, or object storage data typically need to be copied from the legacy environment to the new environment, followed by continuous synchronisation of incremental data. For intensive transfers during this phase, we provide two direct forms of support:

Steer migration traffic onto a dedicated transmission channel: If data is transferred directly between private IP addresses of the legacy and new data centres or cloud environments, we connect the private networks at both ends via site-to-site networking; if migration tools need to upload data to target public cloud object storage or designated public migration endpoints, we can steer that traffic by target address or service onto our cross-region backbone channel, avoiding frequent transfer interruptions from evening peak congestion on the cross-border public internet while keeping migration traffic separate from daily office internet traffic.

Request temporary channel bandwidth scaling by migration cycle: Based on existing access links at the legacy data centre and target environment as well as available regional resources, we can temporarily scale up service bandwidth by site and usage period so short-term bulk transfer demands do not become permanent ongoing expenses; once the bulk data replication phase ends, capacity is scaled back to match routine usage (the maximum bandwidth of local broadband at each data centre and office remains governed by the local carrier line and is not increased by traffic splitting or channel scaling). Resumable transfers, incremental synchronisation, and data consistency verification between both ends are handled by your chosen replication software or database tools; the DNS resolution logs and 5-tuple connection logs we provide are used to inspect network connections and traffic records and do not replace application-layer data validation.

Phased application migration: cross-region mutual calls between legacy and new environments and dual access from offices

When multiple business modules migrate to a new data centre or cloud region in batches, some services will already be running in the new environment while dependent systems or historical databases remain in the legacy environment. During this period when both environments run alongside each other, our transition network addresses three main types of connectivity:

• Cross-region mutual calls between legacy and new environments: Through the connected intranet channel between legacy and new environments and round-trip routes confirmed by administrators on both sides, front-end or business services that move to the new cloud region first can call databases and internal APIs in the legacy data centre over a stable cross-region channel, reducing API timeouts caused by cross-border or inter-region public internet fluctuations.
• Simultaneous access to legacy and new systems from multi-site offices within permitted scopes: We connect offices with both the legacy and new data centres or cloud regions on the same enterprise network, routing access traffic to the respective environment based on permitted internal subnets and permissions so employees can continue using unmigrated systems in the legacy data centre while accessing services already live in the new environment.
• Coordinate external APIs and service entry points by access direction: If a system migrated to the new environment needs to initiate outbound calls to headquarters or partner APIs that enforce source IP allowlists, and moving to the new environment changes the outbound source IP address, we can configure an agreed fixed egress IP address in the solution to help your team notify the counterparty to update their allowlist during the cutover window. Conversely, if external users, partners, or branches need to initiate inbound connections to an application system migrated to the new environment, this involves an inbound service entry adjustment that typically switches according to the addresses and rules published for the new environment; if the business system is suitable for cross-region publishing, you can also use our application publishing service based on your software deployment model so local users connect to the nearest entry point while our backbone network carries traffic back to the new environment.

After relocation completes: scaling back temporary bandwidth, closing legacy paths, and keeping daily interconnect upon notice

Once all business systems and data are running stably in the target data centre or new cloud region and your migration team confirms that the observation period for the legacy environment has ended, simply notify us to perform wrap-up adjustments:

At the mutually confirmed time, we will scale back the temporary bandwidth added during migration, remove transitional routes and access configurations pointing to the legacy data centre or legacy cloud region, and smoothly transition the network into daily operational interconnectivity between your regional offices and the new cloud environment or data centre. This avoids rebuilding an enterprise intranet after relocation while promptly stopping the extra channel capacity opened for the transition period (outbound cloud data transfer fees and cloud component charges billed by the public cloud provider during migration, as well as cabinet and bandwidth fees at the legacy data centre prior to lease termination, remain settled directly between the enterprise and the respective cloud or data centre providers).