Migrazione da SQL Server ad Azure SQL: quanto costa davvero, cosa si rompe e come si fa

Il titolare di un'azienda di serramenti vicino a Padova mi chiama perché il gestionale è lento il lunedì mattina. Gli chiedo dove gira il database. Mi risponde che è su un server sotto la scrivania del magazzino, un Dell del 2016 con SQL Server 2016 Standard, e che l'ultimo backup verificato risale a "quando è venuto il tecnico, forse marzo". Il tecnico è andato in pensione. Il disco di backup è lo stesso disco dei dati, diviso in due cartelle. Il gestionale lo usano diciotto persone, il database pesa 60 gigabyte e ogni fattura emessa passa da lì.

Questa guida è per chi si trova in una situazione simile e sente dire da tutti che "basta metterlo su Azure". Ti spiego dove può andare davvero un database SQL Server, cosa si rompe nel trasloco, quanto costa farlo girare ogni mese e quanto costa il progetto per spostarlo. La migrazione di SQL Server verso Azure SQL conviene quando il database è sotto i 500 gigabyte, usa poche funzioni legate al server e nessuno in azienda ha tempo di curare backup e aggiornamenti: per un database di medie dimensioni il progetto costa circa 6.000-15.000 euro e il canone mensile parte da 15 euro e arriva a 300-400 euro, contro un costo totale in sede che su cinque anni supera quasi sempre i 25.000 euro.

Se prima vuoi capire il quadro dell'intero applicativo, leggi come si migra un'applicazione da .NET Framework: il database è una metà del problema, il programma che lo usa è l'altra.

Perché il database è il pezzo che nessuno vuole toccare, e perché ora

Una versione di SQL Server fuori supporto non è un guasto che si vede: è un rischio che cresce in silenzio, perché Microsoft non pubblica più correzioni di sicurezza e il tuo gestionale continua a funzionare come se niente fosse. Il supporto esteso di SQL Server 2012 è finito nel luglio 2022, quello di SQL Server 2014 nel luglio 2024 e quello di SQL Server 2016 il 14 luglio 2026. Se il tuo server ha un'etichetta con una di queste tre versioni, da qualche mese, o da qualche anno, gira senza correzioni.

Le aziende che incontro hanno quasi sempre lo stesso quadro. Il database è nato con il gestionale, quindici anni fa, quando il consulente di allora ha installato SQL Server Standard su una macchina che faceva anche da file server. Da allora nessuno ha rinnovato la licenza di assistenza, il disco si è riempito due volte, la macchina è stata sostituita una volta e il database è stato spostato con un copia e incolla. Nessuno sa dire quanti job notturni girano, chi ha la password di sa e se i backup si possono ripristinare davvero.

Ci sono tre motivi per muoversi adesso, e nessuno è la moda del cloud. Il primo è la sicurezza: un SQL Server senza correzioni, raggiungibile dalla rete interna, è la porta aperta preferita dai ransomware. Il secondo è il rischio di fermo: un disco rotto o un server che non riparte, con l'ultimo backup di sei mesi fa, ferma l'azienda per giorni. Il terzo è il blocco dell'evoluzione: finché il database sta su un server vecchio, nessuno può aggiornare il programma che lo usa, e il debito si accumula come descrivo in quanto costa il software su misura.

Il lavoro sul database non è comunque un obbligo di andare su Azure. Si può aggiornare SQL Server in sede, e a volte è la scelta giusta. Il resto di questa guida serve a capire quando lo è e quando no.

Le quattro destinazioni possibili, e quale scegliere

"Azure SQL" non è un prodotto solo ma tre, più una quarta strada che è semplicemente il vecchio SQL Server su una macchina virtuale nel cloud: Azure SQL Database, Azure SQL Managed Instance e SQL Server su macchina virtuale, e la scelta si fa su quante funzioni del server il tuo database usa davvero.

Azure SQL Database è il database singolo: nessun server da gestire, backup automatici, aggiornamenti fatti da Microsoft, pagamento a consumo o a capacità. È la destinazione più economica e la più pulita, ma supporta solo le funzioni che stanno dentro al database, non quelle che vivono nel server attorno. Azure SQL Managed Instance è un'istanza completa, con più database, SQL Agent e query fra database, ed è la scelta quando il database fa cose da server ma non vuoi gestire il sistema operativo. SQL Server su macchina virtuale è lo stesso SQL Server di oggi, con gli stessi limiti, spostato in una macchina Azure: la compatibilità è totale e il risparmio è minimo, perché backup, aggiornamenti e sicurezza restano a tuo carico.

