Azure SQL è sempre la scelta migliore?
No.
Il cloud non dovrebbe essere considerato automaticamente la destinazione migliore per qualsiasi database.
Bisogna valutare il contesto.
Se un’applicazione viene utilizzata esclusivamente in una sede locale e genera un elevato numero di transazioni verso il database, spostare solo SQL nel cloud potrebbe introdurre problemi di latenza.
Allo stesso modo, un database di grandi dimensioni con carichi prevedibili potrebbe avere un modello di costo diverso rispetto a un’infrastruttura già ammortizzata on-premises.
Una corretta valutazione dovrebbe considerare almeno:
- latenza;
- banda disponibile;
- dipendenze applicative;
- disponibilità richiesta;
- RPO e RTO;
- costi di licenza;
- costi Azure;
- backup;
- disaster recovery;
- requisiti normativi;
- sovranità e localizzazione del dato.
La migrazione al cloud non deve essere una moda.
Deve risolvere un problema concreto o portare un vantaggio misurabile.
Opzione 3: Extended Security Updates tramite Azure Arc
Ma cosa succede se non possiamo aggiornare subito?
È uno scenario molto comune.
Magari il gestionale non supporta ancora SQL Server 2025.
Oppure la migrazione richiede mesi di test.
O ancora, l’azienda sta già pianificando la sostituzione dell’applicativo e non vuole effettuare un upgrade complesso per un sistema destinato a essere dismesso.
In questi casi entrano in gioco gli Extended Security Updates, o ESU.
Per SQL Server 2016, Microsoft mette a disposizione la possibilità di ricevere aggiornamenti di sicurezza estesi fino al 17 luglio 2029.
Uno dei modi più interessanti per accedere agli ESU è attraverso Azure Arc.
Azure Arc permette di collegare ad Azure server e istanze SQL che si trovano fuori dal cloud Azure, comprese infrastrutture:
- on-premises;
- in altri cloud;
- presso datacenter o service provider;
- in ambienti edge.
Attraverso Azure Arc è possibile estendere alcune funzionalità di gestione Azure anche alle risorse esterne al cloud Microsoft.
Nel caso di SQL Server 2016, questo permette di attivare gli Extended Security Updates secondo il modello previsto da Microsoft.
È una soluzione particolarmente interessante quando abbiamo bisogno di tempo.
Ma è fondamentale comprenderne la natura.
Gli ESU sono un ponte, non una destinazione
Questa è probabilmente la considerazione più importante di tutto l’articolo.
Gli Extended Security Updates non modernizzano SQL Server 2016.
Non introducono nuove funzionalità.
Non trasformano un’applicazione legacy in un’applicazione moderna.
Non eliminano le dipendenze da vecchi sistemi operativi o software.
Gli ESU permettono di continuare a ricevere gli aggiornamenti di sicurezza previsti dal programma per un periodo limitato.
In altre parole, comprano tempo.
E comprare tempo può essere una scelta assolutamente corretta, soprattutto quando una migrazione immediata comporterebbe rischi operativi superiori.
Ma quel tempo deve essere utilizzato per realizzare un piano.
Ogni sistema mantenuto in ESU dovrebbe avere almeno:
- un responsabile;
- una motivazione documentata;
- una valutazione del rischio;
- eventuali misure compensative;
- una destinazione futura;
- una data prevista per la migrazione o la dismissione.
Senza questi elementi, gli ESU rischiano semplicemente di rimandare il problema di qualche anno.
E il 2029 arriverà molto più velocemente di quanto sembri.
Azure Arc come strumento per la gestione ibrida
Il ruolo di Azure Arc, però, non si limita agli Extended Security Updates.
Per le aziende con infrastrutture ibride, Azure Arc può rappresentare un punto di controllo centralizzato per portare risorse esterne ad Azure all’interno di un modello di gestione cloud.
Questo approccio diventa particolarmente interessante in ambienti distribuiti, dove possono convivere:
- server on-premises;
- macchine virtuali Azure;
- infrastrutture presso filiali;
- edge computing;
- altri cloud provider;
- istanze SQL distribuite.
L’obiettivo non è necessariamente spostare tutto nel cloud.
È poter applicare un modello di gestione più coerente anche alle risorse che devono restare locali.
Ed è proprio qui che il concetto di hybrid cloud diventa concreto: Azure non è più soltanto una destinazione, ma può diventare anche un piano di controllo per infrastrutture distribuite.
Come preparare una migrazione da SQL Server 2016
Prima di scegliere una tecnologia, il primo passo dovrebbe essere creare un inventario.
In molte aziende il problema non è decidere come migrare SQL Server 2016.
Il problema è sapere quante istanze SQL Server 2016 esistono realmente.
Può capitare di trovare SQL Server installato come componente di:
- gestionali;
- software di backup;
- applicazioni di monitoraggio;
- sistemi di produzione;
- software sviluppati internamente;
- applicativi dipartimentali ormai dimenticati.
Per questo motivo, un percorso di modernizzazione dovrebbe partire da quattro fasi.
1. Inventario
Identificare tutte le istanze SQL Server presenti nell’ambiente, verificando:
- versione;
- edizione;
- sistema operativo;
- database presenti;
- dimensioni;
- applicazioni collegate;
- autenticazione;
- criticità;
- backup.
2. Analisi della compatibilità
Per ogni applicazione bisogna capire quali versioni SQL sono ufficialmente supportate.
Questo significa coinvolgere i fornitori degli applicativi e verificare anche eventuali dipendenze non immediatamente visibili.
3. Definizione della strategia
A questo punto possiamo dividere i sistemi in diverse categorie:
- upgrade immediato;
- migrazione ad Azure SQL;
- migrazione a SQL Server su Azure VM;
- mantenimento temporaneo con ESU;
- dismissione.
Non tutte le istanze devono necessariamente seguire la stessa strada.
4. Backup e disaster recovery
Prima di qualsiasi migrazione, è indispensabile verificare la capacità di ripristino.
Avere un job di backup verde non significa necessariamente avere un backup realmente utilizzabile.
Bisogna verificare:
- integrità dei backup;
- restore effettivo;
- tempi di ripristino;
- dipendenze applicative;
- credenziali;
- certificati;
- chiavi di cifratura;
- procedure operative.
Un backup non testato è soltanto una speranza.
Il momento giusto per decidere è adesso
SQL Server 2016 ha avuto un ciclo di vita molto lungo e ha rappresentato una piattaforma estremamente importante per tantissime aziende.
Ma dal 14 luglio 2026 lo scenario è cambiato.
Continuare a utilizzarlo senza una strategia significa accettare un rischio crescente.
La scelta corretta non è necessariamente migrare tutto immediatamente al cloud.
In alcuni casi sarà più sensato aggiornare a SQL Server 2025.
In altri, Azure SQL Managed Instance o Azure SQL Database potranno offrire vantaggi importanti.
Per altri ambienti ancora, gli Extended Security Updates tramite Azure Arc rappresenteranno il ponte necessario per guadagnare tempo e preparare la migrazione correttamente.
L’importante è che la decisione sia consapevole e documentata.
Perché la domanda non è più:
“SQL Server 2016 funziona ancora?”
La vera domanda è:
“Qual è il nostro piano per continuare a garantire sicurezza, continuità operativa e gestione del rischio dopo la fine del supporto?”
Ed è una domanda alla quale ogni azienda che utilizza ancora SQL Server 2016 dovrebbe iniziare a rispondere oggi.
LINK
https://learn.microsoft.com/it-it/lifecycle/products/sql-server-2016
