Le 12 janvier 2027 n’est pas une simple date de calendrier

Windows Server 2016 atteindra la fin de son support étendu le 12 janvier 2027. Après cette échéance, les serveurs ne recevront plus les mises à jour de sécurité régulières ni le support standard associé au produit. Le vrai risque n’est pas seulement l’absence d’un correctif : c’est de découvrir trop tard qu’un service critique dépend d’un système que personne n’a documenté.

Une migration réaliste commence par l’inventaire des rôles, des flux, des comptes de service, des certificats, des sauvegardes et des applications. Elle se termine par une validation métier et un plan de retour arrière. Mettre un nouveau serveur en ligne sans traiter les dépendances ne constitue pas une migration; c’est un déplacement de risque.

Commencer par un inventaire exploitable

Ne partez pas d’une liste de noms de serveurs seulement. Pour chaque instance, consignez l’édition, le build, les rôles, les applications, les ports, les propriétaires, le niveau de criticité, le RPO/RTO, la méthode de sauvegarde et la cible de migration. Un serveur qui semble inactif peut encore héberger un relais SMTP, une tâche planifiée ou une autorité de certification.

À collecter	Pourquoi
Rôles et fonctionnalités	Déterminer les prérequis et le chemin de migration
Applications et versions	Valider le support du fournisseur sur 2022 ou 2025
Flux réseau et dépendances DNS	Éviter une coupure invisible après le changement d’IP
Comptes de service, certificats et tâches	Recréer les fonctions cachées sans mot de passe oublié
Sauvegarde et restauration testée	Garantir un retour arrière réel, pas seulement un job vert

Inventaire PowerShell en lecture seule

Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber,
  CsName,CsDomain,OsLastBootUpTime

Get-WindowsFeature | Where-Object InstallState -eq 'Installed' |
  Select-Object Name,DisplayName,InstallState

Get-Service | Where-Object Status -eq 'Running' |
  Sort-Object Name | Select-Object Name,DisplayName,StartType

Choisir entre nouvelle installation, migration ou mise à niveau

La nouvelle installation côte à côte est généralement le choix le plus prévisible : elle permet de conserver l’ancien serveur intact, de tester le nouveau et de revenir en arrière par un simple changement de rôle ou de DNS. La migration de rôle est adaptée aux fichiers, à DHCP, à certaines bases et aux services d’infrastructure lorsque les procédures Microsoft sont suivies.

La mise à niveau sur place peut conserver rôles et paramètres, mais elle augmente le rayon d’explosion : pilotes, agents de sauvegarde, antivirus, filtres de stockage et logiciels anciens peuvent rendre l’opération non supportée. Microsoft recommande de vérifier le chemin exact, les éditions, les langues et les rôles avant de l’utiliser.

Approche	Avantage	Risque	Quand l’utiliser
Côte à côte	Retour arrière simple et test contrôlé	Nouveau nom/IP, migration des données	Choix par défaut pour les services critiques
Migration de rôle	Procédure documentée et ciblée	Dépendances parfois oubliées	AD DS, DHCP, fichiers et services compatibles
Mise à niveau sur place	Conserve davantage de réglages	Incompatibilité d’agents et retour complexe	Serveur bien documenté, fenêtres et sauvegarde validées
Retrait ou remplacement applicatif	Élimine une dette technique	Projet plus large	Application obsolète ou non supportée

Active Directory : ajouter avant de retirer

Pour un contrôleur de domaine, ajoutez d’abord un contrôleur récent, vérifiez la réplication et transférez les rôles FSMO avant de décommissionner Windows Server 2016. Ne traitez pas un contrôleur de domaine comme un serveur membre : DNS, SYSVOL, sites AD, certificats, NTP et dépendances LDAP doivent être validés séparément.

Contrôles AD avant et après

repadmin /replsummary
repadmin /showrepl * /csv
dcdiag /e /c /v
netdom query fsmo

Get-ADDomainController -Filter * |
  Select-Object HostName,OperatingSystem,IsGlobalCatalog,Site

Fichiers, DHCP, IIS et bases : documenter les détails qui cassent

Pour un serveur de fichiers, mesurez les ACL, les partages, les quotas, les chemins DFS, les tâches de réplication et les verrous. Pour DHCP, exportez les étendues, réservations, options et autorisations AD. Pour IIS, notez les certificats, pools, identités, bindings et secrets. Pour SQL Server, validez les versions, jobs SQL Agent, comptes, chaînes de connexion et fenêtres de maintenance.