I prezzi della tabella sono ordini di grandezza verificati nel calcolatore di Azure a novembre 2026, e cambiano con la regione, la capacità scelta e l'eventuale riserva di uno o tre anni. Prima di firmare qualunque cosa, rifai il conto con i tuoi numeri: il calcolatore di Azure è gratuito e dà in dieci minuti una cifra più precisa di qualunque tabella.

La domanda che separa le strade è una sola: il tuo database usa funzioni che vivono fuori dal database? Se la risposta è no, Azure SQL Database è quasi sempre la strada giusta, e fra tutte è la più economica da tenere in piedi. Se la risposta è sì per due o tre funzioni, può essere più sensato sistemarle che pagare una Managed Instance. Se la risposta è sì per molte e il programma non si può toccare, la Managed Instance o la macchina virtuale evitano mesi di riscrittura. Per capire quante funzioni usi serve l'inventario, ed è il prossimo passo.

L'inventario: cosa si rompe nel trasloco

Quasi tutto quello che si rompe passando ad Azure SQL Database sta in cinque posti: i job di SQL Agent, le query fra database diversi, i server collegati, le funzioni scritte in codice compilato e i comandi di sistema lanciati dal database. Sono funzioni che nei database di quindici anni fa si usavano senza pensarci, e che in Azure SQL Database o non esistono o funzionano in modo diverso.

I job di SQL Agent sono le operazioni notturne: ricalcolo delle giacenze, chiusura della giornata, invio di file al commercialista. In Azure SQL Database SQL Agent non c'è, e al suo posto si usano i job elastici, le Azure Functions o i flussi di Azure Data Factory. Non è difficile, ma ogni job va riletto, e ho visto aziende scoprire all'ultimo giorno che i job erano ventidue. Le query fra database diversi, scritte nella forma nomedatabase.dbo.tabella, non funzionano fra due database di Azure SQL Database separati, se non con strumenti dedicati e lenti. I server collegati non esistono. Le funzioni in codice .NET compilate dentro SQL Server (CLR) sono limitate. I comandi di sistema, come xp_cmdshell per copiare un file, non esistono.

Per non scoprire tutto all'ultimo giorno, si interroga il database prima. Queste tre query, da lanciare sul database di produzione con un utente di sola lettura, dicono già molto:

-- 1. Job pianificati e relativo stato: ciascuno è un lavoro da riscrivere
SELECT j.name, j.enabled, j.date_modified
FROM msdb.dbo.sysjobs AS j
ORDER BY j.name;

-- 2. Riferimenti ad altri database: dove il codice esce dal database
SELECT DISTINCT
       OBJECT_NAME(d.referencing_id) AS oggetto,
       d.referenced_database_name   AS database_chiamato,
       d.referenced_entity_name     AS tabella_o_vista
FROM sys.sql_expression_dependencies AS d
WHERE d.referenced_database_name IS NOT NULL
  AND d.referenced_database_name <> DB_NAME();

-- 3. Server collegati: ciascuno è un sistema esterno da raggiungere in altro modo
SELECT s.name, s.product, s.provider, s.data_source
FROM sys.servers AS s
WHERE s.is_linked = 1;

Tre risultati vuoti sono la miglior notizia possibile: il database è un database e basta. Un risultato con dieci righe dice che il progetto non è un trasloco ma una piccola ristrutturazione. Il terzo risultato, i server collegati, è quello che più spesso cambia il preventivo, perché dietro a un server collegato c'è quasi sempre un altro sistema: un vecchio gestionale, un foglio, un database di una macchina utensile. Chi lo usa, e cosa si aspetta in cambio, va chiarito prima.

A questo inventario Microsoft aggiunge strumenti di valutazione automatica, che leggono lo schema e producono un elenco di funzioni non compatibili con la destinazione scelta. I nomi degli strumenti cambiano ogni due o tre anni, perché Microsoft li sostituisce: oggi la strada è l'estensione di migrazione per Azure SQL, il servizio Azure Database Migration Service e le valutazioni di Azure Migrate. Usali, perché sono gratuiti e trovano cose che la lettura a occhio non vede, ma non fidarti ciecamente dell'esito "compatibile": un report dice che la sintassi è valida, non che il job notturno finisce nello stesso tempo.

