12 — Migrations

Concevoir une migration vers Azure → cadrage CAF/WAF, évaluation du parc on-prem (Azure Migrate), puis choix de la stratégie (rehost/replatform/refactor) et de l'outil (DMS, Data Box) selon volume, downtime et cible.

A. Vocabulaire migration

A.1 Les « R » de migration (CAF : jusqu'à 8 stratégies)

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)

Pour source DB on-prem pas accessible direct depuis Azure :

• 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

🚨 Au 305 : 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)

C. Well-Architected Framework (WAF) — à ne pas confondre

WAF = framework de design d'un workload Azure (pas une méthodo d'adoption). 5 piliers :

🎯 Mnémo : CAF = roadmap pour amener l'entreprise sur Azure (org-level) — WAF = design d'un workload spécifique (workload-level). Au 305 on cite WAF quand on justifie un choix de design ("recommande X car aligne avec le pilier Cost").

D. 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).

E. Azure Migrate — hub central

E.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

E.2 Tools intégrés

E.3 Workflow standard

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

E.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).
• 🚨 La migration agent-based (serveurs physiques, AWS/GCP, VMware avec Mobility Service) réutilise des composants backend d'Azure Site Recovery (ASR). ⚠️ Mais la migration agentless (VMware/Hyper-V, méthode par défaut recommandée) n'utilise PAS ASR : réplication par l'appliance Azure Migrate via snapshots Changed Block Tracking. Donc « Azure Migrate = toujours ASR » est faux pour le chemin par défaut.

F. Compute migration — patterns par source

F.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.

F.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.

F.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.

F.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.

F.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.

F.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.

Règle au 305 — mots-clés → outil :

G. App modernization (Adopt > Modernize)

G.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.

G.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.

G.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).

G.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.

G.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.

H. Database migrations

H.1 Les outils

H.2 Sources / cibles

H.3 Quel target SQL pour quelle source SQL Server

🚨 Piège classique : "On a SQL Agent jobs + cross-DB queries" → SQL MI, pas SQL DB. 🚨 Si Linked Servers, Replication, DTC required → SQL MI ou VM.

H.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.

I. Unstructured data / Storage migration

Bases AzCopy / Data Box / Storage Explorer = AZ-104 fiche 7. Ici un memo complet scénarios 305 + comparaison appliances.

I.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).

J. 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

K. Scénarios 305 → outil

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Assurance — sortie de datacenter VMware sous délai de bail

Contexte business : assureur avec ~600 VMs VMware (vSphere 7.0). Le bail du datacenter expire dans 9 mois. Les équipes maîtrisent vCenter/NSX, licences VMware en cours, et aucun budget pour réécrire les apps maintenant. Choix architectural : déplacer le parc « tel quel » vers Azure VMware Solution (AVS) — qui héberge VMware dans Azure — plutôt que de convertir chaque VM en VM Azure native via Azure Migrate. Architecture / pattern :

