Legacy Data Centre Migration

Migrating a data centre to cloud is a phased move, not a single event. A private connection over IZO™+ Multi Cloud Connect lets old and new run side by side during the transition, so you can cut over workload by workload with a clean fallback at each step.

What this is

Legacy data centre migration means relocating workloads – applications, databases, services – from an owned or co-located facility into public cloud. The risk is rarely the final state; it is the in-between, when some systems have moved and some have not, and the two halves must keep talking. This page is the connectivity playbook for that in-between.

The phased pattern

Phase	What happens	Role of the connection
Establish	Provision the private link; extend routing to the target cloud	Old and new sites become one private network
Replicate	Copy data and stand up target workloads alongside the source	Sustained replication over the private path
Cut over	Move traffic to the cloud workload, one service at a time	Deterministic routing switch, with fallback
Decommission	Retire the source once stable; reclaim capacity	Resize or remove the link when migration completes

The principle is coexistence. During Replicate and Cut over, a migrated workload in the cloud still depends on systems left behind on-premises, and vice versa – so the private connection carries that cross-dependency traffic at production quality, not best-effort. Cutting a service over is then a routing decision you can make and, if needed, reverse, rather than a leap.

Sequence the cutover by dependency. Move the least-coupled services first to build confidence, keep chatty co-dependent systems together so you are not carrying heavy east–west traffic back and forth across the link, and leave the system of record until its dependents are proven in the cloud. Fast, deterministic routing (BGP active/backup) means each cutover and each fallback is quick and clean.

Example

A bank migrates its retail-channel applications from a legacy data centre to Azure. It provisions a IZO™+ Multi Cloud Connect Direct connection, extends routing to the Azure environment, and replicates data continuously. Applications cut over in dependency order over several weekends; during each window the private link carries traffic between already-migrated services and those still on-premises. The core banking system moves last, once its dependent channels are stable in the cloud. The legacy facility is decommissioned only after a stable run, and the connection is resized to its steady-state role.

Bandwidth planning

Migration has two distinct bandwidth profiles. During Replicate, size for the bulk data movement within your migration windows. During steady state after cutover, size for the ongoing coexistence and user traffic, which is usually much smaller. Provision for the migration peak, then step the connection down once the source is decommissioned so you are not paying for migration-scale capacity indefinitely.

IZO™+ Multi Cloud Connect components in this architecture

Migration is a Direct build from the data centre; it can start single and go dual for the cutover windows:

IZO™+ Multi Cloud Connect Direct (private MPLS underlay):

Fabric Port – provisioned from the legacy data centre; a single port to start, dual for resilient cutover.
Virtual Cloud Connection – lands on the target cloud and carries replication then coexistence traffic.

From the IZO™+ Multi Cloud Connect side, this architecture uses a Fabric Port + Virtual Cloud Connection (dual for the cutover if needed); the Tata Communications-billed parts run to the Virtual Cloud Connection, while the target cloud’s port/attachment and egress sit on your cloud bill.

Considerations

Two bandwidth profiles - Size for the bulk replication during migration windows, then step the connection down to the steady-state coexistence load once the source is decommissioned.
Coexistence quality - During Replicate and Cut over, cross-dependency traffic between migrated and not-yet-migrated systems must run at production quality on the private path.
Sequence by dependency - Move least-coupled services first, keep chatty co-dependent systems together, and leave the system of record until its dependents are proven in the cloud.
Fallback - Keep cutovers routing-driven (BGP active/backup) so each move – and each fallback – is quick and clean.
Colo / DCI - A cross-metro colocation-to-cloud bridge folds into this pattern as an additional Fabric Port + Virtual Cloud Connection.

What’s on the cloud side

The target environment and its cloud connection are created in the cloud provider’s console. This page covers how the private migration path and coexistence routing are delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.