Migrating from AWS to Azure: A 12-Week Enterprise Playbook

Migrating from one cloud provider to another is one of the hardest infrastructure projects an enterprise can undertake. It is harder than the initial cloud migration because you are replacing a running system, not building from scratch. Teams must learn a new platform while keeping the existing one operational.

This playbook provides a structured 12-week plan for enterprises migrating from AWS to Azure. It is not theoretical — it is based on migrations we have executed for European enterprises. The timeline assumes a mid-size deployment (20-50 workloads) with a dedicated migration team of 4-6 engineers.

Why Enterprises Migrate from AWS to Azure

Before the playbook, a note on motivation. Common drivers:

• Microsoft 365 consolidation: Unified identity, security, and compliance across Office and cloud infrastructure
• EU compliance requirements: Azure's EU Data Boundary and broader EU region coverage
• License economics: Azure Hybrid Benefit makes Windows/SQL workloads 40-80 % cheaper
• Enterprise Agreement simplification: One vendor for Microsoft 365 + Azure + Dynamics
• Hybrid strategy: Azure Arc for managing on-premises alongside cloud

These are rational reasons. "AWS is bad" is not a reason — it is an excellent platform. If your motivation is simply frustration with cost or complexity, optimise first before migrating.

AWS to Azure Service Mapping

This table covers the most common services encountered in enterprise migrations:

Migration Phases Overview

Week-by-Week Playbook

Weeks 1-2: Discovery and Assessment

Objective: Understand everything that exists in AWS and build a migration inventory.

Activities:

1. Automated discovery

# AWS resource inventory
aws resourcegroupstaggingapi get-resources \
  --output json > aws-resource-inventory.json

# Detailed compute inventory
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,Type:InstanceType,State:State.Name,AZ:Placement.AvailabilityZone,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table

# Database inventory
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,Engine:Engine,Size:DBInstanceClass,Storage:AllocatedStorage,MultiAZ:MultiAZ}' \
  --output table

# S3 bucket sizes
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  size=$(aws s3 ls s3://$bucket --recursive --summarize | tail -1 | awk '{print $3}')
  echo "$bucket: $size bytes"
done

2. Dependency mapping: Use AWS X-Ray traces and VPC flow logs to map inter-service dependencies. Export to a dependency matrix.

3. Cost baseline: Export 12 months of AWS Cost Explorer data. This becomes the benchmark for Azure cost projections.

4. Compliance inventory: Document all AWS Config rules, GuardDuty findings categories, and IAM policies that enforce compliance. These must be replicated in Azure.

Deliverable: Migration inventory spreadsheet with every workload, its dependencies, data volumes, compliance requirements, and migration complexity rating (1-5).

Weeks 3-4: Architecture Mapping and Azure Design

Objective: Design the target Azure architecture for each workload.

Activities:

1. Landing zone deployment: Deploy Azure Landing Zone using the Cloud Adoption Framework accelerator. This provides the management group hierarchy, networking hub, policy baseline, and logging infrastructure.

// Landing zone - Hub VNet
resource hubVnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
  name: 'vnet-hub-westeurope'
  location: 'westeurope'
  properties: {
    addressSpace: { addressPrefixes: ['10.0.0.0/16'] }
    subnets: [
      {
        name: 'AzureFirewallSubnet'
        properties: { addressPrefix: '10.0.1.0/24' }
      }
      {
        name: 'GatewaySubnet'
        properties: { addressPrefix: '10.0.2.0/24' }
      }
      {
        name: 'snet-management'
        properties: { addressPrefix: '10.0.3.0/24' }
      }
    ]
  }
}

2. Workload architecture decisions: For each workload, decide the target Azure service based on the service mapping table. Document architectural changes required.

3. Network design: Map AWS VPC CIDR ranges to Azure VNet address spaces. Avoid overlaps with on-premises networks and the existing AWS environment (they will coexist during migration).

4. Cost projection: Use the Azure Pricing Calculator to estimate monthly costs for the target architecture. Compare against the AWS baseline.

Deliverable: Azure architecture document with VNet design, service selections, and cost projections per workload.

Weeks 5-6: Identity and Networking

Objective: Establish identity and network connectivity between AWS and Azure.

Activities:

1. Entra ID setup

# Create migration service principal
az ad sp create-for-rbac --name "sp-aws-migration" \
  --role "Contributor" \
  --scopes "/subscriptions/${SUBSCRIPTION_ID}"

# Configure conditional access baseline
az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  --body @conditional-access-baseline.json

2. IAM policy translation: This is the most complex step. AWS IAM and Azure RBAC are fundamentally different models.

3. Network connectivity: Establish site-to-site VPN between AWS VPC and Azure VNet for the migration period.

// VPN Gateway for AWS-Azure connectivity
resource vpnGateway 'Microsoft.Network/virtualNetworkGateways@2023-05-01' = {
  name: 'vpn-gw-hub'
  location: 'westeurope'
  properties: {
    gatewayType: 'Vpn'
    vpnType: 'RouteBased'
    sku: { name: 'VpnGw2', tier: 'VpnGw2' }
    ipConfigurations: [
      {
        name: 'default'
        properties: {
          publicIPAddress: { id: vpnPublicIp.id }
          subnet: { id: gatewaySubnet.id }
        }
      }
    ]
  }
}

