12 — Migrations (AZ-305)

A. Vocabulaire migration

A.1 Les 5 R ⭐⭐

🎯 Choix au 305 : urgent + dette tech faible = Rehost. Budget + temps + modernisation = Refactor/Rearchitect. Le métier dit "ce serait mieux SaaS" = Replace.

A.2 Landing Zone (LZ)

Environnement Azure pré-construit prêt à recevoir workloads :

• Structure (MGs, Subs) — Accès (Entra, RBAC, PIM) — Connectivité (hub VNet, ER/VPN on-prem) — Sécurité (Defender, Sentinel, KV, policies) — Monitoring (LAW central) — Gouvernance (Policy, naming, tagging).

Sans LZ = chaos (chaque workload son RG/VNet/identité). Avec ALZ (Azure Landing Zones, Bicep/TF MS officiel) : workloads atterrissent dans une place prête, sécurisée, conforme.

A.3 Migration Online vs Offline

A.4 Cutover

Moment exact de bascule source → cible (le "switch") :

1. J-7 : démarre replication continue
2. J-1 : cible synchro à 99.9% (lag <1s)
3. J-Jour 03:00 : cutover → coupe writes source, attend dernier lag, repointe DNS app sur Azure
4. J-Jour 03:01 : app sur Azure

→ Cutover = LE moment downtime court d'une migration online.

A.5 Dependency analysis

Comprendre qui parle à qui avant de migrer. Si web1 → db1 → auth1, migrer ensemble (sinon latence cross-cloud + facture explose). → Azure Migrate Dependency Analysis (agent ou agentless via Service Map) → graphe → migrer par waves (vagues).

A.6 SHIR (Self-hosted Integration Runtime)

• SHIR installé sur VM on-prem (accès SQL source + outbound HTTPS vers Azure)
• DMS / ADF l'utilise comme proxy
• Pas besoin d'ouvrir port 1433 entrant (outbound only) → ami du SecOps

A.7 Performance-based vs As-on-prem ⭐

🚨toujours performance-based sauf peak business imminent connu (Black Friday dans 2 semaines).

B. Cloud Adoption Framework (CAF) ⭐

B.1 C'est quoi

Méthodologie MS (docs + tools + templates) pour structurer une adoption Azure. Pas un produit, un framework de référence.

B.2 Les 7 phases

4 phases foundational (séquentielles) + 3 operational (continues en parallèle) :

B.3 8 design areas de Landing Zone

(1) Billing & Entra tenant — (2) Identity & access — (3) Resource organization — (4) Network topology — (5) Security — (6) Management — (7) Governance — (8) Platform automation (IaC).

B.4 Implémentations Landing Zones

• ALZ Bicep / Terraform ⭐ : standard MS officiel, IaC complet
• ESLZ : ancien nom (Enterprise-Scale Landing Zones — même concept)
• Landing Zone Accelerator (portail) : wizard guidé MG + hub + policies de base (light)

B.5 Pièges 305

• 🚨 Migrate / Modernize / Innovate ≠ phases séparées → ce sont des sous-méthodes dans Adopt.
• 🚨 Ordre strict foundational : Strategy → Plan → Ready → Adopt. Govern/Secure/Manage = continu en parallèle.

C. Estimation & assessment — Strategy/Plan tools

Ce sont des outils disponibles en ligne pour aider les architectes.

🚨 Piège : TCO = compare on-prem vs Azure (vue business macro). Pricing Calculator = devis Azure pur (vue technique micro). Azure Migrate Assessment = mesure ce qui tourne réellement (data-driven).

D. Azure Migrate — hub central

D.1 C'est quoi

Hub central dans le portail Azure pour piloter toutes les migrations (servers, DBs, web apps, VDI, files) avec une UI unifiée.

Project (container metadata)
   │
   ├─ Discover → Appliance (.ova VMware / .vhd Hyper-V / .exe Physical)
   ├─ Assess   → Readiness + SKU reco + cost (performance-based)
   ├─ Migrate  → Replicate + Test migration (VNet isolé) + Cutover
   └─ Modernize → App Service, AKS, SQL DB

D.2 Tools intégrés

D.3 Workflow standard

