Migration von AWS zu Azure: Ein 12-Wochen Enterprise Playbook

Von einem Cloud-Anbieter zu einem anderen zu migrieren ist eines der schwierigsten Infrastrukturprojekte, die ein Unternehmen durchfuehren kann. Es ist schwieriger als die initiale Cloud-Migration, weil Sie ein laufendes System ersetzen, nicht von Grund auf neu bauen. Teams muessen eine neue Plattform erlernen und gleichzeitig die bestehende betreiben.

Dieses Playbook bietet einen strukturierten 12-Wochen-Plan fuer Unternehmen, die von AWS zu Azure migrieren. Es ist nicht theoretisch — es basiert auf Migrationen, die wir fuer europaeische Unternehmen durchgefuehrt haben. Der Zeitrahmen geht von einem mittelgrossen Deployment (20-50 Workloads) mit einem dedizierten Migrationsteam von 4-6 Ingenieuren aus.

Warum Unternehmen von AWS zu Azure migrieren

Haeufige Treiber:

• Microsoft-365-Konsolidierung: Einheitliche Identitaet, Sicherheit und Compliance ueber Office und Cloud-Infrastruktur
• EU-Compliance-Anforderungen: Azures EU Data Boundary und breitere EU-Regionsabdeckung
• Lizenzoekonmie: Azure Hybrid Benefit macht Windows/SQL-Workloads 40-80 % guenstiger
• Enterprise-Agreement-Vereinfachung: Ein Anbieter fuer Microsoft 365 + Azure + Dynamics
• Hybrid-Strategie: Azure Arc fuer konsistentes Management von On-Premises und Cloud

Dies sind rationale Gruende. "AWS ist schlecht" ist kein Grund — es ist eine exzellente Plattform. Wenn Ihre Motivation nur Frustration ueber Kosten oder Komplexitaet ist, optimieren Sie zuerst.

AWS-zu-Azure Service-Mapping

Migrationsphasen-Uebersicht

Woche-fuer-Woche Playbook

Wochen 1-2: Discovery und Assessment

Ziel: Alles verstehen, was in AWS existiert, und ein Migrationsinventar erstellen.

Aktivitaeten:

1. Automatisierte Discovery

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

# Detailliertes Compute-Inventar
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

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

2. Abhaengigkeits-Mapping: AWS X-Ray Traces und VPC Flow Logs nutzen, um Interservice-Abhaengigkeiten zu kartieren.

3. Kostenbasis: 12 Monate AWS Cost Explorer Daten exportieren. Dies wird der Benchmark fuer Azure-Kostenprojektionen.

4. Compliance-Inventar: Alle AWS Config Rules, GuardDuty-Findings und IAM Policies dokumentieren, die Compliance durchsetzen.

Lieferobjekt: Migrationsinventar-Spreadsheet mit jedem Workload, Abhaengigkeiten, Datenvolumen und Migrationskomplexitaetsbewertung (1-5).

Wochen 3-4: Architektur-Mapping und Azure-Design

Ziel: Die Azure-Zielarchitektur fuer jeden Workload entwerfen.

Aktivitaeten:

1. Landing Zone Deployment

// 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-Architekturentscheidungen: Fuer jeden Workload den Azure-Zieldienst basierend auf der Service-Mapping-Tabelle festlegen.

3. Netzwerkdesign: AWS VPC CIDR Ranges auf Azure VNet Adressraeume abbilden. Ueberlappungen mit On-Premises und der bestehenden AWS-Umgebung vermeiden.

4. Kostenprojektion: Azure Pricing Calculator fuer die Zielarchitektur nutzen.

Wochen 5-6: Identitaet und Networking

Ziel: Identitaets- und Netzwerkkonnektivitaet zwischen AWS und Azure etablieren.

Aktivitaeten:

1. Entra ID Setup

# Migrations-Service-Principal erstellen
az ad sp create-for-rbac --name "sp-aws-migration" \
  --role "Contributor" \
  --scopes "/subscriptions/${SUBSCRIPTION_ID}"

2. IAM-Policy-Uebersetzung: Dies ist der komplexeste Schritt. AWS IAM und Azure RBAC sind fundamental unterschiedliche Modelle.