C'è poi una categoria di problemi che nessuno strumento trova: le abitudini. Un gestionale che apre una connessione all'avvio e la tiene aperta tutto il giorno si comporta in un modo, uno che apre e chiude una connessione per ogni clic si comporta in un altro, e in Azure il secondo fa più fatica del primo. Un programma che lancia mille piccole query per riempire una schermata funziona bene con un server a venti metri di distanza e male con uno a venti chilometri. Dei due si parla nella sezione sulla latenza.

Quando il database ha una storia lunga, conviene anche guardare cosa c'è dentro che nessuno usa. Tabelle di prova, viste di un consulente passato, procedure con nomi come "temp_2019_nuova", job disabilitati da anni: nelle migrazioni che ho seguito, fra un quinto e un terzo degli oggetti non era chiamato da nessuno. Eliminarli prima del trasloco riduce il lavoro, il rischio e, in alcuni casi, anche la dimensione del database, che è la voce che incide sul canone. Eliminare non significa cancellare: significa archiviare lo schema in un file, rinominare l'oggetto, aspettare un ciclo di chiusura e solo dopo togliere.

La latenza: il programma resta in sede, il database va a Milano

Il problema che sorprende di più le aziende non è la compatibilità, è la latenza: un programma che fa cento piccole query per riempire una schermata, con un database a pochi metri, impiega 100 millisecondi, e con un database a 15-25 millisecondi di distanza ne impiega due secondi e mezzo. Il vecchio server stava a pochi metri di cavo. Il nuovo sta in un'area cloud, per l'Italia quella di Milano, a qualche decina di chilometri e a più passaggi di rete.

Il tempo di risposta di una singola query cambia poco. Quello che si nota è il numero di query per ogni azione dell'utente. Un gestionale scritto bene ne fa dieci, uno scritto male ne fa duecento perché per ogni riga della lista fa una query per leggere il cliente, una per il listino, una per lo stato. È il problema detto "N+1", che con il database locale non si vede e in Azure salta fuori il primo giorno. Ne parlo in dettaglio in come individuare le query lente in EF Core, ed è la lettura giusta se il tuo gestionale è scritto con Entity Framework.

Il test prima di decidere costa un pomeriggio. Si attiva il tracciamento sulla produzione, si registra una giornata di lavoro e si contano le query per ogni schermata principale. Poi si misura la latenza reale fra l'ufficio e la regione Azure scelta, con un database di prova. Se una schermata fa più di cinquanta query e la latenza è sopra i 15 millisecondi, il tempo di caricamento sale sopra il secondo, e il progetto deve includere l'ottimizzazione del programma. Se il programma non si può toccare, conviene spostare con il database anche il programma, in una macchina nella stessa regione, o tenere il database in sede.

Un secondo effetto della distanza è che la connessione, a differenza di quella locale, può cadere per qualche secondo. In Azure SQL Database capita durante gli aggiornamenti trasparenti, nei cambi di nodo e nelle rare interruzioni di rete. Un programma scritto per un database sempre raggiungibile non ritenta, mostra un errore e l'utente rilancia l'operazione, magari duplicando un ordine. Per questo ogni applicazione .NET va configurata per riprovare in automatico le operazioni che falliscono per cause temporanee. In EF Core è una riga:

using Microsoft.EntityFrameworkCore;

builder.Services.AddDbContext<GestionaleContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("Gestionale"),
        sql => sql.EnableRetryOnFailure(
            maxRetryCount: 5,
            maxRetryDelay: TimeSpan.FromSeconds(10),
            errorNumbersToAdd: null)));

Quella riga non basta se il programma usa transazioni scritte a mano: le operazioni ritentate vanno racchiuse in una strategia di esecuzione, altrimenti EF Core rifiuta di ritentare. È un esempio di lavoro che nessuno inserisce nel preventivo e che va fatto: due-quattro giorni in un gestionale di medie dimensioni. Per un programma in ADO.NET puro, con il vecchio SqlConnection, il lavoro è più lungo, perché il ritento va scritto, o preso da una libreria come Polly.

Il passaggio al cloud è anche l'occasione per sistemare la sicurezza della connessione. La stringa con utente e password, scritta in un file di configurazione, si può sostituire con un'identità gestita: l'applicazione, se gira in Azure, si autentica con il suo nome e non c'è più una password da ruotare, da perdere o da far finire in un repository. Se invece l'applicazione resta in sede, si può usare Microsoft Entra ID con un'identità dedicata, o, nel peggiore dei casi, un utente SQL con una password lunga, tenuta in un deposito di segreti e non in chiaro nel file di configurazione. La stessa attenzione vale per la rete: il database di Azure si apre solo agli indirizzi della sede o, meglio, a un collegamento privato, e mai a tutta internet.

