Step 8 — Cutover finale e completamento della migrazione
Dopo che Azure DMS ha applicato il backup FULL e tutti i backup dei log, arriverai a uno stato molto importante:
Ready for Cutover
Questo significa che:
- il database di destinazione è completamente allineato
- tutte le modifiche della sorgente sono state replicate
- sei pronto per passare in produzione sulla nuova VM
Cosa succede durante il cutover
Il cutover è il momento in cui:
- si fermano le scritture sul database sorgente
- si applicano gli ultimi log
- il database di destinazione viene portato online
È l’unico momento in cui c’è downtime, ma se tutto è configurato bene parliamo di pochi minuti.
Procedura corretta
Per evitare problemi o perdita di dati, è importante seguire questi passaggi con ordine.
Prima cosa:
- fermare le applicazioni che scrivono sul database
- oppure mettere il database in modalità controllata (no nuove scritture)
Subito dopo:
- eseguire manualmente un ultimo backup dei log
Questo serve per catturare tutte le ultime transazioni.
A questo punto:
- vai nel portale Azure su DMS
- aggiorna lo stato della migrazione
- verifica che non ci siano log in sospeso
Quando tutto è allineato:
- seleziona i database
- clicca su Complete Cutover
- conferma l’operazione
Stato finale
Dopo pochi minuti:
- lo stato della migrazione diventa Succeeded
- il database sulla VM di destinazione passa da RESTORING a ONLINE
A questo punto il database è pronto per essere utilizzato.
Cosa fare dopo il cutover
Una volta completata la migrazione, ci sono alcune attività importanti:
- aggiornare le connection string delle applicazioni
- verificare login, utenti e permessi
- controllare job SQL Server Agent
- validare che tutto funzioni correttamente
Considerazione pratica
Questo è il momento più delicato, ma anche quello più soddisfacente.
Nel mio caso, quando arrivo al cutover, tutta la parte complessa è già stata fatta. Se i log sono stati applicati correttamente, il passaggio finale è rapido e senza sorprese.
Piccolo consiglio
Conviene sempre pianificare il cutover in una finestra controllata (sera o weekend), anche se il downtime è minimo.
Meglio avere margine per eventuali verifiche senza pressione.
Conclusioni
La migrazione di SQL Server verso Azure tramite Azure Database Migration Service in modalità Online è oggi uno degli approcci più efficaci per spostare workload in cloud senza impattare in modo significativo sugli utenti.
Il vantaggio principale è chiaro: puoi eseguire tutta la parte più pesante — backup, restore e sincronizzazione — mentre il database sorgente continua a lavorare. Il downtime si riduce al solo momento del cutover, che se gestito bene dura pochi minuti.
Nel mio caso, questo tipo di approccio è quello che utilizzo più spesso quando devo migrare ambienti reali, soprattutto quando non è possibile fermare le applicazioni per lungo tempo.
Un altro aspetto importante è che questa soluzione rappresenta un ottimo primo passo verso il cloud. Non sempre è possibile passare subito a servizi PaaS come Azure SQL Database o Managed Instance, soprattutto in presenza di applicazioni legacy o configurazioni particolari.
La SQL Server su Azure Virtual Machine permette invece di:
- mantenere pieno controllo dell’ambiente
- replicare quasi completamente l’architettura on-premises
- iniziare a sfruttare i vantaggi di Azure in modo graduale
Best practice
Durante questo tipo di migrazione, ci sono alcuni punti che fanno davvero la differenza:
- verificare sempre il Recovery Model FULL prima di iniziare
- eseguire e validare il backup FULL prima di procedere
- monitorare i backup dei log (sono il cuore della migrazione online)
- controllare i permessi sullo Storage Account (errore molto comune)
- testare tutto in ambiente di laboratorio prima della produzione
Uno sguardo oltre
Una volta completata la migrazione su Azure VM, si apre anche la possibilità di evolvere ulteriormente l’architettura.
Molti clienti partono da qui per poi valutare, in un secondo momento:
- ottimizzazioni dei costi
- modernizzazione delle applicazioni
- passaggio a servizi PaaS
Il bello di questo approccio è proprio questo: non è un salto nel vuoto, ma un percorso graduale.
Considerazione finale
Se stai lavorando su ambienti SQL Server datati — soprattutto con versioni in fine supporto come SQL Server 2016 — questa può essere l’occasione giusta per iniziare a portare qualcosa in Azure senza stravolgere tutto.
Nel mio caso, ogni migrazione fatta in questo modo è anche un’opportunità per mettere ordine, aggiornare e preparare il terreno per i passi successivi.
