How to Migrate Servers to Azure with a Wave Plan

Why migrate servers to Azure

Migrating servers to Azure is no longer an isolated infrastructure project — it is a business decision. Expiring datacenter contracts, end-of-life hardware, power costs, and the need to scale fast push companies in Brazil and the United States toward the cloud. The challenge is rarely technical: it is migrating without disrupting operations and without blowing the budget.

The approach that reduces risk is always the same: discover the environment, assess each workload, group servers into waves, and migrate in testable increments. The central tool for this is Azure Migrate, a free hub Microsoft provides for discovery, assessment, and movement of servers, databases, and web applications.

The phases of a successful migration

A project run by RHC as a Microsoft Solutions Partner typically follows five clear phases:

1. Discovery and inventory — map every server, operating system, CPU, memory, disk, and network traffic.
2. Assessment — size the Azure target and estimate monthly cost.
3. Wave planning — group servers by dependency and criticality.
4. Migration (replication and cutover) — replicate data and switch over with a minimal window.
5. Optimization and decommission — right-size, apply reservations, and retire the old datacenter.

Discovery with the Azure Migrate appliance

Azure Migrate uses an appliance (a lightweight virtual machine installed in the current environment) that collects performance data without installing agents on every server. For VMware, Hyper-V, or physical servers, the appliance observes for several days and captures real usage peaks — this avoids oversizing the target.

The most valuable part of discovery is dependency mapping. An application server that talks to a database and an authentication service must migrate together or with guaranteed connectivity. Ignoring dependencies is the number-one cause of failed cutovers.

Assessment: right-sizing from the start

During assessment, Azure Migrate compares real consumption with available VM sizes and recommends the right SKU. You choose the criterion:

Applying Azure Hybrid Benefit and planning Reserved Instances during assessment completely changes the project's return. Initial estimates often drop significantly once these two levers enter the math.

The wave plan

The wave is the heart of low-risk migration. Instead of moving everything at once, you organize groups of servers that migrate together. Good criteria for building waves:

• Low criticality first — test and development environments validate the process.
• Dependencies grouped — application, database, and middleware in the same wave.
• Business window — respect each team's lowest-usage hours.
• Increasing complexity — simple workloads before sensitive legacy systems.

A typical wave sequence:

1. Wave 0 (pilot): test servers, no business impact.
2. Wave 1: low-criticality internal applications.
3. Wave 2: mid-size production workloads.
4. Wave 3: critical systems and primary databases.
5. Wave 4: exceptions, legacy, and cases that require modernization.

Each wave ends with a validation checklist: application responds, users can access, backups configured, and monitoring active.

Replication and cutover

During migration itself, Azure Migrate continuously replicates the server's disks to Azure while the original server stays online. When the replica is synchronized, you run a test migration in an isolated network — you boot the VM in Azure without affecting production and validate everything. Only then comes the final cutover, with a short window for the final sync.

This continuous replication with a prior test is what allows production systems to switch over with minutes of downtime, not hours.

Common mistakes RHC helps you avoid

• Migrating without assessing dependencies, breaking integrations.
• Lift-and-shifting everything, including servers that should be retired or modernized.
• Forgetting network and security — subnets, NSGs, firewall, and hybrid connectivity must be ready before wave one.
• Not planning savings — leaving Hybrid Benefit and reservations for later usually costs dearly.
• Decommissioning the old datacenter too early — keep rollback available for a period.

Checklist / Key takeaways

• Use Azure Migrate for agentless discovery and performance-based assessment.
• Treat dependency mapping as a requirement, not an option.
• Apply Azure Hybrid Benefit and Reserved Instances in the cost estimate itself.
• Organize migration in waves from lowest to highest criticality.
• Always run a test migration in an isolated network before cutover.
• Keep rollback available and only shut down the datacenter after stabilization.

As a Microsoft partner and CSP, RHC runs this process end to end — from discovery to datacenter decommission — keeping cost predictable and operations continuous.