Il grafico qui sopra sintetizza il conto: il tempo di una schermata è il numero di query moltiplicato per la latenza di ciascuna. Con 10 query e 20 millisecondi si arriva a 200 millisecondi e nessuno se ne accorge. Con 200 query si arriva a quattro secondi, e il gestionale sembra rotto. Per questo il primo intervento, se serve, non è sul database ma sul programma, ed è lo stesso lavoro che si fa nei percorsi descritti nella guida alla modernizzazione per piccoli passi con lo Strangler Fig.

Quanto costa far girare il database ogni mese

Un database di un gestionale per quindici-venti utenti in Azure SQL Database costa fra 15 e 150 euro al mese per la maggior parte delle aziende italiane, e salire a 300-400 euro solo se il carico è alto e costante: la cifra dipende da tre leve, la capacità scelta, la riserva di uno o tre anni e lo sconto per la licenza che già possiedi.

Il modello di acquisto è il primo numero da scegliere. Il modello a DTU, con le fasce Basic e Standard, è il più semplice: scegli un livello e paghi una cifra fissa, da circa 5 euro al mese per un database minuscolo a circa 15 euro per il livello S0, 30 per l'S1, 75 per l'S2 e 150 per l'S3. Basta per un gestionale di un'azienda piccola, con pochi utenti contemporanei e un database sotto i 100 gigabyte. Il modello a vCore, con fasce General Purpose e Business Critical, è quello per carichi più alti: si sceglie il numero di core, la memoria è proporzionale e il prezzo parte da qualche centinaio di euro. Esiste anche la versione serverless del vCore, che si ferma da sola dopo un'ora di inattività e paga solo la memoria occupata, adatta a un database usato nelle ore d'ufficio e fermo di notte.

Tre leve riducono il conto senza toccare le prestazioni. La prima è la riserva: impegnarsi per uno o tre anni su una capacità abbassa il prezzo di una quota che va da un quinto a più di un terzo, ma conviene solo quando il carico è stabile e dopo almeno due mesi di misura. La seconda è il vantaggio ibrido: se la tua azienda possiede licenze SQL Server con Software Assurance attiva, puoi portarle su Azure e non pagare la parte di licenza nel prezzo del vCore. Verifica il contratto, perché molte aziende piccole hanno licenze senza Software Assurance e non ne hanno diritto. La terza è la pausa: un database serverless che non lavora di notte non costa.

Esiste infine un'offerta gratuita per iniziare, con una quantità mensile di capacità e di spazio inclusa per ogni abbonamento. Serve per provare, non per la produzione, ma è il modo per fare la prova generale di cui parlo più avanti senza spendere nulla. Il suo limite è che si spegne quando consumi la quantità inclusa: perfetta per un test di compatibilità, da evitare per un database usato davvero.

Ci sono poi i costi che non stanno nel canone e che gonfiano il conto se nessuno li guarda. Il traffico in uscita dal cloud verso la sede si paga a gigabyte dopo una piccola quota gratuita: chi scarica ogni giorno grandi estrazioni verso Excel lo vede in fattura. I backup a lungo termine, oltre il periodo incluso, si pagano a parte. I log di diagnostica inviati a un'area di analisi si pagano a volume. E la replica geografica, che raddoppia il costo della capacità, va attivata solo se serve davvero. Il consiglio che do a tutti è impostare un avviso di spesa al 70 per cento del budget mensile, il primo giorno: costa due minuti e ha evitato più sorprese di qualunque altra misura.

Chi sta valutando più servizi in Azure insieme al database, e si domanda se l'intero conto abbia senso per una PMI, trova i numeri complessivi in Azure per le PMI italiane.

Il confronto su cinque anni: in sede contro Azure

Sui cinque anni, un database in sede costa quasi sempre di più di quanto l'azienda creda, perché nel conto manca il tempo di chi lo cura: server, licenza, ripristino, backup e ore di un sistemista, per un gestionale piccolo, superano i 25.000 euro, contro i 5.000-18.000 di Azure SQL Database più il progetto di migrazione. La difficoltà è che le voci in sede sono sparse: la licenza è stata pagata nel 2016, il server nel 2018, l'assistenza è nel contratto del sistemista e la corrente nella bolletta dell'ufficio. Nessuno le ha mai sommate.