3. Netzwerkkonnektivitaet: Site-to-Site VPN zwischen AWS VPC und Azure VNet fuer die Migrationsphase einrichten.

// VPN Gateway fuer AWS-Azure-Konnektivitaet
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-Strategie: DNS-Migration von Route 53 zu Azure DNS planen. TTLs auf 60 Sekunden senken.

Wochen 7-8: Datenmigration

Ziel: Datenspeicher von AWS zu Azure mit minimaler Downtime migrieren.

1. Object Storage Migration (S3 zu Blob)

# AzCopy fuer S3-zu-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

2. Datenbankmigration

Fuer SQL Server (RDS zu 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

Fuer PostgreSQL (RDS zu Azure Database for PostgreSQL):

# Native logische Replikation fuer Online-Migration
# Auf der Quelle (RDS PostgreSQL):
# ALTER SYSTEM SET wal_level = 'logical';
# CREATE PUBLICATION migration_pub FOR ALL TABLES;

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

3. Datenvalidierung: Nach der Migration Checksummen und Zeilenzahlen auf jeder Tabelle ausfuehren.

Wochen 9-10: Anwendungsmigration

Ziel: Anwendungen auf Azure deployen und testen.

1. Container-Workloads: Kubernetes-Manifeste sind groesstenteils portabel. CI/CD-Pipelines fuer Azure Container Registry und AKS oder Container Apps neu aufbauen.

2. Serverless Functions: Lambda-Funktionen muessen fuer Azure Functions umgeschrieben werden. Die Geschaeftslogik ist portabel; Trigger, Bindings und Runtime-Konfiguration nicht.

3. Konfigurationsaktualisierung: Alle AWS SDK Calls, Connection Strings und Umgebungsvariablen durch Azure-Aequivalente ersetzen.

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

# Nachher (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. Integrationstests: Vollstaendige Integrationstests gegen das Azure-Deployment ausfuehren.

Wochen 11-12: Validierung und Cutover

Ziel: Produktionsbereitschaft validieren und Cutover durchfuehren.

1. Performancetests: Lasttests gegen die Azure-Umgebung mit Produktions-Traffic-Mustern ausfuehren.

2. Sicherheitsvalidierung: Schwachstellenscans ausfuehren. Defender-for-Cloud-Empfehlungen bearbeiten.

3. Compliance-Validierung: Jede AWS Config Rule auf ihr Azure-Policy-Aequivalent abbilden.

4. Cutover-Durchfuehrung

5. Rollback-Plan: AWS-Umgebung 2-4 Wochen nach Cutover beibehalten.

Post-Migration (Wochen 13-16)

• Wochen 13-14: Azure-Konfiguration basierend auf Produktionsmetriken optimieren. VMs richtig dimensionieren, Auto-Scaling anpassen, Reserved Instances fuer stabile Workloads aktivieren.
• Wochen 15-16: AWS-Ressourcen systematisch dekommissionieren. Verifizieren, dass kein Traffic mehr zu AWS fliesst.

Risikominderung

Ehrliche Bewertung

Zwischen Cloud-Anbietern zu migrieren ist teuer, stoerend und riskant. Eine 12-Wochen-Migration mit 5 Ingenieuren kostet ca. EUR 200.000-300.000 an Aufwand (Gehaelter, Schulung, parallele Infrastruktur) plus 3 Monate reduzierte Liefergeschwindigkeit.

Diese Investition ist gerechtfertigt, wenn die langfristigen Vorteile (Lizenzeinsparungen, Compliance-Haltung, operationelle Konsolidierung) die Migrationskosten innerhalb von 18-24 Monaten uebersteigen. Wenn die Amortisationszeit laenger ist, erwaegen Sie, ob die Migration wirklich notwendig ist oder ob die Optimierung Ihrer aktuellen AWS-Umgebung die bessere Investition ist.

Wenn Sie Hilfe bei der Planung oder Durchfuehrung einer AWS-zu-Azure-Migration benoetigen, beim Aufbau Ihrer Landing Zone oder bei der Schulung Ihres Teams, kontaktieren Sie uns unter mbrahim@conceptualise.de. Wir haben europaeische Unternehmen durch diesen Prozess begleitet und koennen Ihnen helfen, die Fallstricke zu vermeiden, die wir auf die harte Tour gelernt haben.