Da SQL Server a Azure SQL Database: guida alla migrazione

Il problema che non puoi più ignorare

Nel 2023 ho visto un'azienda manifatturiera da 800 dipendenti spendere 340.000 euro l'anno in infrastruttura SQL Server: licenze Windows Server, hardware di failover, personale dedicato alla manutenzione, e costi energetici che lievitavano. Quando mi hanno chiesto di valutare la migrazione, il ROI era talmente evidente che il CFO ha chiesto "perché non l'abbiamo fatto prima?".

Non sei solo. Secondo Gartner, entro il 2025 il 75% dei database on-premise sarà migrato verso cloud pubblico o hybrid cloud. La domanda non è più se migrare, ma come farlo senza intaccare l'operatività.

Perché Azure SQL Database e non altri cloud?

Microsoft Azure è la scelta naturale per carichi di lavoro SQL Server. La compatibilità a livello di T-SQL è pressoché totale, il che significa che le tueStored Procedure, trigger e query complesse funzionano senza riscrittura. AWS RDS per SQL Server esiste, ma supporta un sottoinsieme limitato di feature e i costi di licenza sono significativamente più alti. Google Cloud SQL per SQL Server è ancora più limitato nell'ecosistema Microsoft.

Azure SQL Database offre tre modelli di deployment:

• Database singolo: ideale per applicazioni con carico di lavoro isolato
• Pool elastici: perfetti quando hai molteplici database con picchi di utilizzo non sincronizzati (risparmio fino al 30% sui costi)
• Istanza gestita: per scenari enterprise che richiedono compatibilità quasi totale con SQL Server on-premise, incluse linked server e SQL Agent

La scelta tra questi modelli determina la complessità della migrazione e i costi operativi. Se gestisci decine di database di piccole dimensioni, i pool elastici sono un game-changer. Se hai un data warehouse mission-critical con centinaia di Stored Procedure, l'istanza gestita ti salva da notti insonni.

Fase 1: Assessment — non saltare questo passaggio

Il primo errore che vedo fare è iniziare la migrazione senza una valutazione completa. Aprite Data Migration Assistant (DMA), scaricatelo gratuitamente dal sito Microsoft, e fate una scansione completa dei vostri database.

DMA vi fornirà:

• Bloccanti di compatibilità: funzionalità deprecate o rimosse in Azure SQL Database (es. SQL Server Agent nativo non è disponibile nel database singolo)
• Parzialmente supportate: feature che funzionano ma richiedono modifiche (CLR, query distribuite)
• Raccomandazioni: indici mancanti, statistiche obsolete, query con syntax obsoleta

Il mio consiglio: se DMA segnala più di 15 bloccanti, fermatevi e pianificate un progetto di remediation prima della migrazione. Non fate come quella fintech che ha migrato di fretta e ha scoperto dopo 3 giorni che il loro sistema di logging basato su linked server verso un DB legacy non era supportato.

Fase 2: Dimensionamento e scelta del tier

Azure SQL Database offre tier di servizio basati su DTU e su vCore. Per carichi di produzione, raccomando sempre il modello vCore per controllo e prevedibilità dei costi.

I tier disponibili:

• General Purpose: per carichi di lavoro standard, storage HDD, latenza leggermente più alta (5-10ms)
• Business Critical: per database con requisiti di bassa latenza, storage SSD, replica integrata a tre nodi
• Hyperscale: per data warehouse e database con picchi imprevedibili, fino a 100TB di storage

Per dare un riferimento concreto: un database SQL Server con 16 core fisici e 64GB di RAM su hardware Enterprise generalmente consuma circa 4000 DTU. Su Azure, una configurazione equivalente in vCore sarebbe 8 vCore Business Critical, con un costo indicativo di circa 1.200-1.500 euro/mese in zona Europa Occidentale. A questo aggiungete i costi di backup (geo-redundant attivo di default) e il costo del backup a lungo termine se necessario.

Fase 3: Preparazione dello schema

Una volta completata l'assessment, passate alla conversione dello schema. Azure Database Migration Service (DMS) può automatizzare molto di questo processo, ma non aspettatevi magia.

Ecco cosa dovrete verificare manualmente:

• Credenziali e sicurezza: Azure SQL usa Azure Active Directory per l'autenticazione. Dovrete creare utenti AAD e mappare i ruoli SQL esistenti. Questo passaggio è spesso sottovalutato e causa blocchi post-migrazione.
• Compatibility level: portate i database al compatibility level 150 (SQL Server 2019) se possibile, altrimenti 140. Livelli inferiori limitano le performance optimization di Azure.
• Heap tables: Azure SQL non ama le tabelle senza indici cluster. Se ne avete, create l'indice prima della migrazione.

Fase 4: Strategia di migrazione dei dati

Qui la scelta strategica: migrazione offline (downtime prolungato, più semplice) o migrazione online (downtime minimo, più complessa).