Generate key → Deploy appliance → Discovery 24-48h
→ Assessment performance-based
→ Replicate (continu) → Test migration (VNet isolé) → Cutover final

D.4 Pièges 305

• 🚨 Toujours performance-based sauf peak imminent.
• 🚨 Discovery nécessite 24-72h pour counters fiables → planifier.
• 🚨 Test migration dans VNet isolé obligatoire avant cutover prod.
• 🚨 Migrer en waves par dependency groups (sinon latence cross-cloud).
• 🚨 Sous le capot, Server Migration utilise Azure Site Recovery (ASR) pour la réplication → c'est pour ça qu'ASR est aussi cité en "outil de migration" historique.

E. Compute migration — patterns par source

E.1 VMware → Azure VMs (rehost classique)

Azure Migrate Server Migration avec appliance .ova déployée dans vCenter. Performance-based assessment → Replicate → Cutover. ✅ Use case : on veut se débarrasser de VMware et passer en Azure natif.

💡 Sous le capot Azure Migrate utilise ASR comme moteur de réplication — mais l'outil que tu invoques au 305 = Azure Migrate, pas ASR directement.

E.2 VMware → AVS (Azure VMware Solution) ⭐⭐

LE service qu'il faut connaître au 305. AVS = VMware en bloc dans Azure, VMware natif géré par MS.

On-prem vSphere
   │ VMware HCX (migration tool inclus AVS)
   ▼
Azure VMware Solution (AVS) — private cloud
  ├─ vSphere + vSAN + NSX-T + HCX
  ├─ Tu gères vCenter (CloudAdmin)
  └─ MS gère hôtes physiques + réseau Azure

Quand recommander AVS :

• Migrer des centaines/milliers de VMs VMware sans re-platformer.
• Garder vCenter, NSX, vSAN, outils VMware existants (équipes formées VMware).
• Downtime quasi-nul via HCX (vMotion / Bulk / Replication Assisted vMotion).
• Pas le temps/budget de refondre cloud-native maintenant.
• Compliance / licences (VMware ELA) imposent VMware stack.

E.3 Hyper-V → Azure VMs

Azure Migrate Server Migration avec appliance .vhd déployée sur host Hyper-V (Windows Server 2016+ avec Hyper-V role). Workflow identique VMware mais agent différent.

E.4 Physical servers → Azure VMs

Azure Migrate Server Migration avec appliance .exe (Mobility Service installé sur chaque machine physique). Use case : data centers full physiques, Linux/Windows bare-metal, ou sources non-virtualisées.

E.5 Cross-cloud (AWS / GCP → Azure)

Azure Migrate cross-cloud : appliance sur EC2/GCE, traité comme physical machines. Limité : pas de discovery deps cross-cloud aussi riche qu'on-prem.

E.6 Azure Site Recovery (ASR) — distinction nette avec Azure Migrate

ASR = service de réplication :

• Aujourd'hui (modern way) : DR continu (failover en cas de panne région). Voir fiche 11.
• Historiquement : utilisable pour migration one-shot direct (legacy approach pré-2019).
• Sous le capot d'Azure Migrate : c'est ASR qui réplique. Tu ne le vois pas, c'est transparent.

F. App modernization (Adopt > Modernize)

F.1 App Service Migration Assistant

Outil desktop gratuit, scan d'une app ASP.NET (IIS) ou Java (Tomcat) on-prem → migre en App Service en quelques clics. ✅ Use case 305 : "App ASP.NET 4.8 sur IIS Windows Server 2012 → modernizer sans réécrire" → App Service Migration Assistant.

F.2 Container modernization (VM → containers)

• Azure Migrate App Containerization : scanne une web app sur VM → génère Dockerfile + manifests Kubernetes → déploie sur AKS ou ACA.
• Patterns "re-platform vers containers" : intermédiaire entre Rehost (VM) et Rearchitect (cloud-native).
• ✅ Use case 305 : "App monolithe à moderniser sans réécrire totalement" → containerize via Migrate puis ACA/AKS.

F.3 SQL modernize

SQL Server VM on-prem → SQL DB / SQL MI via DMS. Bénéfice : PaaS managé, backups auto, HA built-in, scale-out (voir section G + fiche 11).

F.4 Azure Hybrid Benefit (AHB) — économie licences ⭐

