La progettazione di una migrazione verso Azure non è un esercizio di “sollevamento” tecnico, ma una serie di decisioni di trade-off tra costo, rischio, tempo e valore a lungo termine. In AZ-305 ti viene chiesto di raccomandare la strategia corretta dato un requisito, collocandola nella fase Migrate del Cloud Adoption Framework (CAF), subito dopo Strategy, Plan e Ready (landing zone) e prima di Manage/Govern.

Assessment con Azure Migrate

Ogni raccomandazione difendibile parte da un assessment basato su dati, non su assunzioni. Azure Migrate è l’hub centrale: distribuisci l’appliance per la discovery agentless di VMware/Hyper-V/server fisici, raccogli metriche di performance per almeno 1 settimana (idealmente 30 giorni per catturare i picchi) e ottieni dependency mapping (agentless o agent-based) per raggruppare i workload che devono migrare insieme.

L’assessment produce tre output decisionali:

  • Azure readiness: quali server sono “ready”, “conditionally ready” (es. OS non supportato) o “not ready”.
  • Right-sizing: scegli tra criterio as-on-premises (replica la config attuale, rischioso perché eredita l’over-provisioning del datacenter) e performance-based (dimensiona sui consumi reali osservati). Per l’ottimizzazione dei costi — pilastro Cost Optimization del Well-Architected Framework — preferisci sempre performance-based, così eviti di pagare capacità inutilizzata.
  • Cost estimate: incorpora Azure Hybrid Benefit (licenze Windows Server/SQL) e Reserved Instances, tipicamente decisivi per rendere il TCO cloud competitivo.

Scelta della strategia: le 5 R

Data la baseline, raccomandi la strategia per workload confrontando sforzo e beneficio:

  • Rehost (lift-and-shift): migri la VM as-is con Azure Site Recovery o la replica nativa di Azure Migrate. Minimo sforzo e rischio, nessun beneficio PaaS. Raccomandalo quando il vincolo è il tempo (datacenter in scadenza, exit da un lease) o l’app è legacy/di terze parti non modificabile.
  • Refactor (repackage): modifiche minime per usare PaaS, es. web app da IIS ad Azure App Service, o container su Azure Container Apps/AKS. Buon compromesso quando vuoi ridurre l’overhead operativo senza riscrivere.
  • Rearchitect: modifichi significativamente il codice per scalabilità cloud-native (microservizi, monolite → funzioni serverless). Alto sforzo, giustificato solo se l’app è strategica e i limiti attuali bloccano il business.
  • Rebuild: riscrivi da zero cloud-native. Da riservare a casi in cui il refactor costa più della riscrittura.
  • Replace (retire/SaaS): sostituisci con SaaS (es. Exchange → Microsoft 365). La migrazione più economica è quella che non fai.

Regola d’esame: quando lo scenario enfatizza velocità e basso rischio → rehost; quando enfatizza riduzione dei costi operativi e modernizzazione a sforzo contenuto → refactor verso PaaS.

Migrazione dei database

Per i database la scelta principale è destinazione e modalità:

  • Azure Database Migration Service (DMS) orchestra migrazioni offline (downtime accettabile) o online (downtime minimo, replica continua fino al cutover).
  • SQL Server → Azure SQL Managed Instance quando serve alta compatibilità (SQL Agent, cross-database query, CLR): richiede minima modifica del codice. → Azure SQL Database quando vuoi il massimo del PaaS e l’app è compatibile con il modello single-database.
  • Usa Data Migration Assistant per valutare compatibilità e breaking changes prima di scegliere la destinazione.

Cutover e connettività ibrida

Il design deve prevedere la coesistenza: durante la transizione i workload migrati devono comunicare con i sistemi ancora on-premises. Progetta prima la connettività ibrida — ExpressRoute per banda garantita e bassa latenza in migrazioni massive, Site-to-Site VPN come backup o per scenari a volume ridotto. Pianifica il cutover con una finestra definita, criteri di rollback e validazione post-migrazione (pilastri Reliability e Operational Excellence).

Trappole tipiche d’esame

  • Requisito: migrazione rapida, app di terze parti non modificabile → Rehost con Azure Site Recovery. Non proporre rearchitect/rebuild: aggiungono rischio e tempo senza beneficio richiesto.
  • Scenario: costi cloud stimati troppo alti dopo l’assessment → usa right-sizing performance-based + Azure Hybrid Benefit + Reserved Instances. Il criterio as-on-premises è la trappola: eredita l’over-provisioning.
  • App composta da più server che si chiamano tra loro → esegui dependency mapping in Azure Migrate e migra il gruppo insieme. Migrare un singolo server senza mappare le dipendenze rompe l’applicazione.
  • SQL Server con SQL Agent e cross-database query, downtime minimo richiesto → Azure SQL Managed Instance con DMS in modalità online. Azure SQL Database qui fallirebbe per incompatibilità di feature.
  • Workload migrati devono ancora accedere a un file server on-premises → progetta la connettività ibrida (ExpressRoute/VPN) prima del cutover. Dimenticare la coesistenza durante la transizione è l’errore classico di pianificazione.