Migrazione offline con DMS

Per database sotto i 500GB, DMS offre un'esperienza guidata eccellente:

1. Create un Azure Database Migration Service nella stessa region del vostro SQL Database target
2. Configurate un progetto di migrazione "SQL Server to Azure SQL Database"
3. Selezionate i database e le tabelle da replicare
4. DMS creerà le tabelle, migrerà i dati, e ricreerà indici e constraint
5. Per un database di 200GB su connessione ExpressRoute a 1Gbps, budgetate circa 45-60 minuti

Migrazione online per database critici

Se non potete permettervi più di 15-30 minuti di downtime, servono strumenti diversi:

• Azure Data Factory con attività di copy binlog-based replication
• ** transactional replication** verso Azure SQL (richiede SQL Server Enterprise edition)
• Always On Availability Groups con replica verso Azure SQL Managed Instance (solo per scenari Istanza Gestita)

Personalmente, per la maggior parte dei clienti enterprise, consiglio la migrazione offline durante un finestra di manutenzione pianificata. La complessità della replica in tempo reale spesso supera il beneficio del downtime ridotto, specialmente se avete un team con esperienza limitata su Azure.

Fase 5: Testing — il passaggio che fa la differenza

Non testate solo che le query funzionino. Testate:

• Performance: eseguite le query più critiche con EXPLAIN ANALYZE e confrontate i tempi. Azure SQL ha un query optimizer diverso, e alcune query potrebbero performare peggio.
• Security: verificate che tutti i permessi siano corretti, che l'AAD authentication funzioni, che le policy di Row-Level Security siano applicate
• Connection strings: aggiornate le stringhe di connessione nelle applicazioni. Ricordate che il nome del server cambia da MIO_SERVER a MIO_SERVER.database.windows.net
• Failover plan: Azure SQL Database include replica geografica automatica. Testate un failover manuale prima del go-live per verificare che le app riconnettano correttamente

Ho visto progetti fallire perché nessuno aveva testato la connection string aggiornata nell'applicazione legacy che usava un driver ODBC del 2015.

Fase 6: Cutover e post-migrazione

Il giorno del cutover:

1. Bloccate le scritture sull'applicazione (maintenance mode o block applicativo)
2. Verificate che DMS/DMS-abbia completato la sincronizzazione
3. Eseguite un controllo finale della consistenza dei dati (row count per tabella, checksum se disponibile)
4. Aggiornate le connection strings
5. Rilasciate l'applicazione
6. Monitorate per le prime 4 ore con Azure SQL Analytics

Gestione dei costi post-migrazione

Dopo la migrazione, non dimenticate di:

• Attivare Azure Hybrid Benefit: se avete Software Assurance, convertite le licenze SQL Server esistenti in risparmio fino al 40% sui costi dei vCore
• Scalare in modo elastico: se avete scelto pool elastici, monitorate i picchi e regolate le vCore allocate
• Implementare auto-pause: per ambienti di dev/test, Azure SQL Database permette di sospendere automaticamente il database durante le ore non lavorative
• UsareReserved Capacity: per carichi stabili, prenotate capacità a 1 o 3 anni per risparmiare fino al 65%

Errori comuni da evitare

• Ignorare la rete: la latenza è nemica. Se il vostro SQL Server on-premise è a Milano e l'Azure region è West Europe (Amsterdam), state aggiungendo 20-30ms di latenza. Per applicazioni OLTP ad alta frequenza, valutate una ExpressRoute o almeno una connessione VPN site-to-site.
• Non considerare le service tier: partire con tier troppo basso per "risparmiare" e poi dover scalare sotto carico reale crea interruzioni.
• Dimenticare il backup retention: Azure SQL Database include backup automatici, ma la retention di default è 7 giorni. Per compliance, verificate che sia allineata ai vostri requisiti.
• Mancare di testare su carico realistico: le performance sotto benchmark sintetico e sotto carico reale di produzione sono due mondi diversi.

Conclusione

La migrazione da SQL Server on-premise a Azure SQL Database è un percorso fattibile, con la giusta pianificazione, in 4-12 settimane a seconda della complessità. Microsoft Azure offre strumenti maturi — DMA, DMS, Azure Migrate — che riducono significativamente il rischio rispetto a pochi anni fa.

I benefici sono tangibili: riduzione del TCO del 40-60% per infrastructure e licenze, eliminazione della gestione dell'infrastruttura, alta disponibilità integrata, e scalabilità on-demand. Il mio consiglio finale: non improvvisate. Investite tempo nell'assessment iniziale e nei test. Ogni ora spesa in pianificazione vi farà risparmiare dieci ore di problemi post-migrazione.

Vuoi una valutazione personalizzata della tua infrastruttura SQL Server? Da Ciro Cloud possiamo analizzare il tuo ambiente attuale, quantificare il potenziale risparmio, e definire un piano di migrazione su misura per la tua organizzazione.