SQL Server 2016 n’est plus pris en charge : risques et options de migration
Le support étendu de SQL Server 2016 a pris fin le 14 juillet 2026.
Une base de données ne cesse pas de fonctionner parce qu’une date de cycle de vie est passée. Le risque est plus discret : la plateforme ne reçoit plus le niveau normal de mises à jour de sécurité, de correctifs et de soutien Microsoft.
Pour une PME, SQL Server est rarement visible pour les utilisateurs. Il se trouve derrière une application comptable, un logiciel de gestion, un système de production, un dossier client, un outil immobilier ou une intégration développée sur mesure. Cette invisibilité explique pourquoi les migrations sont souvent repoussées.
La première question n’est pas « quelle version installer? ». C’est « quelles applications et données dépendent réellement de cette instance? »
SQL Server 2016 peut être installé à plusieurs endroits
Une entreprise peut utiliser SQL Server 2016 sans le savoir clairement.
Il peut être installé :
- sur un serveur Windows dédié;
- sur le même serveur que l’application;
- dans une machine virtuelle;
- sur un ancien poste de travail utilisé comme serveur;
- sous forme SQL Server Express intégré à un logiciel;
- dans plusieurs succursales;
- dans un environnement de test oublié;
- comme dépendance d’un outil de sauvegarde, de surveillance ou de gestion.
L’inventaire doit couvrir les moteurs SQL, les instances nommées, les bases attachées, les services et les applications qui s’y connectent.
Ce qu’il faut inventorier
Pour chaque instance SQL Server 2016, relevez :
- l’édition : Express, Standard, Enterprise ou autre;
- la version exacte et le niveau de correctifs;
- le système d’exploitation hôte;
- le serveur physique ou virtuel;
- les bases de données;
- leur taille et croissance;
- les méthodes d’authentification;
- les comptes de service;
- les travaux SQL Agent;
- les liens vers d’autres serveurs;
- les rapports, imports et exports;
- les applications clientes;
- les fournisseurs responsables;
- la méthode de licence;
- les sauvegardes et derniers tests de restauration;
- les exigences de disponibilité et d’arrêt.
Il faut aussi chercher les bases inactives, car une base « inutilisée » peut être la seule copie d’un historique nécessaire à l’entreprise.
Le vrai risque vient des applications dépendantes
Une migration SQL n’est pas seulement une opération de base de données.
L’application peut dépendre :
- d’une version précise du moteur;
- d’un pilote ancien;
- d’un mode de compatibilité particulier;
- d’un compte SQL codé dans un fichier de configuration;
- d’une procédure stockée personnalisée;
- d’un travail planifié;
- d’un chemin de fichiers local;
- d’une intégration avec Excel, Access ou un service Windows;
- d’un fournisseur qui impose sa propre procédure de mise à niveau.
Avant de changer la plateforme, obtenez les exigences écrites du fournisseur de l’application. Une migration techniquement réussie peut tout de même rendre l’application non prise en charge.
Option 1 : migrer vers une version prise en charge
La solution durable est généralement de déplacer les bases vers une version de SQL Server prise en charge ou vers une plateforme de données compatible avec l’application.
Le projet devrait inclure :
1. vérification de la compatibilité fournisseur; 2. inventaire des fonctions SQL utilisées; 3. test de sauvegarde et restauration; 4. installation de la nouvelle plateforme; 5. copie ou restauration des bases dans un environnement de test; 6. validation de l’application; 7. mesure des performances; 8. plan de basculement; 9. retour arrière documenté; 10. retrait contrôlé de l’ancienne instance.
La version la plus récente n’est pas automatiquement la bonne destination. Elle doit être prise en charge par l’application, le système d’exploitation et le modèle de licence retenu.
Option 2 : utiliser les ESU comme pont temporaire
Microsoft offre des mises à jour de sécurité étendues pour SQL Server 2016 pendant une période limitée.
Selon le cycle publié, la première année ESU commence après la fin du support étendu et se termine le 13 juillet 2027. Des années supplémentaires sont prévues jusqu’en 2029 pour les organisations admissibles.
Les ESU sont une mesure de transition. Elles couvrent des mises à jour de sécurité définies par Microsoft, mais ne fournissent pas :
- de nouvelles fonctions;
- les correctifs non liés à la sécurité demandés par le client;
- les changements de conception;
- un remplacement complet du soutien normal.
Une organisation qui choisit ESU devrait avoir en parallèle une date de migration, un propriétaire et un budget. Sans cela, le coût supplémentaire ne fait que déplacer l’échéance.
Option 3 : retirer ou remplacer l’application
Certaines bases existent uniquement parce qu’une application ancienne n’a jamais été réévaluée.
Il peut être plus logique de :
- remplacer le logiciel par une version actuelle;
- migrer vers un service SaaS;
- exporter les données historiques;
- conserver une copie en lecture seule dans un environnement contrôlé;
- retirer complètement l’application.
Cette décision doit être prise avec les responsables métier. Une base techniquement active n’est pas nécessairement une charge de travail encore utile.
Sauvegarder une base n’est pas suffisant
Une sauvegarde SQL doit être restaurée et validée.
Le test devrait confirmer :
- que le fichier de sauvegarde est lisible;
- qu’il contient le point attendu;
- qu’il peut être restauré sur la plateforme cible;
- que les comptes, utilisateurs et permissions sont compris;
- que les travaux et configurations hors base sont documentés;
- que l’application peut se connecter;
- que les données critiques sont cohérentes;
- que le temps de restauration est acceptable.
Une base restaurée sans les identifiants, clés, travaux, liens ou fichiers associés peut rester inutilisable.
Consultez aussi notre guide sur les tests de restauration.
Éviter la migration d’urgence
Une migration précipitée augmente les risques de :
- fenêtre d’arrêt mal estimée;
- sauvegarde incomplète;
- oubli d’une instance secondaire;
- perte de travaux planifiés;
- problèmes de pilotes;
- erreurs de licence;
- lenteur inattendue;
- retour arrière impossible;
- dépendance excessive envers une seule personne.
Le meilleur moment pour tester est pendant que l’ancien système fonctionne encore.
Une revue ciblée peut clarifier la décision
Une revue de l’environnement TI peut identifier les instances SQL Server 2016, les applications dépendantes, les sauvegardes et les options réalistes.
Pour préparer la revue, rassemblez :
- le nom du serveur;
- le nom de l’application;
- le fournisseur;
- les rapports de sauvegarde;
- les périodes où un arrêt est possible;
- les contraintes de licence;
- les personnes qui utilisent les données;
- les exigences de conservation.
Communiquer avec Montréal TI pour définir une portée et un plan de migration.