How to Plan a Cloud Migration: Complete Technical Playbook

Every cloud migration follows the same arc: excitement, chaos, regret, stabilization. This guide compresses the chaos phase by giving you a concrete, step-by-step framework used in 30+ enterprise migrations.

Step 1: Build Your Application Inventory

Before migrating anything, you need a complete inventory. Most organizations don’t actually know what they have running.

1.1 Automated Discovery

# Azure Migrate — deploy the discovery appliance
az migrate project create \
  --name "Migration-Assessment" \
  --resource-group myRG \
  --location eastus

# AWS Application Discovery Service
aws discovery start-continuous-export
aws discovery describe-configurations --configuration-ids server-1234

1.2 Manual Inventory Template

For each application, capture:

Field	Example
Application Name	ERP Portal
Owner	Finance Team
Technology Stack	.NET 6, SQL Server 2019, IIS
Current Infrastructure	2× Dell R740, SAN storage
Dependencies	Active Directory, SMTP relay, File share
Data Volume	2.4 TB (database) + 800 GB (files)
RPO / RTO	15 min / 4 hours
Monthly Cost (Current)	$3,200 (amortized hardware + licensing)
Compliance Requirements	SOC 2, HIPAA

Step 2: Map Dependencies

Dependency mapping is where most migrations fail. An application never exists in isolation.

2.1 Network-Level Discovery

# Use netstat to find active connections on Windows
netstat -ano | findstr ESTABLISHED | findstr :1433  # SQL connections
netstat -ano | findstr ESTABLISHED | findstr :443   # HTTPS connections

# Linux equivalent
ss -tunapl | grep ESTAB | awk '{print $5}' | sort | uniq -c | sort -rn

2.2 Build the Dependency Graph

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Web App    │────▶│   API Layer  │────▶│  SQL Server  │
│  (IIS/.NET)  │     │  (.NET Core) │     │  (2019 Std)  │
└──────────────┘     └──────────────┘     └──────────────┘
       │                    │                     │
       ▼                    ▼                     ▼
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│    Redis     │     │ File Share   │     │    SSRS      │
│   (Cache)    │     │  (SMB/NFS)   │     │ (Reporting)  │
└──────────────┘     └──────────────┘     └──────────────┘

:::tip[Migration Rule] Components connected by solid lines must migrate together. If you migrate the Web App but leave SQL Server on-prem, you’re adding latency to every query. Group tightly coupled components into migration waves. :::

Step 3: Choose Your Migration Strategy (6 Rs)

For each application, choose one of the 6 R strategies:

Strategy	Description	When to Use	Effort
Rehost (Lift & Shift)	Move as-is to cloud VMs	Legacy apps, quick migration	Low
Replatform	Minor modifications (e.g., managed DB)	Apps with modular components	Medium
Refactor	Rewrite for cloud-native	Strategic apps worth investing in	High
Repurchase	Replace with SaaS	Off-the-shelf functionality	Medium
Retain	Keep on-premises	Compliance, low ROI to migrate	None
Retire	Decommission	Unused or redundant applications	None

Decision Framework

Is the application actively used? ──NO──▶ RETIRE
         │
        YES
         │
Does it have a SaaS equivalent? ──YES──▶ REPURCHASE (if cost-effective)
         │
        NO
         │
Is it strategic and worth investing in? ──YES──▶ REFACTOR
         │
        NO
         │
Can you use managed services (DB, cache)? ──YES──▶ REPLATFORM
         │
        NO
         │
▶ REHOST (lift and shift)

Step 4: Size Your Landing Zone

4.1 Compute Sizing

# Collect performance data for sizing
# Windows Performance Monitor — capture 2 weeks of data
typeperf "\Processor(_Total)\% Processor Time" \
  "\Memory\Available MBytes" \
  "\PhysicalDisk(_Total)\% Disk Time" \
  -si 60 -o perf_data.csv -f CSV

# Map to cloud VM sizes
# Rule of thumb:
# 4 vCPU on-prem ≈ 2-4 vCPU in cloud (modern chips are faster)
# Match peak memory, not average

4.2 Network Requirements

Current Bandwidth	Azure ExpressRoute	AWS Direct Connect
< 200 Mbps	200 Mbps circuit ($55/mo)	1 Gbps hosted ($220/mo)
200 Mbps - 1 Gbps	1 Gbps circuit ($290/mo)	1 Gbps dedicated ($220/mo)
> 1 Gbps	10 Gbps circuit ($4,750/mo)	10 Gbps dedicated ($1,650/mo)

Step 5: Execute the Migration Wave

5.1 Pre-Migration Checklist

Backup all source systems
Document current DNS, IP, and firewall configurations
Prepare rollback runbook
Notify stakeholders of maintenance window
Pre-stage data replication (for large datasets)
Test connectivity from cloud to on-prem dependencies

5.2 Migration Execution

# Azure Site Recovery — replicate VMs
az site-recovery replication-protected-item create \
  --fabric-name "OnPrem-Fabric" \
  --name "erp-web-01" \
  --protection-container "DefaultContainer" \
  --provider-specific-details '{
    "instanceType": "InMage",
    "masterTargetId": "target-01",
    "processServerId": "ps-01"
  }'

# AWS Server Migration Service
aws sms create-replication-job \
  --server-id s-1234567890abcdef0 \
  --seed-replication-time 2026-03-15T00:00:00Z \
  --frequency 3600

5.3 Cutover Procedure

T-4 hours: Final data sync / replication flush
T-2 hours: Stop source application (maintenance mode)
T-1 hour: Verify replication is 100% complete
T-0: Switch DNS to cloud endpoints
T+1 hour: Smoke test all critical paths
T+4 hours: Monitor for issues, prepare rollback
T+24 hours: Declare migration complete or rollback

:::caution[DNS TTL] Reduce DNS TTL to 300 seconds (5 minutes) at least 48 hours before cutover. This ensures that when you flip DNS, the propagation happens quickly. Reset to normal TTL (3600+) after 48 hours of stable operation. :::

Step 6: Post-Migration Optimization

The migration isn’t complete when the workload is running in the cloud — it’s complete when it’s optimized.

Right-size VMs within 30 days based on actual cloud metrics
Enable auto-scaling for variable workloads
Implement tagging for cost allocation
Set up monitoring with Azure Monitor / CloudWatch
Review security groups — remove overly permissive rules

Migration Checklist

Complete application inventory
Map all dependencies
Assign migration strategy (6 Rs) to each application
Size landing zone (compute, storage, network)
Build and test landing zone
Execute migration waves (grouped by dependency)
Cutover with rollback plan
Post-migration right-sizing and optimization
Decommission source systems

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For a premium cloud migration assessment, visit garnetgrid.com. :::