Il 14 luglio 2026 rappresenta una data importante per moltissime infrastrutture IT: SQL Server 2016 ha raggiunto la fine del supporto esteso Microsoft.
Una scadenza che potrebbe sembrare semplicemente una delle tante date del ciclo di vita di un prodotto, ma che in realtà riguarda ancora numerose aziende che utilizzano SQL Server 2016 per ospitare database di gestionali, ERP, applicazioni verticali, sistemi di produzione e servizi critici.
Il problema è semplice: SQL Server 2016 continuerà a funzionare, ma senza una copertura Extended Security Updates non riceverà più i normali aggiornamenti di sicurezza previsti dal ciclo di supporto.
In un contesto in cui vulnerabilità, ransomware, supply chain attack e requisiti normativi come quelli introdotti dalla direttiva NIS2 stanno aumentando l’attenzione sulla sicurezza delle infrastrutture IT, continuare a utilizzare un database fuori supporto senza un piano preciso può rappresentare un rischio significativo.
La buona notizia è che esistono diverse alternative.
Possiamo aggiornare a SQL Server 2025, valutare una migrazione verso Azure SQL oppure utilizzare Azure Arc per accedere agli Extended Security Updates e guadagnare il tempo necessario per pianificare la modernizzazione.
Vediamo nel dettaglio cosa significa.
SQL Server 2016: cosa cambia dal 14 luglio 2026?
Microsoft gestisce i propri prodotti attraverso un ciclo di vita che prevede diverse fasi di supporto.
Per SQL Server 2016, il supporto mainstream è terminato il 13 luglio 2021, mentre il supporto esteso è terminato il 14 luglio 2026.
La fine del supporto non significa che il database smetterà di funzionare.
Le istanze continueranno ad avviarsi, le applicazioni continueranno a collegarsi e, salvo altri problemi, gli utenti potranno continuare a lavorare.
Il cambiamento è meno visibile, ma molto più importante dal punto di vista della sicurezza.
Dopo la fine del supporto esteso, SQL Server 2016 non riceve più i normali aggiornamenti di sicurezza gratuiti. Una nuova vulnerabilità scoperta nel prodotto potrebbe quindi rimanere senza una correzione disponibile per le installazioni prive di copertura ESU.
Questo significa che un’infrastruttura apparentemente stabile può diventare progressivamente più esposta con il passare del tempo.
Ed è proprio questo uno degli aspetti più pericolosi del software legacy: il fatto che continui a funzionare può creare una falsa percezione di sicurezza.
Un database fuori supporto è automaticamente non conforme alla NIS2?
Su questo punto è importante essere precisi.
Utilizzare SQL Server 2016 dopo il 14 luglio 2026 non significa automaticamente essere non conformi alla NIS2.
La conformità non dipende semplicemente dal numero di versione di un singolo software. Deve essere valutata considerando il contesto, il rischio, la criticità del sistema, le misure tecniche adottate e le eventuali misure compensative.
Tuttavia, mantenere in produzione un sistema fuori supporto, contenente magari informazioni aziendali critiche, senza aggiornamenti di sicurezza, senza misure compensative e soprattutto senza un piano di rientro documentato può diventare un serio problema.
La NIS2 rafforza infatti l’attenzione su aspetti come:
- gestione e analisi dei rischi;
- sicurezza dei sistemi informatici;
- gestione degli incidenti;
- business continuity e disaster recovery;
- gestione delle vulnerabilità;
- sicurezza della supply chain;
- verifica dell’efficacia delle misure di cybersecurity.
La domanda da porsi, quindi, non dovrebbe essere semplicemente:
“SQL Server 2016 funziona ancora?”
Ma piuttosto:
“Possiamo dimostrare di conoscere e gestire il rischio derivante dall’utilizzo di un sistema fuori supporto?”
Se la risposta è no, il problema non è più soltanto tecnico.
Diventa un rischio aziendale.
Il rischio del legacy: tutto funziona, ma per quanto tempo?
Nella realtà di molte aziende, soprattutto PMI, SQL Server non è sempre considerato come un componente autonomo dell’infrastruttura.
Spesso viene installato insieme a un gestionale o a un’applicazione verticale e poi rimane lì per anni.
Il risultato può essere una catena tecnologica di questo tipo:
Applicazione legacy → SQL Server 2016 → Windows Server datato → sistema di backup non verificato → accesso remoto
Finché tutto funziona, la tendenza naturale è non intervenire.
Ma questa stabilità apparente può nascondere diversi problemi:
- vulnerabilità non corrette;
- sistemi operativi vicini o oltre la fine del supporto;
- incompatibilità con nuove versioni software;
- difficoltà nell’aggiornamento degli applicativi;
- backup mai realmente testati;
- procedure di disaster recovery non documentate;
- dipendenza da hardware obsoleto;
- assenza di competenze sul sistema originale.
Il vero problema del legacy non è semplicemente l’età del software.
È la progressiva riduzione delle opzioni disponibili quando qualcosa va storto.
Quali alternative abbiamo per SQL Server 2016?
Non esiste una soluzione valida per tutte le aziende.
La scelta dipende dall’applicativo, dalla quantità di dati, dalle prestazioni richieste, dalla connettività, dalle licenze, dai requisiti di sovranità del dato e dal tempo disponibile per la migrazione.
Le tre strade principali sono:
- aggiornare verso SQL Server 2025;
- migrare verso Azure SQL;
- utilizzare gli Extended Security Updates tramite Azure Arc come soluzione temporanea.
Analizziamole singolarmente.
Opzione 1: aggiornare a SQL Server 2025
Per chi vuole mantenere i database on-premises oppure su macchine virtuali, SQL Server 2025 rappresenta la destinazione più moderna della piattaforma SQL Server.
Un aggiornamento consente di uscire dalla condizione di prodotto legacy e adottare un motore moderno, supportato e dotato delle funzionalità più recenti in termini di sicurezza, prestazioni, gestione dei dati e integrazione con scenari AI.
Ma attenzione: non bisogna partire dall’upgrade del database.
Bisogna partire dall’applicazione.
La prima domanda da fare è:
L’applicativo che utilizza SQL Server 2016 è certificato e supportato su SQL Server 2025?
Questo aspetto è particolarmente importante nel caso di:
- ERP;
- gestionali;
- software per la logistica;
- applicazioni di produzione;
- software sviluppati internamente molti anni fa;
- applicativi verticali con dipendenze specifiche.
Una versione più recente di SQL Server può introdurre differenze nei livelli di compatibilità, nei comportamenti del query optimizer e nelle funzionalità disponibili.
Per questo motivo, una migrazione dovrebbe prevedere almeno:
- inventario dei database;
- analisi delle dipendenze;
- verifica della compatibilità applicativa;
- test di backup e restore;
- migrazione in ambiente di test;
- test funzionali;
- test delle performance;
- definizione della finestra di cutover;
- piano di rollback.
Quando possibile, il passaggio a una nuova versione SQL può essere anche l’occasione per abbandonare un vecchio server fisico e passare a un’infrastruttura virtualizzata o a una piattaforma più moderna.
Opzione 2: migrare verso Azure SQL
La seconda strada è valutare la migrazione verso i servizi database gestiti di Microsoft Azure.
Quando parliamo genericamente di Azure SQL, però, è importante distinguere le diverse opzioni disponibili.
Tra le principali troviamo:
- Azure SQL Database;
- Azure SQL Managed Instance;
- SQL Server su Azure Virtual Machines.
Non sono la stessa cosa e non rispondono alle stesse esigenze.
Azure SQL Database
Azure SQL Database è un servizio Platform as a Service completamente gestito.
Microsoft si occupa dell’infrastruttura sottostante e di molte attività operative, permettendo all’azienda di concentrarsi maggiormente sul database e sull’applicazione.
Può essere una soluzione interessante per applicazioni moderne e cloud-native, ma richiede un’attenta analisi della compatibilità quando si proviene da un’istanza SQL Server tradizionale.
Azure SQL Managed Instance
Azure SQL Managed Instance offre un livello elevato di compatibilità con SQL Server e può rappresentare una destinazione interessante per applicazioni che utilizzano funzionalità tipiche di un’istanza SQL tradizionale.
Anche in questo caso, però, non bisogna dare per scontata la compatibilità completa.
È necessario verificare:
- funzionalità utilizzate;
- dipendenze tra database;
- SQL Agent Jobs;
- linked server;
- autenticazione;
- integrazioni esterne;
- requisiti di rete;
- latenza applicativa.
SQL Server su Azure Virtual Machines
Esiste poi una terza possibilità: eseguire SQL Server all’interno di una macchina virtuale Azure.
In questo scenario manteniamo un modello Infrastructure as a Service, con un controllo molto simile a quello di una VM on-premises.
Può essere una soluzione utile quando abbiamo bisogno della massima compatibilità con applicazioni legacy o quando non possiamo ancora passare a un servizio PaaS.
