Il fermo tollerato è il vero criterio
Dietro quasi ogni domanda di migrazione c’è lo stesso perno: quanto tempo l’applicazione può restare indisponibile. Prima ancora di scegliere lo strumento si fissano tre elementi di progetto — la finestra di fermo concordata, la dimensione del database e la banda disponibile verso Azure — e poi la destinazione. La destinazione pesa quanto il metodo: Azure SQL Managed Instance conserva quasi tutta la superficie di SQL Server (SQL Server Agent, query cross-database, Service Broker, CLR, linked server, Resource Governor) ed è la destinazione naturale di un lift and shift d’istanza; Azure SQL Database è PaaS a livello di singolo database e obbliga a riprogettare tutto ciò che vive fuori dal database; SQL Server su macchina virtuale Azure resta l’unica scelta quando servono controllo del sistema operativo, patching proprio o funzionalità che nessun PaaS espone.
Offline contro online
Nella migrazione offline si ferma il carico, si trasferisce lo stato del database, si valida e si riapre l’applicazione sulla destinazione: il fermo dura quanto trasferimento più validazione. È semplice, prevedibile, ripetibile — adatta a database piccoli, ad ambienti non di produzione o quando esiste una finestra di manutenzione generosa.
Nella migrazione online la destinazione viene inizializzata e poi mantenuta allineata in modo continuo mentre l’origine resta in produzione; il fermo si concentra nel cutover finale, quando si drena l’ultima coda di modifiche e si sposta la stringa di connessione. Costa di più in prerequisiti, monitoraggio e prove, ma è l’unica risposta quando il requisito parla di pochi minuti o di poche ore di indisponibilità.
Gli strumenti e quando sceglierli
Azure Database Migration Service è il servizio gestito di riferimento e supporta entrambe le modalità: in offline ripristina sulla destinazione i backup completi e differenziali presi dall’origine; in online continua ad applicare i backup del transaction log finché non si comanda il cutover. È la scelta di default per SQL Server verso Managed Instance o verso SQL Server su VM, e copre anche Azure SQL Database.
Il Managed Instance link replica un database da SQL Server verso Managed Instance in modo continuo, usando la tecnologia degli availability group: la Managed Instance mantiene una copia allineata e leggibile, e la migrazione si chiude con un passaggio finale molto breve. Lo stesso link serve anche come soluzione di disaster recovery o di offload della lettura, quindi in uno scenario che chiede “replica continua verso Managed Instance con fermo minimo” è il candidato più forte.
La replica transazionale resta l’opzione online quando serve migrare un sottoinsieme di oggetti o alimentare una destinazione già in uso, ma richiede che le tabelle pubblicate abbiano una primary key. Backup e restore coprono gli scenari semplici: Managed Instance può ripristinare backup nativi di SQL Server da Azure Blob Storage, mentre Azure SQL Database non accetta un file di backup nativo e usa il percorso BACPAC di import ed export, che è per definizione offline. Fra istanze gestite esistono infine copia e spostamento di database su Managed Instance, utili per riorganizzare l’estate senza ripassare dall’origine on-premises.
Dove le migrazioni si rompono
L’assessment precede sempre lo spostamento: versione e livello di compatibilità dell’origine, funzionalità non supportate sulla destinazione (tipico di Azure SQL Database), oggetti a livello di istanza che il ripristino non porta con sé. Login, permessi, linked server, credenziali e job vanno riportati a mano; su Managed Instance i job tornano in SQL Server Agent, su Azure SQL Database vanno ripensati con elastic job, Azure Automation o Azure Functions. Infine le prestazioni di rete: su volumi grandi la banda determina la durata reale, e una prova di trasferimento va fatta prima del cutover, non durante.
Trappole tipiche d’esame
- Fermo massimo di pochi minuti su un database grande → migrazione online: qualsiasi opzione che preveda copia e riapertura viola il requisito, indipendentemente dallo strumento citato.
- Replica continua da SQL Server verso Managed Instance con cutover breve → Managed Instance link: se lo scenario nomina esplicitamente Managed Instance e la replica continua, il link batte le alternative generiche.
- Ripristinare un file .bak in Azure SQL Database → non è possibile: il backup nativo si ripristina su Managed Instance o su VM; per Azure SQL Database la via è BACPAC, quindi offline.
- Migrare i job pianificati verso Azure SQL Database → elastic job: SQL Server Agent non esiste su Azure SQL Database, e una risposta che lo dà per scontato è sbagliata anche se tutto il resto torna.
- Origine con linked server, Service Broker o query cross-database → Managed Instance: portarla su Azure SQL Database significherebbe riscrivere l’applicazione, non migrarla.
- Migrazione online con replica transazionale su tabelle senza primary key → prerequisito non soddisfatto: va aggiunta la chiave o scelto un altro metodo online.