MSSQL 2016 : date de fin de support et alternatives pour votre base de données

Le 14 juillet 2026 a marqué la fin du support étendu de SQL Server 2016 : les correctifs de sécurité ne sont désormais accessibles que via un programme payant, temporaire et soumis à conditions. Pour les organisations qui utilisent encore cette version, l’enjeu est concret : sécuriser la période de transition et choisir une cible adaptée, sans précipiter une migration de base de données qui fragiliserait les applications.

Fin de support SQL Server 2016 : ce qui a changé en juillet 2026

Depuis le 14 juillet 2026, SQL Server 2016 a dépassé la fin de son support étendu. Microsoft ne fournit plus les correctifs de sécurité habituels pour cette version ; les systèmes concernés restent utilisables, mais leur exposition augmente à mesure que de nouvelles vulnérabilités sont découvertes.

La fin du support ne signifie pas que la base s’arrête du jour au lendemain. Elle signifie que l’organisation doit désormais assumer un risque sans mises à jour standard, ou engager une solution de transition. Pour une entreprise fictive comme Atelier Nord, qui exploite encore MSSQL Server 2016 pour sa facturation, la première étape consiste à inventorier les instances et les applications dépendantes.

Un point de calendrier mérite attention : la date s’applique au dernier Service Pack pris en charge. Une instance identifiée simplement comme « SQL Server 2016 » peut être bien plus ancienne et déjà hors support depuis plusieurs années. Le nom du produit ne suffit pas : il faut relever le numéro de build et confirmer le Service Pack installé.

Support standard, support étendu et fin de vie

Le support standard couvre généralement les premières années d’un produit et peut inclure des corrections et des évolutions. Le support étendu se concentre ensuite sur les mises à jour de sécurité ; sa date de fin correspond à la fin de vie indiquée dans le calendrier Microsoft.

Après cette échéance, les Extended Security Updates (ESU) peuvent apporter une protection supplémentaire, mais elles ne constituent pas un prolongement complet du support. Elles fournissent des correctifs de sécurité, sans transformer une version ancienne en plateforme actuelle ni remplacer un plan de migration.

SQL Server 2016 et les dates à connaître avant une migration

La comparaison des versions permet de prioriser les travaux plutôt que de traiter toutes les instances de la même façon. SQL Server 2017 arrivera à son tour en fin de support étendu le 12 octobre 2027, tandis que SQL Server 2019 ne reçoit déjà plus que des mises à jour de sécurité depuis la fin de son support standard.

Les seules versions encore en support standard dans ces données sont SQL Server 2022 et SQL Server 2025. Les dates de 2016 et des versions antérieures concernent le dernier Service Pack ; celles de SQL Server 2017 et des versions plus récentes s’appliquent à l’ensemble de la version, Microsoft ayant abandonné les Service Packs au profit des mises à jour cumulatives.

Autre vérification souvent oubliée : la plateforme Windows Server qui héberge la base. Windows Server 2016 arrive en fin de support le 12 janvier 2027 ; renouveler SQL Server sans examiner le système d’exploitation peut donc simplement déplacer le problème.

ESU pour SQL Server 2016 : une protection limitée dans le temps

Les ESU de SQL Server 2016 sont prévues jusqu’au 17 juillet 2029, sur une période pouvant aller jusqu’à trois années et achetée par tranches annuelles. Elles ne couvrent pas toutes les installations : les conditions indiquées concernent les éditions Enterprise et Standard exécutant le Service Pack 3.

Des clients éligibles disposant de Software Assurance dans le cadre d’un contrat Enterprise peuvent acheter et déployer des mises à jour de sécurité étendues activées par Azure Arc, dans des environnements locaux ou hébergés. Cette option propose une gestion centralisée et un modèle avec paiement à l’usage ; les achats classiques via le Centre de gestion des licences en volume suivent des modalités annuelles. Les conditions et la facturation doivent être confirmées auprès de Microsoft.

Les ESU constituent un pont, pas une destination. Atelier Nord pourrait s’en servir pour maintenir temporairement sa facturation pendant les tests de compatibilité, à condition de vérifier l’éligibilité et de fixer une date de sortie ferme. Sans calendrier de migration, chaque année achetée repousse la décision sans résoudre la dette technique.

Vérifications à effectuer avant d’acheter des ESU

• Identifier la version exacte : relever le numéro de build et confirmer l’installation du Service Pack 3.
• Contrôler l’édition : vérifier que l’instance utilise Enterprise ou Standard, selon les conditions du programme.
• Évaluer le canal d’achat : comparer les options Azure Arc et les modalités annuelles de licences en volume.
• Associer une échéance de sortie : planifier le remplacement avant la fin de la couverture, fixée au 17 juillet 2029.

Pour SQL Server 2014, les ESU s’arrêtent le 12 juillet 2027 et aucune protection de ce type n’est indiquée ensuite. Le programme SQL Server 2012 est terminé depuis le 8 juillet 2025 ; les instances plus anciennes ne disposent donc plus de cette voie de transition.

Alternatives à SQL Server : choisir entre mise à niveau et changement de plateforme

La bonne cible dépend des applications, des compétences disponibles, des exigences de disponibilité et du coût total d’exploitation. Une migration vers une version récente de SQL Server préserve souvent davantage de compatibilité ; changer de moteur peut apporter d’autres avantages, mais demande un examen plus profond du code et des processus.

SQL Server 2022 ou SQL Server 2025

