Azure Migrate: assessment e migrazione

Azure Migrate è l’hub centralizzato per pianificare e realizzare la migrazione verso Azure di VM VMware, VM Hyper-V e server fisici. Il flusso tipico prevede due fasi. Nella fase di assessment si distribuisce l’appliance Azure Migrate on-premises, che effettua discovery agentless dei workload e ne raccoglie dati di performance (CPU, memoria, disco, rete) per un periodo di osservazione. L’assessment produce tre output chiave: readiness (il server è idoneo, idoneo con condizioni o non idoneo ad Azure), sizing e stima dei costi mensili.

Per il sizing hai due criteri: as-on-premises, che replica pedissequamente le risorse allocate, e performance-based, che dimensiona la VM di destinazione sui consumi reali misurati, con la possibilità di applicare un fattore di comfort. Performance-based è quasi sempre la scelta corretta quando l’obiettivo è ottimizzare i costi. La dependency analysis mappa le comunicazioni tra server per raggruppare i workload da migrare insieme ed evitare di spezzare applicazioni multi-tier.

Nella fase di migrazione, Azure Migrate: Server Migration replica i dischi verso Azure (replica agentless per VMware/Hyper-V, agent-based per i server fisici), consente un test failover non disruptivo e infine il cutover definitivo. Ricorda che l’Azure Hybrid Benefit si applica in fase di migrazione per riusare le licenze Windows Server con Software Assurance.

Upgrade in-place di Windows Server

L’upgrade in-place esegue setup.exe mantenendo ruoli, feature, impostazioni e dati mentre porta il sistema operativo a una versione più recente. È supportato tipicamente per uno o due salti di versione (ad esempio da Windows Server 2016 a 2019 o 2022, da 2019 a 2022, da 2022 a 2025): non puoi saltare arbitrariamente più release. L’upgrade rispetta canale ed edizione — puoi passare da Standard a Datacenter ma non tornare indietro.

All’esame l’in-place è la risposta quando il vincolo è “conservare configurazione e applicazioni senza reinstallare”; la clean install resta comunque l’approccio consigliato quando si può ripartire da zero. Prima di procedere: verifica la compatibilità, esegui backup o snapshot, controlla lo spazio disco e ricorda che il rollback dopo il completamento non è banale.

Cluster OS rolling upgrade

Il Cluster OS Rolling Upgrade aggiorna il sistema operativo dei nodi di un failover cluster (tipicamente Hyper-V o Scale-Out File Server) senza fermare i workload. Procedi un nodo alla volta: lo metti in pause/drain per spostare i ruoli sugli altri nodi, lo evicti, aggiorni il SO e lo reinserisci nel cluster.

Durante il processo il cluster entra in mixed-OS mode: nodi con versioni diverse convivono, ma il cluster resta al functional level più basso e nessuna nuova feature del SO più recente è disponibile. La mixed-OS mode è uno stato temporaneo e ancora reversibile (puoi reintrodurre nodi della versione vecchia). Solo quando tutti i nodi sono aggiornati esegui Update-ClusterFunctionalLevel per elevare il functional level: operazione irreversibile che chiude la mixed-OS mode e abilita le nuove funzionalità. Verifica prima lo stato con Get-Cluster | Select ClusterFunctionalLevel.

Trappole tipiche d’esame

  • Ottimizzare i costi della VM target → assessment performance-based: il sizing as-on-premises copia l’over-provisioning esistente e gonfia la stima; performance-based dimensiona sui consumi reali misurati.
  • “Nessuna nuova feature dopo aver aggiornato i nodi” → manca Update-ClusterFunctionalLevel: in mixed-OS mode il functional level resta basso; solo il cmdlet lo eleva e sblocca le funzionalità del SO nuovo.
  • Voler tenere aperta la finestra di rollback → non eseguire ancora Update-ClusterFunctionalLevel: è irreversibile e impedisce di reintrodurre nodi della versione precedente; lancialo solo a upgrade completato.
  • Conservare ruoli e configurazione senza reinstallare → in-place upgrade: la clean install azzererebbe impostazioni e applicazioni; l’in-place le mantiene, a costo di un rollback più complicato.
  • Migrazione senza downtime percepito → test failover prima del cutover: la replica continua mantiene i dischi sincronizzati e consente la validazione senza toccare la produzione.
  • Evitare di rompere applicazioni multi-tier → dependency analysis: senza la mappa delle dipendenze rischi di separare i tier di un’applicazione e migrarli in modo incoerente.