Il confronto non è una verità universale, e conviene dirlo senza giri. Se il carico è alto e costante tutto il giorno, il canone sale e il vantaggio si assottiglia. Se il database è grande, sopra qualche terabyte, la forbice si inverte. Se il server in sede è già pagato e serve per altro, la voce hardware pesa meno. E se hai un sistemista interno che costa già quello che costa e fa tutto bene, le ore non sono una voce evitabile. Il dato che raramente cambia è un altro: in sede il rischio non entra nel conto. Un'ora di fermo di un gestionale con diciotto persone costa quanto l'ora di diciotto persone ferme, e questo, a 25 euro l'ora di costo azienda, sono 450 euro per ogni ora. Una giornata persa vale più di un anno di canone.

Se vuoi un riferimento sui costi del software in generale, non del solo database, la guida a quanto costa il software su misura mette in fila le voci che spesso restano fuori dai preventivi.

Quanto costa il progetto di migrazione

Il progetto di migrazione di un database di medie dimensioni costa dai 6.000 ai 15.000 euro, a 600 euro al giorno, e richiede da due a cinque settimane: la metà del tempo se ne va in compatibilità e collaudo, solo un decimo nello spostamento vero e proprio dei dati. Le cifre sono stime per un database fino a 200 gigabyte, un'applicazione e un massimo di venti oggetti fra job e collegamenti.

Tre fattori fanno salire il totale. Il primo è il numero di sistemi che parlano con il database: ogni sistema collegato è un test in più e a volte un adattatore in più. Il secondo è la qualità dell'applicazione: un programma con SQL scritto dentro i pulsanti, senza livello di accesso ai dati, costa il doppio da adeguare. Il terzo è la finestra di fermo ammessa: se l'azienda può stare ferma una notte, il passaggio si fa con il metodo semplice, se non può stare ferma nemmeno dieci minuti serve la replica continua e il progetto si allunga di una settimana.

Un buon preventivo mette per iscritto cosa è escluso. Escludere, per esempio, l'adeguamento dell'applicazione fa sembrare il progetto più economico e lo lascia con un gestionale lento il primo lunedì. Quando leggi un'offerta, cerca le voci "ritento delle connessioni", "prova generale con i dati veri" e "presidio del primo giorno": se mancano tutte e tre, il prezzo basso è una promessa, non un preventivo.

Per un percorso più ampio, che comprende anche l'applicazione, l'organizzazione e le priorità, il percorso di modernizzazione del software legacy parte dall'inventario e arriva a un piano a tappe, con una stima per ogni tappa.

Il metodo passo per passo: prova generale, passaggio, ritorno indietro

Il metodo che non fa dormire male è sempre lo stesso: si copia il database, si spostano i dati in un ambiente di prova, si fa girare l'applicazione contro la copia in Azure con i dati veri, si confrontano i risultati e solo allora si fissa la notte del passaggio, con un piano scritto per tornare indietro. Nessuna migrazione che ho visto andare male è fallita per un limite tecnico. Sono fallite per una prova generale saltata.

La prima tappa è la copia. Dal backup di produzione si ricostruisce il database su una macchina di prova e si controlla che si ripristini: è la prima verifica che il backup esista e funzioni, e mi è capitato di scoprire, in questo punto, che l'unico backup dell'azienda era corrotto da otto mesi. La seconda tappa è la valutazione di compatibilità con gli strumenti Microsoft e con le tre query viste sopra. La terza è la correzione degli oggetti che non funzionano, un'attività da fare sul database di prova, con il lavoro tracciato in script che si possono rilanciare identici il giorno del passaggio.

La quarta tappa è il vero spostamento dei dati, e qui il metodo dipende dalla destinazione e dal fermo ammesso. Per Azure SQL Database il metodo più semplice è il pacchetto di esportazione e importazione dei dati (il file con estensione bacpac): si esporta lo schema con i dati, si importa in Azure, si controlla. Va bene per database sotto i 100-150 gigabyte e con una notte di fermo ammessa. Per database più grandi, o con fermo di pochi minuti, si usa il servizio di migrazione online di Microsoft, che copia i dati mentre l'azienda lavora, tiene allineate le modifiche e permette di passare al nuovo database con un'interruzione di pochi minuti. Per la Managed Instance si può anche ripristinare direttamente un backup nativo, con un metodo simile a quello conosciuto da chi usa SQL Server da sempre.

