How to Plan a Cloud Migration: Complete Technical Playbook
Step-by-step guide to migrating workloads to Azure, AWS, or GCP. Covers assessment, dependency mapping, migration strategies (6 Rs), and cutover planning.
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. The organizations that succeed treat migration as a program, not a project — with clear waves, dependency tracking, and ruthless prioritization.
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-12341.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 |
1.3 Application Categorization
| Category | Description | Migration Priority | Typical Count |
|---|---|---|---|
| Critical business apps | Revenue-generating, customer-facing | High (wave 3-4, after validation) | 5-10 |
| Internal productivity | Email, collaboration, HR | Medium (wave 2) | 10-20 |
| Development/test | CI/CD, staging environments | High (wave 1, low risk) | 5-15 |
| Legacy/EOL | Old servers, unused apps | Retire candidates | 10-30 |
| Shadow IT | Unknown servers discovered during audit | Evaluate per app | 5-20 |
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 -rn2.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) │
└──────────────┘ └──────────────┘ └──────────────┘2.3 Dependency Types
| Type | Description | Migration Impact |
|---|---|---|
| Hard dependency | App won’t start without this service | Must migrate together or maintain connectivity |
| Soft dependency | App works without it but degraded | Can migrate separately with temporary workaround |
| Network dependency | Latency-sensitive connection | Must be in same region/VPC |
| Auth dependency | AD, LDAP, SAML | Requires hybrid identity solution during transition |
| Data dependency | Shared database, file share | Must resolve ownership before migration |
:::tip[Migration Rule] Components connected by hard dependencies 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 | Risk |
|---|---|---|---|---|
| Rehost (Lift & Shift) | Move as-is to cloud VMs | Legacy apps, quick migration | Low | Low |
| Replatform | Minor modifications (e.g., managed DB) | Apps with modular components | Medium | Low-Med |
| Refactor | Rewrite for cloud-native | Strategic apps worth investing in | High | Medium |
| Repurchase | Replace with SaaS | Off-the-shelf functionality | Medium | Medium |
| Retain | Keep on-premises | Compliance, low ROI to migrate | None | None |
| Retire | Decommission | Unused or redundant applications | None | 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)Cost Comparison by Strategy (per application)
| Strategy | Implementation Cost | Timeline | Ongoing Cost Impact |
|---|---|---|---|
| Rehost | $5K-$20K | 1-4 weeks | Similar to on-prem |
| Replatform | $10K-$50K | 2-8 weeks | 20-40% lower (managed services) |
| Refactor | $50K-$500K | 2-12 months | 40-70% lower (cloud-native) |
| Repurchase | License cost | 1-3 months | Varies by SaaS vendor |
| Retain | $0 | N/A | Same (but aging hardware) |
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 average4.2 Sizing Rules of Thumb
| On-Prem Resource | Cloud Equivalent | Notes |
|---|---|---|
| 4 vCPU server | 2-4 vCPU VM | Modern cloud CPUs are faster |
| 32 GB RAM | Match exactly | Memory is cheap, don’t undersize |
| 500 GB SAN (IOPS: 5K) | Premium SSD (P30: 5K IOPS) | Match IOPS, not just capacity |
| SQL Server 2019 | Azure SQL / RDS | Start with general purpose, scale up |
| File share 1 TB | Azure Files / EFS | Match throughput, not just capacity |
4.3 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 Wave Planning
| Wave | Applications | Strategy | Timeline | Risk |
|---|---|---|---|---|
| 0 | Landing zone, networking, identity | Foundation | Month 1-2 | Low |
| 1 | Dev/test environments | Rehost | Month 2-3 | Low |
| 2 | Internal tools (wiki, monitoring) | Rehost/Replatform | Month 3-4 | Low |
| 3 | Non-critical business apps | Rehost/Replatform | Month 4-5 | Medium |
| 4 | Critical business apps | Replatform/Refactor | Month 5-8 | High |
| 5 | Remaining apps + decommission | Mixed | Month 8-10 | Medium |
5.2 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.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.
| Optimization | Timeline | Expected Savings |
|---|---|---|
| Right-size VMs (based on actual metrics) | Day 30 | 20-40% |
| Enable auto-scaling for variable workloads | Day 30-60 | 15-30% |
| Convert to reserved instances (stable workloads) | Day 90 | 30-50% |
| Implement tagging for cost allocation | Day 1 | Visibility |
| Set up monitoring with alerting | Day 1 | Incident response |
| Review security groups | Day 7 | Risk reduction |
| Decommission source infrastructure | Day 90 | 100% of on-prem cost |
Migration Checklist
- Complete application inventory (automated + manual)
- Categorize all applications (critical, internal, dev, legacy, shadow)
- Map all dependencies (hard, soft, network, auth, data)
- Assign migration strategy (6 Rs) to each application
- Size landing zone (compute, storage, network)
- Build and test landing zone (networking, identity, security)
- Plan migration waves (low-risk first, critical in later waves)
- Execute migration waves (grouped by dependency)
- Cutover with rollback plan and DNS TTL reduction
- Post-migration right-sizing and optimization
- Convert to reserved instances for stable workloads
- Decommission source systems (don’t pay for both!)
:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For a premium cloud migration assessment, visit garnetgrid.com. :::