• AVS private cloud, SKU AV36, min 3 hosts, bloc /22 dédié.
• Lien on-prem ↔ AVS via ExpressRoute Global Reach.
• HCX Bulk Migration (migration de masse en parallèle) pour le gros du parc ; RAV pour les ~30 VMs critiques sans coupure.
• HCX Network Extension (L2) pour garder les mêmes IPs (apps avec IP en dur). Trade-offs assumés :
• Gain : coupure minimale, aucune réécriture, on garde outils et compétences VMware, et on tient le délai du bail.
• Perte : cher (hosts AV36 facturés à l'heure), aucune modernisation PaaS, dette technique repoussée. Pièges à éviter :
• AVS vs Azure Migrate : « garder vCenter » ⇒ AVS, pas Azure Migrate.
• HCX exige vSphere 6.5+ côté source ; à vérifier avant de s'engager.
• Pas de Cold migration pour le parc prod (coupure longue) — la réserver au hors-prod. 📐 Réf. CAF — Migrate methodology (rehost) / WAF Cost Optimization : le rehost AVS est un like-for-like justifié quand la modernisation n'est pas requise sous 2 ans ; le pilier Cost impose d'assumer le surcoût des hosts dédiés comme trade-off explicite vs gain de délai. Lien

Scénario 2 : Média — transfert massif d'archives vidéo, réseau insuffisant

Contexte business : studio média, ~600 TB d'archives vidéo sur un NAS on-prem à monter vers Azure Blob. Le lien WAN est saturé : un upload online prendrait plusieurs mois. C'est un transfert one-shot, sans besoin de synchro continue. Choix architectural : transfert hors-ligne via Data Box Heavy (~770 TB utilisables) — on copie sur l'appareil, on l'expédie à Microsoft — plutôt qu'un upload online ou une appliance hybride. Architecture / pattern :

• 1× Data Box Heavy (40 GbE, chiffrement AES-256, 2 nœuds de 500 TB).
• Copie SMB locale → appareil → renvoi au datacenter Azure → upload interne vers le storage account cible.
• Cross-region direct supporté si la région cible diffère du pays d'origine (l'appareil ne sort pas du pays). Trade-offs assumés :
• Gain : aucun impact sur le WAN de prod, données chiffrées (AES-256 + TPM), délai prévisible vs upload online interminable.
• Perte : délai logistique (envoi/retour) ; c'est une photo à l'instant T (les données modifiées après la copie sont à resynchroniser). Pièges à éviter :
• Data Box Heavy = ~770 TB utilisables, pas 800 TB ni 1 PB (1 PB = chiffre brut marketing).
• Ne pas confondre Data Box (hors-ligne, one-shot), Data Box Gateway (online continu) et Azure Stack Edge (compute en Edge).
• Data Box ne fait ni cross-cloud ni export cross-region. 📐 Réf. CAF — Migrate (unstructured data transfer) / WAF Performance Efficiency : le choix offline est dicté par la tranche de volume vs débit réseau disponible ; le pilier Performance Efficiency justifie d'écarter l'online quand le WAN devient le goulot. Lien

Scénario 3 : Santé — assessment et dependency mapping avant migration par vagues

Contexte business : groupe hospitalier, ~400 serveurs mixtes (VMware + physiques), apps très interconnectées (web → DB → auth → AD). Personne ne connaît vraiment qui dépend de qui. Le risque : migrer un tier en oubliant ses dépendances ⇒ lenteurs et pannes. Choix architectural : une vraie phase Plan/Assess avec Azure Migrate (découverte + dimensionnement basé sur la perf réelle + analyse de dépendances sans agent) avant de bouger quoi que ce soit, puis migration par vagues. Architecture / pattern :

• Appliance Azure Migrate (OVA VMware) ; les serveurs physiques traités avec agent.
• Découverte 24-72h pour des compteurs fiables ; assessment performance-based (on dimensionne sur l'usage réel, pas sur la config on-prem).
• Analyse de dépendances sans agent (capture TCP, relevé toutes les 5 min, jusqu'à 1000 serveurs/appliance) → graphe → groupes d'apps.
• Migration découpée en vagues par groupe de dépendances ; test de migration en VNet isolé avant chaque bascule. Trade-offs assumés :
• Gain : aucune dépendance oubliée, bon dimensionnement (économies vs surdimensionner), moins de pannes après migration.
• Perte : ça prend des semaines (découverte + analyse) ; le mode sans agent donne moins de détail (niveau réseau, pas processus) que le mode avec agent. Pièges à éviter :
• Toujours performance-based, sauf gros pic métier imminent connu d'avance.
• L'analyse de dépendances avec agent (classic view) est dépréciée fin 2026 → préférer le sans agent.
• Test de migration en VNet isolé obligatoire avant la bascule en prod. 📐 Réf. CAF — Plan : assess workloads + migration wave planning / WAF Reliability : CAF impose discovery → dependency mapping → wave planning pour réduire le risque ; le pilier Reliability motive de migrer les groupes inter-dépendants ensemble. Lien

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.