Windows Server 2016 arrive en fin de support : que faire avant janvier 2027?
Le support étendu de Windows Server 2016 prend fin le 12 janvier 2027.
Cela ne signifie pas que le serveur s’arrêtera le lendemain. Les fichiers, applications et services peuvent continuer à fonctionner. Le changement important est ailleurs : Microsoft ne fournira plus les mises à jour de sécurité et le soutien standard associés à cette version.
Pour une PME, le vrai danger n’est donc pas une date abstraite. C’est de découvrir trop tard qu’un serveur 2016 héberge encore plusieurs fonctions critiques, dépend d’une application ancienne, utilise une méthode de sauvegarde jamais testée ou ne peut pas être remplacé pendant une courte fenêtre d’arrêt.
Une migration raisonnable commence par comprendre ce que le serveur fait réellement.
Pourquoi attendre jusqu’à la dernière minute coûte plus cher
Un projet de remplacement devient risqué lorsqu’il doit être exécuté sous pression.
Les problèmes les plus fréquents ne viennent pas de l’installation du nouveau système d’exploitation. Ils viennent des dépendances cachées :
- application métier dont le fournisseur n’existe plus;
- base de données locale oubliée;
- tâches planifiées exécutées sous un ancien compte;
- partage utilisé par un copieur, un logiciel comptable ou un équipement spécialisé;
- certificat ou clé de licence lié au nom du serveur;
- service DNS, DHCP ou Active Directory installé « temporairement » il y a plusieurs années;
- sauvegarde qui copie des fichiers, mais ne permet pas de restaurer le service complet;
- espace disque, mémoire ou matériel insuffisant pour une transition propre.
Plus ces dépendances sont découvertes tôt, plus il existe d’options. Découvertes pendant une panne, elles dictent souvent la solution la plus rapide plutôt que la meilleure.
Première étape : inventorier les rôles et les charges de travail
Le nom du serveur ne dit pas toujours ce qu’il fait.
L’inventaire devrait confirmer au minimum :
- l’édition et le niveau de correctifs de Windows Server 2016;
- le matériel physique ou l’hyperviseur qui l’héberge;
- les rôles Windows installés;
- les services et applications qui démarrent automatiquement;
- les partages, permissions et quotas;
- les bases de données et moteurs utilisés;
- les tâches planifiées;
- les certificats;
- les ports et connexions vers d’autres systèmes;
- les comptes de service;
- les licences et contrats de soutien;
- les sauvegardes, rétentions et derniers tests de restauration;
- les utilisateurs, sites ou processus qui dépendent du serveur.
Il faut aussi déterminer si le serveur est encore nécessaire. Une migration n’est pas toujours un remplacement un pour un. Certaines fonctions peuvent être retirées, regroupées ou déplacées vers un service déjà utilisé par l’entreprise.
Ne pas confondre mise à niveau et migration complète
Une mise à niveau sur place peut sembler plus simple parce qu’elle conserve le serveur existant. Elle conserve aussi ses anciennes configurations, ses logiciels inutiles et certaines dépendances mal documentées.
Une migration vers une nouvelle machine virtuelle ou un nouveau serveur permet souvent de :
- construire une plateforme propre;
- valider les applications avant le basculement;
- transférer les données par étapes;
- conserver l’ancien système comme référence pendant une courte période contrôlée;
- définir un retour arrière plus clair;
- réduire le risque de transformer un serveur fonctionnel en serveur impossible à démarrer.
Le bon choix dépend de la charge de travail, du chemin de mise à niveau pris en charge, des licences, du matériel et des exigences du fournisseur de l’application. Il ne faut pas présumer qu’un chemin est valide uniquement parce qu’un programme d’installation accepte de démarrer.
Choisir la destination selon les besoins réels
La destination peut être :
- une version prise en charge de Windows Server sur du matériel existant compatible;
- une nouvelle machine virtuelle sur l’infrastructure locale;
- un nouveau serveur physique;
- Azure ou un autre environnement infonuagique lorsque la charge s’y prête;
- un service SaaS qui remplace une ancienne application locale;
- la retraite complète du service.
Le choix devrait tenir compte de :
- la compatibilité de l’application;
- la durée de vie du matériel;
- la capacité de sauvegarde et de reprise;
- les besoins de performance;
- la connexion Internet;
- les coûts de licence et d’exploitation;
- la dépendance envers un seul fournisseur;
- les exigences de conservation et de confidentialité;
- les compétences nécessaires pour maintenir la nouvelle plateforme.
Le nuage n’est pas automatiquement la meilleure réponse, et rester sur place n’est pas automatiquement plus simple. La bonne architecture est celle qui réduit le risque tout en restant exploitable par l’organisation.
Les sauvegardes doivent être testées avant le changement
Avant toute migration, il faut prouver qu’une restauration est possible.
Une coche verte dans une console ne suffit pas. Le test devrait confirmer :
- qu’un point de restauration récent existe;
- que les données attendues sont présentes;
- que les clés et comptes nécessaires sont accessibles;
- qu’une machine ou une application restaurée peut démarrer;
- que les permissions et services critiques fonctionnent;
- que le délai de reprise est compatible avec l’entreprise.
Notre guide sur les tests de restauration explique pourquoi un travail de sauvegarde réussi n’est pas la même chose qu’une reprise réussie.
Contrôleur de domaine
Un contrôleur de domaine ne devrait pas être traité comme un simple serveur de fichiers. Il faut vérifier la santé d’Active Directory, la réplication, DNS, les rôles FSMO, l’heure, les sauvegardes d’état système et la présence d’au moins une stratégie de récupération documentée.
Serveur de fichiers
La migration doit préserver les permissions, les chemins utilisés par les applications, les quotas, les fichiers ouverts et parfois les noms réseau attendus par les utilisateurs ou équipements.
Serveur d’application
Il faut obtenir les exigences officielles du fournisseur : version de Windows prise en charge, version de SQL, méthode de licence, composants requis, procédure de sauvegarde et validation après migration.
Ancien serveur physique
Un serveur 2016 installé sur du matériel du même âge peut cumuler deux échéances : fin du support logiciel et risque de panne matérielle. La disponibilité des pièces, le stockage, les contrôleurs RAID et les garanties doivent faire partie de la décision.
Un plan de migration utile
Un plan raisonnable devrait contenir :
1. l’inventaire confirmé; 2. la destination approuvée; 3. les dépendances et responsabilités; 4. la méthode de sauvegarde et de retour arrière; 5. un test hors production lorsque possible; 6. la séquence de migration; 7. la fenêtre d’arrêt attendue; 8. les critères de validation; 9. le plan de communication aux utilisateurs; 10. la date de retrait définitif de l’ancien serveur.
Le projet n’est pas terminé lorsque le nouveau serveur démarre. Il est terminé lorsque les utilisateurs, applications, sauvegardes, alertes, documentation et responsabilités ont été validés.
Que faire si la migration ne peut pas être terminée avant janvier 2027?
L’organisation devrait documenter clairement :
- pourquoi le serveur doit rester en service;
- quelles données et fonctions sont exposées;
- quelles mesures compensatoires sont possibles;
- qui accepte le risque;
- quelle est la date cible réaliste;
- quelles dépendances bloquent le projet.
Des mesures temporaires peuvent inclure la réduction des services exposés, une segmentation réseau plus stricte, une surveillance accrue, des sauvegardes indépendantes et la limitation des comptes administratifs. Elles ne remplacent pas une plateforme prise en charge.
Commencer par une évaluation ciblée
Une revue de l’environnement TI peut identifier les rôles, dépendances, sauvegardes et options avant de transformer le dossier en urgence.
Pour préparer la discussion, rassemblez :
- le nom et l’adresse IP du serveur;
- les applications connues;
- les utilisateurs concernés;
- les contrats ou coordonnées des fournisseurs;
- les rapports de sauvegarde;
- la tolérance d’arrêt;
- les contraintes budgétaires ou de calendrier.
Communiquer avec Montréal TI pour planifier une revue à portée définie.