Pour les applications fortement liées à l’écosystème Microsoft, SQL Server 2022 peut offrir une trajectoire de mise à niveau avec des échéances de support connues jusqu’en 2033. SQL Server 2025 étend davantage l’horizon annoncé, avec un support étendu jusqu’au 6 janvier 2036. Le choix doit toutefois être validé avec les versions de Windows Server, les pilotes, les outils de sauvegarde et les dépendances applicatives.

Avant la bascule, un environnement de test permet de repérer les changements de comportement, les requêtes lentes et les incompatibilités. Une migration réussie ne se mesure pas seulement à l’ouverture de la base : elle doit aussi préserver les traitements métiers, les sauvegardes et les procédures de restauration.

Azure SQL Database et les solutions hébergées

Azure SQL Database peut convenir aux applications qui peuvent adopter un service de base de données géré. L’exploitation de l’infrastructure est alors prise en charge en partie par le fournisseur, mais la compatibilité doit être évaluée : certaines fonctionnalités ou configurations d’une instance SQL Server locale ne se transposent pas directement.

Pour une base nécessitant davantage de contrôle au niveau de l’instance, une option Azure conçue pour cette compatibilité peut être étudiée. Dans les deux cas, il faut comparer les coûts récurrents, les exigences réseau, la résidence des données, les sauvegardes et les engagements de disponibilité. Le cloud déplace une partie des responsabilités ; il ne supprime pas la nécessité d’une architecture maîtrisée.

PostgreSQL et MySQL pour une modernisation plus large

PostgreSQL et MySQL figurent parmi les alternatives à SQL Server, notamment lorsque l’organisation souhaite réduire sa dépendance à un fournisseur ou s’appuyer sur des compétences et outils différents. Le passage à un autre moteur peut cependant nécessiter de réécrire des procédures stockées, des fonctions, des requêtes spécifiques et des intégrations applicatives.

Pour Atelier Nord, une application de facturation simple pourrait être candidate à une migration vers PostgreSQL ou MySQL après un audit, tandis qu’un système reposant fortement sur des fonctionnalités Microsoft pourrait rester sur SQL Server. La modernisation des bases de données commence par les usages réels, pas par le nom du moteur.

Préparer la migration de base de données sans interrompre les activités

Une transition solide suit des étapes vérifiables. Le piège consiste à migrer d’abord et à découvrir ensuite qu’un rapport, une tâche planifiée ou une application secondaire dépendait d’un comportement non documenté.

1. Inventorier les instances : relever les versions, builds, éditions, volumes et systèmes d’exploitation associés.
2. Cartographier les dépendances : associer chaque base aux applications, comptes de service, sauvegardes, tâches et rapports qui l’utilisent.
3. Classer les risques : prioriser les instances exposées à Internet, critiques pour l’activité ou déjà privées de correctifs.
4. Tester la cible : mesurer la compatibilité, les performances et le comportement des traitements sur une copie représentative.
5. Répéter la bascule : simuler la migration et le retour arrière avant toute intervention en production.
6. Valider après transfert : contrôler l’intégrité, les droits, les sauvegardes et les indicateurs de performance.

Un test de restauration est aussi important que la migration elle-même. Si la sauvegarde ne peut pas être restaurée dans des délais acceptables, la base n’est pas prête pour une bascule, quelle que soit la qualité du nouvel environnement.

Sécurité des bases de données : réduire le risque pendant la transition

Une instance hors support ne devient pas automatiquement vulnérable à chaque instant, mais elle ne bénéficie plus des correctifs standard publiés pour la version. La sécurité des bases de données doit alors s’appuyer sur une réduction concrète de l’exposition, en parallèle d’une migration planifiée.

Les mesures de confinement ne remplacent pas les mises à jour. Elles peuvent néanmoins limiter les chemins d’accès pendant une période transitoire : isoler le serveur sur le réseau, restreindre les connexions entrantes, appliquer le principe du moindre privilège, surveiller les journaux et vérifier régulièrement les sauvegardes restaurables.

Pour une instance sans ESU, la direction informatique doit formaliser le risque accepté, désigner un responsable et fixer une date de sortie. Une échéance sans responsable reste une intention ; une échéance inscrite dans un plan de changement devient une action pilotable.

Questions fréquentes sur la fin de support de SQL Server 2016

SQL Server 2016 est-il encore pris en charge ?

Non. Le support étendu a pris fin le 14 juillet 2026. Des ESU peuvent fournir des correctifs de sécurité jusqu’au 17 juillet 2029 aux installations éligibles, notamment Enterprise ou Standard avec Service Pack 3.

Jusqu’à quand les ESU de SQL Server 2016 sont-elles disponibles ?

Le programme s’étend jusqu’au 17 juillet 2029, sur une durée maximale de trois années. Les conditions d’éligibilité et le canal d’achat doivent être vérifiés avant de bâtir le calendrier de transition.

Quelle version de SQL Server choisir après 2016 ?

SQL Server 2022 et SQL Server 2025 sont des cibles possibles. Le choix dépend de la compatibilité applicative, de l’infrastructure et de l’horizon de support recherché ; les services Azure, PostgreSQL ou MySQL peuvent aussi être évalués.

Quelle est la prochaine version à atteindre la fin du support étendu ?

SQL Server 2017 atteindra la fin de son support étendu le 12 octobre 2027. Microsoft n’a pas annoncé d’ESU pour cette version ou les versions ultérieures dans les informations disponibles ici.

Peut-on migrer directement SQL Server 2016 vers PostgreSQL ou MySQL ?

C’est possible dans certains projets, mais la migration demande un audit des requêtes, procédures stockées, fonctions et dépendances applicatives. Un prototype et des tests de charge permettent de mesurer l’effort avant de choisir cette voie.