4. DNS strategy: Plan DNS migration from Route 53 to Azure DNS. Lower TTLs on existing records to 60 seconds to prepare for cutover.

Deliverable: Identity mapping document, network connectivity verified, DNS migration plan.

Weeks 7-8: Data Migration

Objective: Migrate data stores from AWS to Azure with minimal downtime.

Activities:

1. Object storage migration (S3 to Blob)

# AzCopy for S3 to Azure Blob migration
azcopy copy \
  "https://s3.eu-central-1.amazonaws.com/my-bucket" \
  "https://mystorageaccount.blob.core.windows.net/my-container" \
  --s2s-preserve-access-tier=true \
  --recursive=true \
  --include-after "2026-01-01"

# Verify copy completeness
azcopy list "https://s3.eu-central-1.amazonaws.com/my-bucket" --running-tally > s3-inventory.txt
azcopy list "https://mystorageaccount.blob.core.windows.net/my-container" --running-tally > azure-inventory.txt
diff s3-inventory.txt azure-inventory.txt

2. Database migration

For SQL Server (RDS to Azure SQL):

# Azure Database Migration Service
az dms project task create \
  --resource-group rg-migration \
  --service-name dms-migration \
  --project-name rds-to-azure-sql \
  --task-name migrate-orders-db \
  --task-type MigrateSqlServerSqlDb \
  --source-connection-json @source-rds.json \
  --target-connection-json @target-azure-sql.json \
  --database-options-json @db-options.json

For PostgreSQL (RDS to Azure Database for PostgreSQL):

# Native logical replication for online migration
# On source (RDS PostgreSQL):
# ALTER SYSTEM SET wal_level = 'logical';
# CREATE PUBLICATION migration_pub FOR ALL TABLES;

# On target (Azure PostgreSQL Flexible Server):
# CREATE SUBSCRIPTION migration_sub
#   CONNECTION 'host=rds-endpoint port=5432 dbname=mydb'
#   PUBLICATION migration_pub;

3. Data validation: After migration, run checksums and row counts on every table. Validate application-level data integrity, not just technical replication success.

Deliverable: All data stores migrated and validated. Delta sync configured for ongoing changes until cutover.

Weeks 9-10: Application Migration

Objective: Deploy and test applications on Azure.

Activities:

1. Container workloads: Kubernetes manifests are mostly portable. Rebuild CI/CD pipelines to push to Azure Container Registry and deploy to AKS or Container Apps.

2. Serverless functions: Lambda functions must be rewritten for Azure Functions. The business logic is portable; the trigger configuration, input/output bindings, and runtime configuration are not.

3. Configuration update: Replace all AWS SDK calls, connection strings, and environment variables with Azure equivalents. This is tedious but critical.

# Before (AWS)
import boto3
s3 = boto3.client('s3')
obj = s3.get_object(Bucket='my-bucket', Key='data.json')

# After (Azure)
from azure.storage.blob import BlobServiceClient
blob_service = BlobServiceClient.from_connection_string(os.environ['AZURE_STORAGE_CONNECTION'])
blob_client = blob_service.get_blob_client(container='my-container', blob='data.json')
data = blob_client.download_blob().readall()

4. Integration testing: Run full integration test suites against the Azure deployment. Focus on data paths, authentication flows, and cross-service communication.

Deliverable: All applications deployed to Azure staging environment. Integration tests passing.

Weeks 11-12: Validation and Cutover

Objective: Validate production readiness and execute the cutover.

Activities:

1. Performance testing: Run load tests against the Azure environment matching production traffic patterns. Compare latency, throughput, and error rates against AWS baselines.

2. Security validation: Run vulnerability scans. Verify Defender for Cloud recommendations are addressed. Confirm network security groups match the intended security posture.

3. Compliance validation: Map every AWS Config rule to its Azure Policy equivalent. Verify audit logs are flowing to Sentinel. Confirm compliance dashboard parity.

4. Cutover execution

5. Rollback plan: Maintain the AWS environment for 2-4 weeks after cutover. DNS can be reverted within 60 seconds (due to lowered TTL). Database failback requires the reverse sync to be active.

Deliverable: Production traffic serving from Azure. Monitoring confirms parity with AWS performance.

Post-Migration (Weeks 13-16)

• Week 13-14: Optimise Azure configuration based on production metrics. Right-size VMs, adjust auto-scaling, enable Reserved Instances for stable workloads.
• Week 15-16: Decommission AWS resources systematically. Verify no traffic is flowing to AWS. Delete resources, cancel Reserved Instances (or transfer), close the account.

Risk Mitigation

Honest Assessment

Migrating between cloud providers is expensive, disruptive, and risky. A 12-week migration with 5 engineers represents approximately EUR 200,000-300,000 in effort (salaries, training, parallel infrastructure) plus 3 months of reduced delivery velocity.

This investment is justified when the long-term benefits (license savings, compliance posture, operational consolidation) exceed the migration cost within 18-24 months. If the payback period is longer, consider whether the migration is truly necessary or whether optimising your current AWS environment is the better investment.

If you need help planning or executing an AWS to Azure migration, building your landing zone, or training your team on Azure, contact us at mbrahim@conceptualise.de. We have guided European enterprises through this process and can help you avoid the pitfalls we have learned the hard way.