How to Plan a Datacenter Exit to the Cloud

Datacenter exit: a business project, not just IT

Moving out of an owned or colocation datacenter to Azure is one of the highest-impact infrastructure decisions a company makes. Beyond technology, it involves contracts, deadlines, people and operational continuity. A well-planned datacenter exit reduces risk, avoids duplicate cost and delivers a modern platform; a poorly planned one produces cost surprises and outages.

As a Microsoft Solutions Partner, RHC structures these exits into clear phases with risk governance at every step.

Why leave the datacenter

The most common triggers:

• Contract end of colocation or an imminent hardware refresh.
• Capital cost of server and storage refresh.
• Need for elasticity that on-premises does not provide.
• Resilience and DR hard to maintain on a single site.
• Modernization of applications and data.

Phase 1: Discovery and inventory

Nothing is planned without visibility. Capture:

1. Server inventory, VMs, operating systems and versions.
2. Applications and their business owners.
3. Dependencies between systems (communication map).
4. Databases, volumes and growth rates.
5. Requirements for latency, compliance and data residency.

Tools like Azure Migrate help discover workloads, map dependencies and estimate target sizing and cost.

Phase 2: Per-application strategy (the 6 Rs)

Each workload gets a strategy:

Most projects combine rehost for speed and replatform/refactor for strategic workloads.

Phase 3: Target design

Before moving, design the target:

• Landing zone in Azure with governance, network, identity and security.
• Network topology (hub-and-spoke, hybrid connectivity via VPN or ExpressRoute).
• Identity model integrated with Entra ID.
• Policies for cost, tags and security from day one.

A well-built landing zone avoids rework and technical debt right at the start.

Phase 4: Wave migration

Never migrate everything at once. Organize waves:

1. Start with low-risk workloads without critical dependencies.
2. Group applications that talk to each other to migrate together and avoid cross-boundary latency.
3. Keep controlled coexistence during the transition.
4. Validate each wave before advancing.

Replication tools like Azure Migrate and Azure Site Recovery let you replicate VMs and cut over with a minimal window.

Phase 5: Cutover, validation and decommission

For each wave:

• Run functional and performance validation in the target.
• Perform cutover in a planned window, with a rollback plan.
• Monitor for a period before decommissioning the source.
• At the end, close colocation contracts and hardware refresh.

Risks and how to mitigate

• Duplicate cost during coexistence: minimize wave duration.
• Latency between separated tiers: group dependencies.
• Cost surprises at the target: size with real data and apply reservations/Hybrid Benefit.
• Skills gap: lean on a partner for the landing zone and first waves.

Datacenter exit checklist

• Complete inventory and dependency map.
• 6 Rs strategy defined per application.
• Landing zone and hybrid network designed.
• Wave plan with success criteria.
• Cutover window and rollback plan per wave.
• Cost governance with reservations and Hybrid Benefit.
• Decommission schedule aligned with contracts.

RHC runs the datacenter exit end to end, from the Azure Migrate assessment to the cutover of the final waves, keeping continuity and cost under control.