Exemples de sauvegarde de configuration

# DHCP
Export-DhcpServer -ComputerName SRV2016 -File C:Tempdhcp.xml -Leases

# IIS
& $env:windir\system32\inetsrv\appcmd.exe list site /config /xml > C:\Temp\iis-sites.xml

# Partages et ACL
Get-SmbShare -CimSession SRV2016
Get-SmbShareAccess -Name Data -CimSession SRV2016

Windows Server 2022 ou 2025?

Windows Server 2022 demeure une cible stable lorsque le fournisseur de l’application certifie cette version ou lorsque l’équipe veut limiter le changement. Windows Server 2025 est pertinent pour un cycle plus long, mais il faut confirmer la compatibilité des agents, des outils de sauvegarde, des pilotes et des applications médicales ou industrielles.

Le numéro de version ne suffit pas. Une cible supportée doit aussi respecter les exigences de virtualisation, de chiffrement, de réseau, de stockage, de licences et de supervision. Faites valider la matrice du fournisseur par écrit pour les applications qui ne peuvent pas être arrêtées facilement.

ESU : un pont, pas une stratégie

Microsoft a annoncé des Extended Security Updates pour certains scénarios Windows Server 2016, notamment via Azure Arc. Cette option peut réduire le risque pendant une migration complexe, mais elle ne corrige pas une application abandonnée, une configuration faible ou une dépendance non documentée. Traitez-la comme une exception avec une date de sortie, un propriétaire et un budget.

Si vous retenez ESU, documentez les serveurs couverts, le mode d’activation, les correctifs réellement reçus, les contrôles de conformité et le plan de remplacement. Ne laissez pas une licence temporaire devenir une justification pour conserver indéfiniment un système ancien.

Microsoft — Annonce ESU Windows Server 2016 ↗

Plan de migration en quatre vagues

Pour chaque vague, prévoyez un changement approuvé, une personne qui décide du retour arrière et une validation métier. Une migration réussie se mesure à la continuité du service, pas au fait que le nouveau serveur démarre.

Vague	Travail	Critère de sortie
1 — Découverte	Inventaire, propriétaires, criticité, dépendances	Aucun serveur sans propriétaire ni sauvegarde validée
2 — Pilote	Services non critiques et restauration testée	Monitoring, sauvegarde et procédures approuvés
3 — Production	Applications critiques par fenêtre contrôlée	Tests métier, performance et retour arrière réussis
4 — Retrait	Décommission, nettoyage DNS/AD, documentation	Ancien serveur éteint et absence de flux résiduels

Contrôle de santé après migration

Comparer les journaux et la performance avec la référence avant migration.
Tester les connexions clientes, les tâches planifiées, les certificats et les relais.
Valider la sauvegarde du nouveau serveur et une restauration représentative.
Retirer les anciens enregistrements DNS, objets AD, comptes et règles de pare-feu seulement après la période d’observation.
Conserver la décision, les résultats et les écarts dans la documentation d’exploitation.

Vérifications simples

Get-WinEvent -LogName System -MaxEvents 200 |
  Where-Object LevelDisplayName -in 'Error','Warning'

Test-NetConnection app.example.local -Port 443
Get-SmbSession
Get-DnsServerResourceRecord -ZoneName example.local

# Vérifier les sauvegardes récentes dans votre outil
# puis exécuter une restauration de fichier et une restauration applicative

Checklist de décision

La fin de Windows Server 2016 est une occasion de réduire la dette opérationnelle. En traitant l’inventaire, les dépendances et les tests comme un seul projet, vous évitez la migration précipitée de janvier 2027 et obtenez une plateforme plus facile à sauvegarder, surveiller et sécuriser.

Tous les Windows Server 2016 sont inventoriés et classés par criticité.
Chaque application possède une cible supportée et un propriétaire.
Les dépendances réseau, DNS, certificats, comptes et sauvegardes sont documentées.
Le chemin de migration et le retour arrière ont été testés sur un pilote.
Les exceptions ESU ont une date de fin et ne remplacent pas un plan de sortie.
Les contrôleurs AD, serveurs de fichiers, DHCP, IIS et bases sont validés séparément.

À propos de l’auteur

Marc-Antoine Lambert

Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.

Discuter de votre environnement →