Réutilise tes licences on-prem Windows Server / SQL Server (avec Software Assurance) pour ne payer que le compute Azure → jusqu'à -85% sur la facture VM.

🎯 Question 305 type : "Réduire coût migration VMs Windows on-prem avec Software Assurance" → Azure Hybrid Benefit.

F.5 MABS / MARS — agents backup hybrides (awareness)

Pour la phase de migration, tu peux avoir besoin de backup hybride (on-prem ↔ Azure). 2 agents MS :

🎯 Au 305 : awareness suffit. MARS = simple files/folders 1 serveur. MABS = serveur backup centralisé hybride multi-workloads. 💡 Les deux utilisent Recovery Services Vault (RSV) comme cible Azure.

G. Database migrations

G.1 Les outils

G.2 Sources / cibles

G.3 Quel target SQL pour quelle source SQL Server ⭐⭐

G.4 Modes online vs offline (DMS)

• Online ⭐ : replication continue, downtime ~secondes au cutover. Prod 24/7.
• Offline : copy one-shot, downtime = durée de migration. Maintenance window OK.

G.5 Pièges 305

• 🚨 SHIR obligatoire si source on-prem (outbound only, pas de port 1433 entrant à ouvrir).
• 🚨 Cutover online : attendre statut Ready for cutover dans DMS portal avant Complete.
• 🚨 DMA = legacy → préférer SSMS 22+ Migration extension ou DMS portail (VS Code MSSQL extension émerge mais pas encore le tooling SQL Migration complet en GA mai 2026).
• 🚨 Distinguer DB migration vs IaaS migration :
  • SQL Server on-prem → Azure SQL DB / MI : utiliser le workflow Azure SQL Migration (DMS + SSMS extension ou portail). Tool moderne dédié au workflow assessment + migration DB end-to-end.
  • Azure Migrate = tool multi-target IaaS-first (VMs, web apps, et DB via DMS embedded). OK pour discover/assess à grande échelle, mais pour la migration DB elle-même → DMS ou SSMS Migration extension guident mieux le workflow.
  • Distractor exam : "tool dédié SQL Server → Azure SQL" → DMS / SSMS Migration extension, pas Azure Migrate générique.
• 🚨 Migration vers Hyperscale : restrictions sur Active Geo-Rep / FG (voir fiche 11).

H. Unstructured data / Storage migration

H.1 Memo complet des outils de transfert ⭐⭐