La quinta tappa è la prova generale, e merita di essere fatta come se fosse la notte vera. Si prende una copia recente della produzione, la si porta in Azure con la procedura scelta, e si cronometra: quanto dura l'esportazione, quanto l'importazione, quanto la verifica. Poi si fa girare l'applicazione contro il database in Azure e si percorrono i dieci flussi principali, con una persona dell'ufficio. Si confrontano i risultati con quelli della produzione: i totali delle fatture di un mese, il numero di righe delle tabelle principali, il saldo di magazzino di venti articoli a campione. Se un numero non coincide, si indaga prima di andare avanti.

La sesta tappa è la notte del passaggio. Si blocca l'accesso al vecchio database, si fa l'ultimo backup, si esegue la procedura provata, si controllano i numeri, si cambia la stringa di connessione dell'applicazione e si riapre. Se qualcosa non va entro una soglia stabilita in anticipo, per esempio la mezzanotte e mezza, si torna indietro: il vecchio database non si tocca, non si cancella e non si spegne, e basta rimettere la vecchia stringa di connessione. Il vecchio server resta spento ma integro per almeno un mese, e viene eliminato solo dopo una chiusura contabile completa passata senza problemi.

Il passaggio non si fa di venerdì sera, né alla vigilia di una scadenza fiscale, né quando la persona che conosce il gestionale è in ferie. Il momento migliore è l'inizio di un trimestre tranquillo, con un lunedì davanti in cui qualcuno controlla le prestazioni. Alla fine del primo giorno si guarda il pannello di Azure, che mostra utilizzo, query lente e connessioni: se il livello scelto è troppo stretto, lo si alza in pochi minuti, e se è troppo largo lo si abbassa dopo due settimane di misura. È uno dei veri vantaggi del cloud: sbagliare la taglia costa poco e si corregge in fretta, mentre un server in sede sottodimensionato si paga per anni.

Chi sposta il database dovrebbe spostare, o almeno ripensare, anche il modo in cui l'applicazione viene pubblicata, perché i due lavori si aiutano a vicenda. Se l'applicazione è un'applicazione web, la guida a pubblicare applicazioni senza stress descrive come far arrivare le modifiche in produzione con un procedimento ripetibile, e l'articolo su cos'è un'architettura senza server spiega quando conviene delegare al cloud anche la parte di calcolo. Sono due strade che si collegano alla migrazione del database ma non sono obbligatorie: si possono fare in un secondo tempo.

Sicurezza, backup e dati personali: cosa cambia davvero

In Azure SQL Database i backup sono automatici, i dati sono cifrati a riposo senza che tu faccia nulla e il ripristino a un punto preciso degli ultimi 7-35 giorni è incluso, quindi la cosa che più spesso manca nelle aziende italiane, un backup verificato e recente, c'è dal primo giorno. La copia dei dati viene fatta in automatico, con una frequenza decisa da Microsoft, e si può ripristinare un database a un momento di cinque minuti prima di un errore. Chi ha cancellato per sbaglio un cliente alle 15:42 può riavere il database com'era alle 15:41, senza telefonare a nessuno.

Per i dati personali, la regione è una scelta che si controlla. Azure ha un'area in Italia, a Milano, e una in Germania e in Francia. Per un'azienda italiana con dati dei clienti, tenere il database in un'area europea e documentarlo nel registro dei trattamenti è la regola, e scegliere l'Italia semplifica il discorso con clienti che lo chiedono. Verifica sempre che la regione scelta offra il livello di servizio che ti serve, perché non tutte le funzioni sono presenti in tutte le aree, e che la replica geografica, se la attivi, resti dentro l'Europa.

La parte che cambia di più è l'accesso. In sede, il database è raggiungibile da chiunque sia nella rete interna e conosca una password. In Azure, per impostazione predefinita, è protetto da un filtro di rete che lascia passare solo gli indirizzi che indichi, e l'autenticazione può appoggiarsi all'identità aziendale di Microsoft con l'accesso multifattore. Tre regole pratiche: nessun utente condiviso, nessun accesso aperto a tutta internet, nessuna password scritta nel codice. Un accesso di emergenza per l'amministratore, con credenziali custodite in cassaforte, è l'unica eccezione che consiglio.

La sicurezza dei dati non finisce con la scelta della piattaforma. Il database di un'azienda contiene spesso più di quanto serve: codici fiscali conservati in chiaro, note con dati sanitari dei dipendenti, esportazioni vecchie dimenticate in tabelle di appoggio. Il trasloco è il momento giusto per ripulire, e per decidere cosa cifrare a livello di colonna e cosa mascherare nei report. Non è un lavoro obbligatorio per migrare, ma costa poche ore quando lo si fa insieme e molte quando lo si rimanda a un audit.

