Le 14 juillet 2026, le support étendu de SQL Server 2016 prendra fin. Pour les organisations qui utilisent encore cette version, l’enjeu dépasse la mise à niveau technique : il s’agit de préserver la sécurité des données, de maîtriser les risques et de choisir une trajectoire réaliste, qu’elle passe par une migration, une modernisation ou un sursis encadré.
L’article en bref
La fin de support de SQL Server 2016 appelle une décision préparée plutôt qu’une réaction dans l’urgence. Plusieurs voies permettent de maintenir la protection des bases, mais elles ne répondent pas aux mêmes contraintes techniques et budgétaires.
- Échéance à anticiper : Le support étendu s’achève le 14 juillet 2026.
- Options à comparer : Mise à niveau, Azure SQL, machine virtuelle ou ESU.
- Protection transitoire : Les ESU fournissent des correctifs de sécurité limités.
- Migration préparée : Évaluez compatibilité, sauvegardes, dépendances et exigences de conformité.
À retenir : une solution temporaire peut réduire le risque, mais ne remplace pas un plan de modernisation.
SQL Server 2016 : que signifie la fin de support en 2026 ?
SQL Server suit un cycle de vie qui comprend normalement cinq ans de support standard, puis cinq ans de support étendu. Le premier couvre notamment des mises à jour fonctionnelles et de sécurité ; le second se concentre sur les correctifs de sécurité. Pour SQL Server 2016, cette période étendue se termine le 14 juillet 2026.
Après cette échéance, Microsoft ne publiera plus de correctifs de sécurité réguliers pour cette version et le support technique sera fortement limité. La base de données ne s’arrête pas pour autant : elle peut continuer à fonctionner, mais les vulnérabilités découvertes ensuite risquent de rester sans correctif, ce qui complique la gestion des vulnérabilités et peut peser sur la conformité réglementaire.
Fin de support de SQL Server 2016 : quels risques pour la sécurité des données ?
Le risque principal n’est pas une panne automatique au lendemain de l’échéance. Il s’installe plutôt dans le temps : un serveur exposé à une faille nouvellement découverte devient plus difficile à défendre, surtout si ses accès réseau, ses comptes ou ses logiciels associés ne sont pas régulièrement réévalués.
Une sauvegarde des données reste indispensable pour se relever d’une erreur, d’une panne ou d’une attaque. Elle ne corrige toutefois pas une vulnérabilité du moteur SQL Server. De même, le chiffrement des données protège certaines informations en cas d’accès non autorisé, mais il ne remplace ni les correctifs ni une gestion stricte des privilèges.
Dans une entreprise fictive de logistique, une application de gestion des expéditions peut dépendre d’une version ancienne de SQL Server et d’un connecteur spécifique. La priorité consiste alors à inventorier ces dépendances, vérifier les copies de sauvegarde et tester la restauration avant de choisir une destination : déplacer une base sans comprendre ce qui l’utilise, c’est risquer de déplacer le problème avec elle.
Quelles options après la fin de support de SQL Server 2016 ?
Le choix dépend surtout du niveau de changement acceptable. Une application ancienne qui exige un contrôle complet du système n’a pas les mêmes besoins qu’un service récent pouvant être adapté à une base managée. Le tableau suivant permet de comparer les grandes orientations.
| Option | Adaptée si… | À examiner avant de décider |
|---|---|---|
| Mise à niveau sur site | Vous souhaitez conserver une infrastructure locale et une instance SQL Server classique. | Compatibilité de Windows Server, matériel, temps d’arrêt et tests applicatifs. |
| Azure SQL Managed Instance | Vous cherchez une migration vers un service géré, proche d’une instance SQL Server. | Fonctionnalités non prises en charge, réseau, performances et coût récurrent. |
| Azure SQL Database | Vous pouvez moderniser l’application autour d’une base gérée, notamment avec Hyperscale. | Écarts au niveau de l’instance, requêtes inter-bases et tâches SQL Agent. |
| SQL Server sur machine virtuelle Azure | Vous avez besoin de conserver le contrôle du système d’exploitation ou de déplacer rapidement une charge de travail. | Vous restez responsable de l’administration du système et de SQL Server. |
| Mises à jour de sécurité étendues | La migration doit être différée pour des raisons techniques ou métier. | Éligibilité, coût, durée limitée et périmètre réduit aux correctifs de sécurité concernés. |
Azure SQL Managed Instance et Azure SQL Database sont des services gérés : Microsoft prend en charge une partie de la maintenance de la plateforme, mais les besoins de migration et les responsabilités de l’organisation ne disparaissent pas. Une machine virtuelle Azure offre davantage de contrôle, au prix d’une administration plus proche de celle d’un serveur traditionnel.
Moderniser sur place ou migrer vers Azure SQL
Une mise à niveau vers une version prise en charge de SQL Server conserve un environnement familier et donne accès aux fonctions de la nouvelle version. Elle demande toutefois de vérifier l’état du système d’exploitation : si celui-ci est lui aussi ancien, le chantier peut concerner à la fois Windows Server, le moteur de base de données et l’application.
La migration de base de données vers un service Azure peut réduire la charge liée au matériel, aux sauvegardes et aux correctifs de plateforme, selon le service retenu. Avant de déplacer une application vers une instance managée ou une base Hyperscale, il faut notamment tester ses requêtes, ses tâches automatisées, ses connexions et ses besoins de performance. Des outils d’évaluation de migration Microsoft peuvent aider à repérer certaines incompatibilités en amont.
Utiliser les mises à jour de sécurité étendues comme transition
Les mises à jour de sécurité étendues, ou ESU, peuvent prolonger temporairement la réception de certains correctifs après la fin du support. Pour SQL Server 2016, la couverture peut s’étendre sur une durée maximale de trois ans, sous réserve des conditions d’éligibilité et de souscription applicables. Les ESU ne rétablissent pas le support complet : elles n’apportent ni nouvelles fonctionnalités ni correctifs généraux pour les problèmes non liés à la sécurité.
Les modalités varient selon le mode d’hébergement et le contrat. Pour les environnements locaux ou hébergés, Azure Arc peut proposer aux clients éligibles une gestion des ESU avec une facturation par abonnement ; d’autres modalités peuvent passer par les canaux de licences Microsoft. Il est donc prudent de vérifier les conditions commerciales et techniques correspondant précisément à votre contrat, plutôt que de traiter les ESU comme une prolongation automatique.
Ce sursis est utile si une application doit être recertifiée ou si une migration nécessite davantage de temps. Il doit s’accompagner d’une date de sortie, d’un budget et d’un calendrier : sans ces repères, la solution provisoire risque de devenir une dépendance durable.
Préparer une migration SQL Server 2016 sans fragiliser l’exploitation
Une transition réussie commence par un inventaire précis, pas par le choix d’une plateforme. Recensez les bases, leur taille, leurs dépendances, les applications qui les utilisent et les contraintes de disponibilité. Pour une équipe réduite, ce travail permet aussi de distinguer les systèmes réellement critiques des bases qui peuvent être migrées plus simplement.
- Inventorier l’existant : versions, bases, serveurs liés, tâches planifiées, comptes et applications connectées.
- Évaluer les dépendances : repérer les fonctions SQL Server et les composants qui risquent de ne pas être pris en charge à destination.
- Protéger les données : contrôler les sauvegardes, tester une restauration et confirmer les règles de rétention.
- Comparer les destinations : mettre en regard mise à niveau locale, machine virtuelle, Azure SQL Managed Instance et Azure SQL Database.
- Tester avant bascule : mesurer les performances, valider les traitements métier et prévoir un retour arrière.
- Documenter la conformité : vérifier les exigences de conservation, d’accès et de chiffrement des données.
Une migration pilote sur une base représentative révèle souvent les difficultés que les fiches techniques ne montrent pas : requête lente, dépendance oubliée ou fenêtre de maintenance trop courte. Ce test permet d’ajuster le plan avant de toucher aux bases les plus sensibles.
Comment choisir la bonne trajectoire pour SQL Server 2016 ?
Le bon choix n’est pas nécessairement la migration la plus ambitieuse. Si l’application dépend fortement de fonctions au niveau de l’instance ou exige un accès système, une machine virtuelle peut constituer une étape pragmatique. Si l’objectif est de réduire l’administration quotidienne, un service managé mérite d’être évalué, à condition que ses différences fonctionnelles soient compatibles avec l’usage réel.
Pour l’entreprise fictive de logistique, une approche progressive peut commencer par l’analyse d’une base non critique, puis par la validation des échanges avec l’application. Les systèmes qui ne peuvent pas migrer avant l’échéance peuvent rester couverts par des ESU, si l’organisation y est éligible, tandis qu’un plan daté prépare leur sortie. La décision devient alors un arbitrage documenté entre risque, coût et continuité de service.
Les questions à poser avant de valider le projet
Demandez-vous quelles fonctions SQL Server sont réellement utilisées, quelle interruption l’activité peut tolérer et qui sera responsable des correctifs après migration. Vérifiez également si vos exigences de conformité imposent un hébergement ou des contrôles particuliers : la plateforme choisie doit pouvoir s’inscrire dans ces règles, et pas seulement réussir un test technique.
La sécurité ne repose pas sur une seule mesure. Des mises à jour adaptées, des accès limités, le chiffrement des données, une sauvegarde des données testée et un suivi régulier des vulnérabilités composent une défense cohérente, que la base soit locale ou hébergée dans le cloud.
Questions fréquentes sur la fin de support de SQL Server 2016
Quand SQL Server 2016 arrive-t-il en fin de support ?
La fin du support étendu est fixée au 14 juillet 2026. Après cette date, les mises à jour de sécurité régulières et le support associé à cette période ne sont plus fournis pour SQL Server 2016.
Une instance SQL Server 2016 cessera-t-elle de fonctionner après cette date ?
Non. Le moteur peut continuer à fonctionner, mais l’absence de correctifs de sécurité réguliers augmente le risque au fil du temps. Il faut planifier une mise à niveau, une migration ou une couverture ESU si l’organisation y est éligible.
Que couvrent les mises à jour de sécurité étendues ?
Les ESU donnent accès, pour une durée limitée et selon les conditions applicables, à certains correctifs de sécurité. Elles ne comprennent pas de nouvelles fonctionnalités ni une maintenance complète du produit.
Faut-il migrer vers Azure SQL pour rester protégé ?
Non. Une mise à niveau vers une version prise en charge de SQL Server peut aussi convenir. Azure SQL Managed Instance, Azure SQL Database et les machines virtuelles Azure sont des options à comparer selon les dépendances applicatives, le niveau de contrôle recherché et les coûts.
Les sauvegardes suffisent-elles à protéger une base qui n’est plus prise en charge ?
Non. Elles facilitent la restauration après une panne ou une perte de données, mais elles ne corrigent pas les vulnérabilités du moteur. Elles doivent compléter les mises à jour, les contrôles d’accès, le chiffrement et un plan de migration.
Je suis Thomas Vasseur, rédacteur spécialisé high-tech, passionné de son et d’image depuis toujours. Hi-fi, casques, home-cinéma, multiroom, objets connectés : j’écris des guides clairs pour aider chacun à bien choisir et bien installer son matériel, sans jargon ni snobisme audiophile. Sur Enceinte Monitor, j’explique, je compare et je teste — en toute indépendance.