3 familles : Online (réseau), Offline (Azure t'envoie un device physique), Hybride/Edge (appliance qui reste chez toi en continu).

H.2 Hybride continu : Gateway vs Stack Edge ⭐

Les appliances qui restent chez toi (≠ Data Box qu'on renvoie). Différence clé :

🎯 Question typique :

• "Continuously upload TBs of IoT data to Azure with NFS share on-prem" → Data Box Gateway
• "ML inference on cameras feeds in factory, sync results to Azure" → Azure Stack Edge (avec GPU)
• "One-shot 200 TB migration" → Data Box (offline), pas Gateway

I. Decision trees migration

Pour une VM (compute)

Plateforme source ?
├─ VMware (volumes massifs, garder vCenter) → AVS ⭐
├─ VMware (passer Azure natif)              → Azure Migrate Server Migration
├─ Hyper-V                                  → Azure Migrate Server Migration
├─ Physical                                 → Azure Migrate Server Migration
├─ AWS EC2 / GCP GCE                        → Azure Migrate cross-cloud
└─ App moderne containerizable              → Container Apps / AKS

Pour une app web

ASP.NET / Java Tomcat IIS ?     → App Service Migration Assistant
App custom multi-tier sur VMs ? → Azure Migrate App Containerization → ACA/AKS
.NET 8+ cloud-native ?           → App Service / Functions / Container Apps direct

Pour une DB

SQL Server ?
├─ Compat 100% (Agent, CLR, cross-DB, Service Broker) → SQL MI
├─ App standalone, modernizable                       → SQL DB
└─ Control OS, version SQL spécifique                 → SQL Server on Azure VM

MySQL / PG ?            → Azure DB for MySQL / PG Flexible Server
MongoDB ?               → Cosmos DB Mongo API
Oracle ?                → SQL DB / PG (assess compat) OU SQL on VM

Pour des fichiers / data lake

< 1 TB online OK               → AzCopy / Storage Explorer
10 TB - 1 PB                   → Data Box (Box / Heavy)
File server progressif         → Azure File Sync
Hadoop / data lake             → ADLS Gen2 + DistCp + ADF + Databricks/Synapse

DEMO

Portail — Setup SQL Server VM source (simuler on-prem)

1. Create a resource > Marketplace > SQL Server 2022 on Windows Server 2022 (Developer = gratuit)
2. Basics : RG, VM name, region, image SQL Server 2022 Dev, size D2s_v5, admin
3. SQL Server settings : Authentication = mixed mode, login sqladmin
4. Review + create
5. RDP sur la VM → SSMS préinstallé → Restore .bak (AdventureWorks) sample

Portail — Migration Assessment SQL (Azure Data Studio)

1. Install Azure Data Studio (multi-plateforme) + extension Azure SQL Migration
2. Connect au SQL Server source (IP + SQL auth)
3. Clic droit server > Manage > onglet Azure SQL Migration > Migrate to Azure SQL
4. Cocher DBs à assesser → Run assessment
5. Output target reco : SQL Database / Managed Instance ⭐ (compat 100%) / SQL on VM
6. Lire rapport : Critical / Warning / Info
   • Critical (force MI/VM) : cross-DB queries, SQL Agent jobs, CLR, Service Broker, FILESTREAM

Alternative : Azure Migrate > Azure SQL > Assess (sans Data Studio).

Portail — Migrate SQL → Azure SQL via DMS

Pré-requis : target Azure SQL créé, backup recent dispo.

Étape 1 — Target Azure SQL DB

1. Create a resource > SQL Database
2. Basics : name, server (create new), General Purpose / Serverless
3. Networking : Public endpoint + Allow Azure services + Add current IP
4. Review + create

Étape 2 — Créer DMS

1. Create a resource > Azure Database Migration Service
2. Service mode : Azure (managé) + même région que target
3. Networking : VNet (ou Public pour test)
4. Review + create

Étape 3 — SHIR (Self-hosted Integration Runtime)

1. Sur VM source : télécharger Microsoft Integration Runtime (https://aka.ms/integrationruntime)
2. Installer → ouvrir Configuration Manager
3. DMS > Settings > Integration runtime > +New → générer Auth Key
4. Coller la key dans l'agent SHIR → Register → état Running

Étape 4 — Migration depuis le portail DMS

1. DMS > Overview > New Migration
2. Migration type : Online (minimal downtime) ou Offline
3. Source : IP source + SQL Login + SHIR sélectionné
4. Target : Azure SQL server + DB target
5. Databases to migrate : cocher
6. Backup location : Azure Files share ou network share
7. Backup mode : Take backup automatically
8. Start migration

Étape 5 — Cutover (online)

1. DMS > Monitor migrations → attendre Ready for cutover
2. Complete cutover → source read-only, dernier diff replayé
3. Redirect app sur Azure SQL target

📌 Workflow Azure Data Studio = même résultat, UI alternatif au portail DMS.

Portail — Azure Migrate (VMware → Azure VMs)

Étape 1 — Créer projet

1. Azure Migrate > Servers, databases and web apps > Create project
2. Project name + Geography

Étape 2 — Déployer appliance VMware

1. Discovery and assessment > Discover > Yes, VMware vSphere
2. Generate project key → copier
3. Download OVA → deploy dans vCenter → register appliance avec key
4. vCenter credentials read-only → Start discovery (24-48h)

Étape 3 — Assessment

1. Discovery and assessment > Assess > Azure VM
2. Sizing criteria : Performance-based ⭐ (pas as-on-prem)
3. Storage type : Automatic, Savings : Reserved 1y/3y
4. Comfort factor 1.3, Performance history Week/Month
5. Select VMs (group) → Create assessment
6. Output : Azure readiness + SKU recommandé + monthly cost → Export Excel

Étape 4 — Replicate + Test + Cutover

1. Migration and modernization > Replicate → VMs + target VNet/subnet
2. Wait Protected state
3. Test migration (VNet isolé) → valider → Clean up test
4. Migrate (cutover) → final delta + power on Azure VM

Portail — AVS (Azure VMware Solution) deploy + HCX

Étape 1 — Créer AVS private cloud

1. Create a resource > Azure VMware Solution > Create
2. Basics : Subscription, RG, Resource name, Region
3. SKU : AV36 / AV52 / AV64 + min 3 hosts (cluster minimal)
4. Address block : /22 CIDR dédié AVS (ex 10.10.0.0/22)
5. Review + create (~3-4 heures de déploiement)

Étape 2 — Connectivité on-prem ↔ AVS

1. AVS private cloud > Connectivity : 2 options principales :
   • ExpressRoute Global Reach : pair ER on-prem ↔ ER managé AVS (recommandé prod)
   • VPN S2S via Azure vWAN : plus simple, débit moindre
2. Configurer la peering selon l'option choisie

Étape 3 — Installer HCX

1. AVS > Add-ons > HCX > Install (HCX Enterprise inclus dans AVS)
2. Récupérer HCX Cloud Manager FQDN + admin password
3. Sur vSphere on-prem : HCX Cloud Manager > Download HCX Connector .ova
4. Déployer le .ova dans vCenter on-prem → register avec activation key

Étape 4 — Site pairing + Service Mesh

1. HCX Cloud Manager (AVS) > Site pairing > Add Site Pairing → IP+credentials du HCX Connector on-prem
2. Interconnect > Service Mesh > Create → choisir les profils réseau source/destination
3. Attendre Service Mesh Up

Étape 5 — Migrer des VMs

1. HCX > Migration > Migrate
2. Choisir VMs + méthode :
   • Bulk Migration ⭐ (large scale, downtime mini cutover)
   • vMotion (zéro downtime, en série)
   • Replication Assisted vMotion (RAV) ⭐ (zéro downtime + parallèle)
3. Choisir cluster destination AVS + datastore (vSAN par défaut) + folder
4. Schedule (cutover window) → Validate → Go
5. Vérifier dans vCenter AVS que les VMs apparaissent post-migration

🚨 Le HCX Network Extension permet de garder les mêmes IPs sur les VMs migrées (L2 extension). Indispensable si l'app a des IPs hardcodées.

Azure Landing Zones — Portal Accelerator vs IaC

Approche 2026 recommandée MS : utiliser l'IaC Accelerator (Bicep ou Terraform) basé sur Azure Verified Modules (AVM). Le portail wizard reste OK si pas d'expertise IaC.

Option 1 — Portal Accelerator (wizard guidé)

1. Ouvrir aka.ms/alz/portal (deep link officiel vers le blade ALZ) — PAS dans Entra ID.
2. Renseigner : MG prefix, Region, Identity/Connectivity/Management subs, Network topology (hub-spoke / vWAN).
3. Review + Deploy → déploie MG hierarchy + hub network + policies de base.
4. Suivi : Deployments au scope tenant.

⚠️ Approche portail = moins de flexibilité, pas de version control natif. À transitionner vers IaC quand maturité IaC OK.

Option 2 — IaC Accelerator (recommandé)

aka.ms/alz/accelerator — automatise la mise en place avec phases :

• Phase 0 : Planning (choix Bicep ou Terraform + Azure DevOps ou GitHub)
• Phase 1 : Prerequisites (credentials, subscriptions)
• Phase 2 : Bootstrap (PowerShell module prépare l'environnement)
• Phase 3 : Run (CI/CD pipelines déploient la LZ)

Option 3 — AVM modules direct (Bicep)

Pour intégrer dans un repo existant sans accelerator complet :

# AVM Bicep modules pour ALZ : aka.ms/alz/bicep
# (équivalent Terraform : aka.ms/alz/tf)

# Référencer un module AVM dans ton Bicep
# Exemple : déploiement de la hub network
az deployment sub create -l eastus \
  --template-file ./alz-deploy.bicep \
  --parameters @hub-params.json

🚨 L'ancien repo github.com/Azure/ALZ-Bicep (que tu peux voir cité dans des tutos plus anciens) est supplanté en 2026 par AVM (aka.ms/alz/bicep). MS maintient encore l'ancien mais pousse AVM comme standard.