Quando non conviene migrare

Non conviene spostare il database in Azure quando il carico è alto e costante tutto il giorno, quando il programma fa centinaia di query per schermata e non si può modificare, o quando un prodotto di terze parti è certificato solo su SQL Server installato in sede. In questi casi la strada onesta è un'altra, e la dico spesso ai clienti, anche quando perdo un lavoro.

Il primo caso è il carico costante. Un database usato a pieno ritmo ventiquattr'ore al giorno, con molti core sempre occupati, paga ogni ora di capacità e non beneficia della pausa. Su cinque anni, un server in sede con una buona licenza può costare meno. Il secondo caso è la dipendenza dalla latenza: reparti di produzione con macchine che scrivono nel database ogni secondo, o programmi di cassa che non possono aspettare la rete. Lì il database sta vicino alle macchine, e al massimo si replica una copia in cloud per i report. Il terzo caso è il fornitore: certi gestionali verticali dichiarano il supporto solo su SQL Server installato in un ambiente da loro indicato, e spostare il database fa decadere il supporto. Prima di muovere un dito, un'email al fornitore ti salva da una discussione contrattuale.

Il quarto caso, il più frequente, è l'applicazione con troppe query. Ho visto gestionali con 300 query per aprire una scheda cliente: in sede funzionavano, in Azure no. Se l'applicazione non si può correggere, ci sono due strade: spostare in Azure anche l'applicazione, nella stessa area del database, e far collegare gli utenti da remoto, oppure restare dove si è e aggiornare solo SQL Server. L'aggiornamento in sede, con una versione supportata, un backup esterno e una prova di ripristino al trimestre, è una soluzione dignitosa e costa circa 3.000-5.000 euro. Meglio un database in sede curato che uno in Azure che rallenta il lavoro di diciotto persone.

Un quinto caso, meno ovvio, è l'azienda che non ha nessuno che segua il cloud. Azure non si gestisce da solo: il conto cresce se qualcuno attiva servizi e se ne dimentica, le autorizzazioni si accumulano, e un avviso di spesa ignorato diventa una fattura. Se in azienda non c'è nessuna persona, interna o esterna, con un compito chiaro sul tema, il canone va comprato insieme a una piccola manutenzione mensile. Ne bastano due ore al mese, ma devono essere di qualcuno.

Un caso a parte è quello in cui il database è la parte meno critica del problema. Se il programma è in Access, in Visual Basic 6 o in Delphi, il database è un passaggio e la vera sfida è il programma. In quel caso si parte dal programma: per chi ha un gestionale in Access, la guida a migrazione da Access a SQL Server spiega il percorso, e la destinazione dei dati può già essere Azure SQL fin dall'inizio, saltando un passaggio.

Come uso l'intelligenza artificiale in una migrazione di database

L'intelligenza artificiale fa risparmiare tempo in tre punti di una migrazione SQL Server, la lettura di centinaia di procedure per trovare le funzioni incompatibili, la scrittura dei test di confronto e la riscrittura dei job, e non deve mai decidere da sola cosa si cancella o cosa si sposta. Nelle ultime migrazioni ho usato un assistente per leggere lo schema, e il tempo di inventario è passato da tre giorni a uno.

Il primo uso è la lettura. Un database di quindici anni ha centinaia di procedure e viste, molte scritte da persone diverse, senza documentazione. Esporto gli script, li dò in pasto all'assistente a gruppi, e gli chiedo di elencare per ciascuna cosa fa, quali tabelle tocca e se usa funzioni non compatibili con Azure SQL Database. Il risultato non è affidabile al cento per cento, ma funziona benissimo come primo filtro: le procedure segnalate le leggo io, le altre le controllo a campione. Il secondo uso è la scrittura dei test: per ogni procedura importante l'assistente propone query di confronto fra vecchio e nuovo database, e le verifico a mano su dati reali. Il terzo uso è la riscrittura dei job di SQL Agent in funzioni Azure o in script ripetibili, con la stessa logica ma una forma diversa.

I limiti sono altrettanto chiari. L'assistente non conosce le abitudini dell'azienda: non sa che quella procedura si lancia solo l'ultimo giorno dell'anno, né che un certo cliente ha un trattamento particolare scritto in un'istruzione condizionale. Non può accedere al database di produzione, e non deve: lavora su script esportati, senza dati personali. E non sostituisce la prova generale con i dati veri. Per chi vuole approfondire il metodo, la guida a come usare l'AI per rifattorizzare software legacy spiega regole e limiti nel dettaglio, e vale per il database come per il codice.

