Azure Cloud Migrate

Azure Cloud Migrate

Migrate workloads to Azure in controlled waves with clear risk management, rollback options, and validation.

Use This Skill When

• The user is moving applications or data to Azure
• The user needs migration planning and wave sequencing
• The user needs cutover and post-migration validation
• The user wants to assess workload readiness and identify blockers

Context: Migration Maturity

Immature: Ad hoc migrations, no planning, high risk of failure Developing: Discovery done, basic wave plan, some testing Managed: Dependency mapping, wave execution, validation, rollback plan → Target Optimized: Automated discovery, real-time risk scoring, self-healing post-migration

Required Inputs

• Workload inventory: Applications, databases, storage, and external dependencies
• Current infrastructure: Hosting stack (VMware, Hyper-V, cloud competitors)
• Constraints: Downtime window, cutover blackout dates, compliance/data residency
• Success criteria: Performance targets, cost targets, SLA requirements
• Team: Who executes? Internal, partner, Microsoft FastTrack?

Decision Tree

What's the migration strategy for each workload?
├─ Rehost (lift-and-shift) → Move VM as-is, minimal changes
├─ Replatform (lift, tinker, shift) → Update OS/runtime, same app logic
├─ Refactor (re-architect) → Rebuild for cloud-native (containers, serverless)
├─ Replace (buy SaaS) → Decommission, switch to SaaS alternative
└─ Retain → Stay on-premises (not migrating)

What's the business criticality and complexity?
├─ Low complexity, non-critical → Migrate first (learn fast)
├─ Medium complexity, moderate criticality → Migrate mid-wave
└─ High complexity, critical → Migrate last (proven process)

How much downtime is acceptable?
├─ Zero downtime (active-active) → Requires dual-run, complex
├─ Few hours (typical) → Scheduled cutover window
├─ Days/weeks (acceptable) → Phased over time
└─ Unlimited (decommissioned) → Can take time

Are there compliance/data residency constraints?
├─ No → Full flexibility, optimize for cost/speed
├─ Yes → Choose Azure region carefully, plan audit trail
└─ Multi-region required → Plan for data synchronization

Workflow

Phase 1: Discovery & Assessment

1. Collect inventory:

```bash # Use Azure Migrate az migrateprojects create --resource-group $RG \ --migrate-project-name "migration-prod" \ --location "eastus"

# Discover on-premises: # ├─ VMs (Hyper-V, VMware, physical) # ├─ Databases (SQL Server, Oracle, PostgreSQL) # ├─ File shares and storage # └─ Network and firewall rules ```

1. Map dependencies:

``` Application Tiers:

Frontend (Web): └─ asp-web-01 (4-core, 8GB) └─ asp-web-02 (4-core, 8GB) └─ Depends on: api-backend, load balancer

Backend (API): └─ api-backend-01 (8-core, 16GB) └─ api-backend-02 (8-core, 16GB) └─ Depends on: sql-db, cache, message queue

Data: └─ sql-db (2-core, 32GB, 500GB storage) └─ cache (2-core, 4GB) └─ msg-queue (shared, 100GB) ```

1. Assess readiness:

`` Checklist: ✓ OS supported by Azure (Windows Server 2012+, Linux) ✓ No unsupported drivers/hardware ✓ Network connectivity (ExpressRoute or VPN gateway planned) ✓ Licensing (can migrate with Software Assurance) ✓ Backup & DR strategy documented ✗ Custom middleware (Oracle WebLogic) → May need workarounds ⚠️ Large database (500GB) → Plan staging environment ``

1. Calculate costs:

``` On-premises annual cost: ├─ Hardware/lease: $50K ├─ Datacenter/power: $15K ├─ Licensing: $30K └─ Staff: $60K Total: $155K/year

Azure annual cost estimate: ├─ VMs (2x D4s_v3): $2,176/month ├─ SQL Database (S3): $380/month ├─ Storage (1TB): $100/month ├─ Data transfer (egress): $500/month └─ Networking: $200/month Total: ~$45K/year → 71% cost reduction ```

Phase 2: Plan Migration Waves

1. Define waves (sequence by risk):

``` Wave 1 (Non-critical, simple) - Week 1-2 ├─ Dev/Test environments ├─ Non-customer-facing apps └─ Risk: Low | Duration: 1 day | Rollback: Easy

Wave 2 (Medium criticality) - Week 3-4 ├─ Internal tools, ops systems ├─ Secondary workloads └─ Risk: Medium | Duration: 2-4 hours | Rollback: 1 hour

Wave 3 (Critical, complex) - Week 5-6 ├─ Customer-facing API ├─ Database tier └─ Risk: High | Duration: 4 hours | Rollback: 4 hours

Wave 4 (Legacy, low urgency) - Month 2 ├─ Deprecated systems, archive data └─ Risk: Low | Duration: Flexible | Rollback: None (decommission) ```

1. Define success criteria per wave:

``` Wave 1 Validation: ✓ All VMs boot and pass health checks ✓ Application logs show no errors ✓ Network connectivity confirmed ✓ Backups run successfully → If all pass: Proceed to Wave 2 (hold 1 day for monitoring) → If any fail: Rollback and investigate

Wave 3 Validation (critical): ✓ Database migrated and schemas match (byte-level comparison) ✓ Performance benchmarks met (p95 latency <200ms) ✓ Users can log in and perform core operations ✓ Alerts firing correctly → Monitor for 24 hours before declaring success ```

Phase 3: Prepare Azure Landing Zone

1. Create landing zone:

```bash # Hub VNet for shared services az network vnet create \ --resource-group $RG \ --name "hub-vnet" \ --address-prefix "10.0.0.0/16" \ --location "eastus"

# Spoke VNet for migrated workloads az network vnet create \ --resource-group $RG \ --name "spoke-prod-vnet" \ --address-prefix "10.1.0.0/16" \ --location "eastus"

# Peer hub to spoke az network vnet peering create \ --resource-group $RG \ --vnet-name "hub-vnet" \ --name "hub-to-spoke" \ --remote-vnet "/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Network/virtualNetworks/spoke-prod-vnet" \ --allow-vnet-access --allow-forwarded-traffic ```

1. Setup connectivity:

``bash # ExpressRoute (dedicated connection, recommended for large migrations) OR # VPN Gateway (cheaper, adequate for <100 Mbps) az network vpn-gateway create \ --resource-group $RG \ --name "vpn-gateway" \ --vnet "hub-vnet" \ --public-ip-address "vpn-public-ip" ``

1. Configure identity:

``bash # Azure AD Connect (sync on-premises AD with Entra ID) # Enables seamless login for users post-migration ``

Phase 4: Execute Migration

1. Test migration (dry-run):

`` For Wave 1 Dev VM: ├─ Create snapshot of on-premises VM ├─ Replicate to Azure via Azure Migrate ├─ Boot test VM (non-production) ├─ Verify OS, applications, connectivity ├─ Take snapshots for rollback ├─ Validate performance (CPU, memory, disk I/O) └─ Document issues and blockers ``

1. Production migration (Wave 1):

``` Timeline: 00:00 - Pre-cutover validation ├─ On-premises: All health checks pass ├─ Azure: Landing zone ready, connectivity confirmed └─ Rollback: Test executed successfully

01:00 - Begin replication ├─ Disable on-premises VM ├─ Final delta sync to Azure (5-10 min) ├─ Boot Azure VM └─ Verify applications online

01:20 - Update DNS/routing ├─ Route traffic to Azure VM ├─ Monitor error rate and latency └─ Alert on-call if issues

02:00 - Validation ├─ Run smoke tests (login, core operations) ├─ Check logs for errors ├─ Verify backup job runs └─ Declare success or rollback ```

1. Handle database migrations (special care):

``` For SQL Server Database:

Option 1: Azure Database Migration Service (DMS) ├─ Continuous replication (minimal downtime) ├─ Schema sync automatically └─ Cutover: Switch connection string

Option 2: Full backup/restore ├─ Backup from on-premises ├─ Upload to storage ├─ Restore to Azure SQL └─ Run validation queries

Option 3: Native replication ├─ Setup Always-On Availability Group ├─ Sync on-premises to Azure ├─ Failover when ready └─ Decommission on-premises replica ```

Phase 5: Validate & Optimize

1. Post-migration validation:

``` Functional: ✓ All applications running (no errors in app logs) ✓ Users can access (login successful) ✓ Data integrity (row counts match, checksums pass) ✓ Integrations working (APIs, file shares accessible)

Performance: ✓ CPU utilization < 80% ✓ Memory utilization < 85% ✓ Disk I/O latency < 10ms ✓ Application response time: p95 < SLA

Operational: ✓ Backups running successfully ✓ Monitoring/alerting active ✓ Patch management configured ✓ Cost tracking shows expected usage ```

1. Optimize sizing (reduce costs post-migration):

``` Day 1 (over-provisioned for safety): ├─ Web tier: 2x D4sv3 (4-core, 16GB) = $240/month ├─ API tier: 2x D8sv3 (8-core, 32GB) = $480/month └─ Total: $720/month

Day 30 (after monitoring): ├─ Web tier: Actually uses 20% CPU, 40% memory ├─ Downsize to: 1x D2sv3 (2-core, 8GB) = $60/month ├─ API tier: Actually uses 30% CPU, 50% memory ├─ Downsize to: 1x D4sv3 (4-core, 16GB) = $120/month └─ Savings: $540/month (75% reduction) ```

1. Decommission on-premises:

`` After 30 days in production (stable): ├─ Keep on-premises running as backup (DR failback if needed) ├─ Reduce licensing/support cost ├─ Plan hardware decommissioning (6 months) └─ Document lessons learned ``

Output Contract

1. Migration Strategy

• Rehost/replatform/refactor approach per workload
• Dependency map and criticality ranking
• Readiness assessment (blockers, risks)

1. Wave Plan

• Sequence (Wave 1, 2, 3...)
• Workloads per wave
• Timeline and blackout windows
• Success criteria and validation steps

1. Risk Assessment

• Identified risks (data loss, downtime, performance)
• Mitigation strategies
• Rollback procedures

1. Cutover Runbook

• Hour-by-hour timeline
• Pre-cutover validation checklist
• Go/no-go decision criteria
• Rollback triggers

1. Post-Migration Plan

• Validation checklist (functional, performance, ops)
• Cost optimization (right-sizing)
• Decommissioning timeline (on-premises)

Guardrails

• Don't skip dependency mapping: Hidden dependencies cause cutover failures.
• Include rollback path: Every wave must have <4-hour rollback procedure.
• Validate before/after: Use checksums, row counts, smoke tests.
• Plan data sync carefully: Large databases need careful timing to avoid data loss.
• Communicate with users: Publish maintenance windows, expected downtime.
• Test in dev first: Execute exact same procedures in non-prod before production.
• Monitor obsessively post-cutover: First 24 hours are highest risk; watch logs/alerts closely.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: manu14357
• Source: manu14357/zskills
• License: MIT
• Homepage: https://zskills.vercel.app

Install and usage instructions live in the source repository linked above.