Best Practices -- VMware to Azure Migration¶

Assessment methodology, phased migration waves, parallel-run validation, application dependency mapping, network cutover planning, decommission timeline, and Broadcom contract negotiation strategies.

1. Assessment methodology¶

Start with data, not opinions¶

The most common migration failure is migrating based on assumptions rather than data. Use Azure Migrate to collect actual utilization data for a minimum of 2 weeks (4 weeks preferred) before making sizing or migration path decisions.

Workload categorization¶

Classify every VM into one of four tiers:

Most VMware estates have 15--30% zombie VMs. Every zombie VM you decommission instead of migrating saves \(1,500--\)3,000/year in Azure costs. Invest time in identifying these VMs early.

Right-sizing opportunity¶

Azure Migrate assessment data typically reveals that VMs are significantly over-provisioned:

2. Phased migration waves¶

Wave planning principles¶

1. Start with low-risk workloads: dev/test environments, non-production systems
2. Validate with pilot production: select 5--10 production VMs for the first wave
3. Scale with confidence: increase wave size after each successful wave
4. Group by application: migrate entire application stacks together, not individual VMs
5. Respect dependencies: use dependency mapping to avoid breaking application chains

Recommended wave structure¶

Application dependency mapping¶

Before each wave, validate application dependencies:

# Export Azure Migrate dependency data
# Azure Portal > Azure Migrate > Dependency analysis > Export

Critical dependencies to map:

• Database connections (which app VMs connect to which DB VMs)
• File share dependencies (which VMs mount which NFS/SMB shares)
• Service-to-service calls (API calls between application tiers)
• External integrations (connections to SaaS, partner systems, internet)
• Authentication dependencies (AD domain controllers, LDAP servers)
• DNS dependencies (internal DNS resolution requirements)
• Load balancer configurations (VIPs, backend pools, health probes)
• Monitoring dependencies (which agents report to which collectors)

3. Parallel-run validation¶

Parallel-run strategy¶

Run migrated workloads in parallel with on-premises for a defined period:

Validation checklist¶

For each migrated application:

Functional validation:

• Application starts and responds to requests
• All API endpoints return expected responses
• Authentication and authorization work correctly
• Database queries return correct results
• Batch jobs complete successfully
• Scheduled tasks execute on schedule
• Email/notification integrations work

Performance validation:

• Response time within acceptable range (compare to on-prem baseline)
• CPU utilization is healthy (< 80% sustained)
• Memory utilization is healthy (< 85% sustained)
• Disk IOPS meets workload requirements
• Network throughput is sufficient
• No packet loss or high latency

Operational validation:

• Azure Monitor collecting metrics and logs
• Alerts configured and tested
• Azure Backup running and verified
• DR replication (ASR) enabled and healthy
• NSG rules validated (no unexpected blocks)
• DNS resolution working for all names

4. Network cutover planning¶

DNS-based cutover (recommended)¶

The safest cutover approach uses DNS changes:

1. Before migration: VM is at IP 10.100.1.50 (on-prem), DNS TTL set to 300 seconds
2. During parallel run: both on-prem (10.100.1.50) and Azure (10.20.1.50) are active
3. Cutover: update DNS A record from 10.100.1.50 to 10.20.1.50
4. Rollback: if issues, revert DNS A record to 10.100.1.50

# Pre-cutover: reduce DNS TTL to 60 seconds (24 hours before cutover)
# This ensures clients will pick up the change quickly

# Cutover: update DNS record
az network private-dns record-set a update \
  --resource-group rg-dns \
  --zone-name contoso.internal \
  --name app-server-01 \
  --set "aRecords[0].ipv4Address=10.20.1.50"

# Verify DNS propagation
nslookup app-server-01.contoso.internal

# Post-cutover: restore DNS TTL to normal (3600 seconds) after 48 hours stable

Load balancer cutover¶

For applications behind load balancers:

1. Before: traffic flows through on-prem load balancer (NSX LB or F5)
2. During parallel: Azure Load Balancer is configured and health-checked
3. Cutover: update external DNS to point to Azure LB VIP (or update Global Traffic Manager weights)
4. Rollback: revert DNS to on-prem LB VIP

Network cutover risks and mitigations¶

5. Decommission timeline¶

On-premises decommission sequence¶

Data retention considerations¶

Before decommissioning on-prem storage:

• Verify all data is accessible on Azure
• Confirm regulatory retention requirements are met
• Archive data that is not migrated but must be retained
• Document data lineage for audit trail
• Sanitize media per NIST 800-88 guidelines (Purge or Destroy)

6. Broadcom contract negotiation during migration¶

Negotiation strategies¶

If your Broadcom VMware contract is up for renewal while you are migrating:

Negotiation timing¶

12 months before expiry: Begin migration planning and Azure POC
 9 months before expiry: Inform Broadcom of Azure migration plans
 6 months before expiry: Request short-term extension proposal
 3 months before expiry: Execute extension (or let expire if migration is complete)

Document all Broadcom pricing changes for internal budget justification. If you are a federal agency, this documentation supports competitive analysis requirements under FAR and may support TMF (Technology Modernization Fund) applications.

7. CSA-in-a-Box integration for data workloads¶

Identifying data workloads for modernization¶

During assessment, identify VMs running data workloads that are candidates for PaaS modernization:

Data workload migration sequencing¶

1. Phase 1 (during infrastructure migration): migrate data VMs to Azure IaaS via Azure Migrate
2. Phase 2 (post-infrastructure migration): modernize from Azure IaaS to PaaS via CSA-in-a-Box
3. Phase 3 (optimization): optimize Fabric capacity, Direct Lake, dbt contracts

This two-phase approach gets you off VMware quickly (Phase 1) and then modernizes at Azure speed (Phase 2).

CSA-in-a-Box deployment alongside AVS/IaaS¶

Deploy CSA-in-a-Box's data landing zone in parallel with AVS/IaaS landing zones:

# Deploy CSA-in-a-Box foundation
az deployment sub create \
  --location eastus2 \
  --template-file infra/main.bicep \
  --parameters infra/parameters/prod.bicepparam

# Verify data platform services
az resource list \
  --resource-group rg-data-platform \
  --query "[].{Name:name, Type:type, Location:location}" \
  --output table

8. Change management¶

Stakeholder communication¶

Training plan¶

9. Common pitfalls and avoidance¶

10. Migration readiness checklist¶

Before starting migration execution:

Technical readiness:

• Azure Migrate assessment complete with 2+ weeks of performance data
• AVS private cloud deployed and HCX enabled (if using AVS path)
• Azure IaaS landing zone deployed (VNet, NSG, Firewall, Bastion)
• ExpressRoute or VPN connectivity verified
• DNS resolution working between on-premises and Azure
• Azure Backup and DR configured
• Monitoring (Azure Monitor, Defender for Cloud) enabled

Organizational readiness:

• Workload categorization complete (Tier A/B/C/D)
• Application dependency mapping complete
• Migration wave plan approved by stakeholders
• Rollback plan documented for each wave
• Training completed for operations team
• Change management process established
• Broadcom contract situation addressed (extension or expiry plan)

Compliance readiness (federal):

• ATO package updated to include Azure environment
• STIG hardening applied to Azure VMs
• Azure Policy assignments aligned with compliance framework
• Defender for Cloud compliance dashboard configured
• CSA-in-a-Box compliance mappings reviewed (for data workloads)

Related¶

• AVS Migration Guide
• Azure IaaS Migration Guide
• TCO Analysis
• Federal Migration Guide
• Benchmarks
• Migration Playbook

Last updated: 2026-04-30 Maintainers: CSA-in-a-Box core team