Domande frequenti

Quanto costa migrare un database SQL Server verso Azure SQL?

Per un database fino a 200 gigabyte e un'applicazione, il progetto costa da 6.000 a 15.000 euro a 600 euro al giorno, in due-cinque settimane. Il canone mensile parte da 15 euro per i piccoli gestionali e arriva a 300-400 euro con carichi alti.

Qual è la differenza fra Azure SQL Database e Managed Instance?

Azure SQL Database è un database singolo, senza SQL Agent e senza query fra database, ed è il più economico. La Managed Instance è un'istanza completa, quasi identica a un SQL Server, e costa di più. La scelta dipende da quante funzioni del server usi.

Si può migrare senza fermare l'azienda?

Quasi. Con il servizio di migrazione online i dati si copiano mentre si lavora e il fermo si riduce a pochi minuti. Con il metodo semplice serve una notte. In entrambi i casi un piano scritto per tornare indietro rende ogni passo reversibile.

Il mio gestionale funzionerà come prima?

Dipende da quante query fa per ogni schermata. Con un database a qualche decina di chilometri, 200 query per schermata diventano lente. Si misura prima, in un pomeriggio, e si decide se ottimizzare il programma o spostarlo insieme al database.

Cosa succede se la connessione cade?

In Azure può cadere per qualche secondo durante gli aggiornamenti. Un programma ben configurato ritenta da solo. In EF Core basta abilitare la strategia di ritento, in altri programmi va scritta o presa da una libreria.

Devo comprare nuove licenze SQL Server?

No, in Azure SQL Database la licenza è compresa nel canone. Se possiedi licenze con Software Assurance attiva puoi usarle per ridurre il prezzo con il vantaggio ibrido. Verifica il contratto prima di contare su questo sconto.

Conviene aspettare ancora un anno?

Se il tuo SQL Server è fuori supporto, no: ogni mese senza correzioni è un mese di rischio. Il momento migliore è un trimestre tranquillo, finché in azienda c'è ancora qualcuno che conosce il database e i job notturni.

Il passo per lunedì

Non serve decidere oggi. Serve sapere con quali numeri decidere. Lunedì mattina, con un'ora a disposizione, fai quattro cose. Controlla la versione di SQL Server con la query SELECT @@VERSION e confrontala con le date di fine supporto. Lancia le tre query dell'inventario e conta le righe. Chiedi al sistemista, o a chi ne fa le veci, quando è stato fatto l'ultimo ripristino di prova di un backup, e se la risposta è "mai", fallo questa settimana su una macchina di prova. Poi apri il calcolatore di Azure, inserisci dimensione del database e numero di utenti, e scrivi la cifra mensile su un foglio, accanto a quella che oggi spendi in sede senza saperlo.

Se la cifra mensile è bassa, le tre query escono quasi vuote e il backup funziona, hai un progetto da poche settimane. Se escono dieci job e quattro server collegati, hai un progetto con più parti, e conviene dividerlo. Se il backup non si ripristina, hai già trovato la prima cosa da sistemare, a prescindere da dove vivrà il database. Il valore dell'esercizio è che ti dà numeri e non opinioni.

Il responsabile dell'azienda di serramenti ha fatto questo esercizio con me. Il server era un SQL Server 2016, fuori supporto da pochi mesi. Le tre query hanno trovato sei job notturni, nessun collegamento e due riferimenti a un database dimenticato. Il test di latenza ha mostrato che il gestionale faceva 70 query per la schermata degli ordini, e abbiamo ridotto il numero a 18 in tre giorni. Il database è andato su Azure SQL Database con un livello S3, per circa 150 euro al mese, in una notte di sabato, con la prova generale fatta tre settimane prima. Il lunedì successivo il gestionale era più veloce di prima, e per la prima volta in dieci anni l'azienda sapeva dove stava l'ultimo backup.

Se hai un database SQL Server che nessuno vuole toccare e non sai da dove cominciare, vieni a parlarne: nel percorso di modernizzazione del software legacy partiamo dall'inventario, stimiamo costi e tempi delle strade che si adattano al tuo database e decidiamo insieme cosa conviene spostare per primo. La prima conversazione serve a capire se la migrazione ha senso adesso, anche quando la risposta è che puoi aspettare.