2026 Windows Server 2022 : faut-il encore migrer après la fin du support standard ?

Le support standard de Windows Server 2022 a pris fin le 13 octobre 2026, tandis que son support étendu va jusqu’au 14 octobre 2031, selon la fiche de cycle de vie de Microsoft. Il n’est donc pas nécessaire de migrer immédiatement pour cette seule raison : une entreprise peut poursuivre l’exploitation si elle installe les mises à jour de sécurité et si ses applications restent prises en charge. En revanche, une incompatibilité logicielle, un besoin fonctionnel non satisfait ou un renouvellement déjà planifié justifie d’évaluer Windows Server 2025.

Cet article s’adresse aux administrateurs IT qui gèrent un environnement de production sous Windows Server 2022 et doivent décider s’il faut planifier une migration.
Il concerne aussi les équipes IIS, .NET et logiciels métier qui doivent vérifier la compatibilité avant de changer de système.
Les responsables qui préparent un prochain budget informatique y trouveront des critères pour comparer le maintien en service et une migration vers un nouvel environnement.

Dernière vérification : 23 octobre 2026, à partir des pages de cycle de vie et de documentation Microsoft citées ci-dessous.

Après la fin du support standard, la poursuite de l’utilisation reste possible sous conditions

Oui, sous conditions. La fin du support standard marque un changement de phase, pas l’arrêt immédiat du serveur ni la fin automatique des mises à jour de sécurité. La page Microsoft associe Windows Server 2022 à une fin du support standard le 13 octobre 2026 et à une fin du support étendu le 14 octobre 2031. Ces dates indiquent la période de support du produit ; elles ne certifient ni la sécurité d’une installation particulière ni la compatibilité de chaque application.

Pendant le support standard, un produit peut recevoir des évolutions qui ne sont pas nécessairement fournies pendant le support étendu. Celui-ci se concentre notamment sur les mises à jour de sécurité, sous réserve des conditions et politiques de Microsoft. Il ne faut donc pas interpréter « pris en charge » comme « automatiquement protégé » : la configuration, l’application effective des correctifs, les comptes d’administration et les sauvegardes restent sous la responsabilité de l’organisation.

La décision peut être formulée simplement :

• Rester sur Windows Server 2022 si les correctifs de sécurité sont installés, que l’éditeur des applications confirme la prise en charge du système et que les contrôles de sécurité de l’entreprise sont respectés.
• Tester une migration si une dépendance logicielle, un pilote ou une procédure d’installation n’a pas encore été validé sous la version cible.
• Préparer un nouvel environnement si le logiciel métier exige une version plus récente, si une fonctionnalité indispensable manque ou si le serveur est déjà concerné par un renouvellement.

La fin du support standard de Windows Server 2022 doit donc déclencher une revue documentée, pas une migration précipitée. Une équipe qui ne peut pas démontrer l’état des mises à jour ou le support de ses logiciels doit toutefois traiter ces inconnues comme des risques à résoudre, et non comme une raison de présumer que l’environnement restera sûr.

Les mises à jour de sécurité restent disponibles pendant le support étendu

La fiche de cycle de vie de Microsoft indique que Windows Server 2022 reste en support étendu jusqu’au 14 octobre 2031. Cela signifie que la date de fin du support standard ne supprime pas, à elle seule, la possibilité de recevoir des mises à jour de sécurité pendant cette période. Les conditions applicables restent celles de Microsoft et doivent être vérifiées à partir de la fiche officielle du produit.

Cette couverture ne dispense pas de vérifier l’état réel de chaque serveur. Une machine qui n’a pas reçu ses mises à jour, qui expose inutilement des services d’administration ou dont les sauvegardes ne peuvent pas être restaurées peut rester vulnérable, même si sa version est toujours dans une période de support. La politique de l’entreprise peut aussi exiger un niveau de sécurité ou une fréquence de mise à jour plus stricte que le minimum associé au cycle de vie du système.

Première vérification : établir l’état des correctifs

Dans l’interface, l’équipe peut examiner l’historique des mises à jour depuis les paramètres Windows Update, puis comparer les dates de correctifs avec sa politique interne. L’emplacement précis peut varier selon la manière dont l’organisation gère les mises à jour. Sur un serveur, cette vérification peut aussi passer par la console de gestion déployée par l’entreprise.

Dans PowerShell, la commande suivante affiche les correctifs enregistrés localement :

Get-HotFix | Sort-Object InstalledOn -Descending

Cette liste aide à repérer les mises à jour installées, mais ne suffit pas à prouver que toutes les mises à jour attendues sont présentes. Il faut la comparer aux règles de déploiement internes et aux alertes éventuelles de l’outil de gestion utilisé.

Deuxième vérification : réduire l’exposition de l’administration

L’accès à l’administration à distance doit être limité aux personnes et aux réseaux qui en ont besoin. Il convient de désactiver les comptes inutilisés, d’appliquer une authentification appropriée, de restreindre les règles du pare-feu et de conserver des journaux exploitables pour examiner les connexions. Si l’administration est accessible depuis Internet, l’équipe doit vérifier si cette exposition est réellement nécessaire et si une méthode d’accès plus restreinte est disponible dans son architecture.

Troisième vérification : tester la restauration

Une sauvegarde n’est utile que si les données et les services nécessaires peuvent être restaurés dans un état cohérent. L’équipe doit documenter ce qui est sauvegardé, où se trouve une copie séparée du serveur et qui est autorisé à effectuer la restauration. Un test contrôlé, effectué dans un environnement isolé, permet de vérifier les procédures sans transformer le serveur de production en terrain d’essai.

La compatibilité des applications détermine le besoin de migration

La compatibilité doit être examinée application par application. Le fait que Windows Server puisse être mis à niveau ne signifie pas que les logiciels métier, les extensions IIS, les pilotes ou les outils de sauvegarde installés sur le serveur fonctionneront sans adaptation sous Windows Server 2025.

Pour un site IIS ou une application .NET, l’équipe doit identifier la version du moteur d’exécution, les modules IIS utilisés, les composants natifs et les dépendances installées sur la machine. Pour un ERP ou un logiciel métier, elle doit consulter la matrice de compatibilité et les prérequis de l’éditeur. La documentation Microsoft sur la compatibilité des applications constitue un point de départ pour l’évaluation du système ; elle ne remplace pas la documentation du fournisseur de l’application.

Une revue utile rassemble au minimum :

• la version de Windows Server officiellement prise en charge par l’éditeur du logiciel ;
• les versions de .NET, les rôles et fonctionnalités Windows requis ;
• les pilotes et composants matériels dont dépend l’application ;
• les tâches planifiées, scripts, certificats et comptes de service associés ;
• les procédures de sauvegarde, de supervision et de reprise propres au service.

Il faut ensuite reproduire le fonctionnement dans un environnement de test séparé. Le test doit couvrir les opérations réelles : connexion des utilisateurs, traitement métier, échanges avec les systèmes dépendants, génération de rapports et restauration des données. Une ouverture réussie de l’application ne suffit pas à confirmer que les traitements périodiques, les intégrations ou les outils d’exploitation fonctionnent aussi.

Pour les applications IIS, l’équipe peut conserver une liste des sites, des liaisons, des certificats, des pools d’applications et des paramètres qui ne sont pas enregistrés dans le code du projet. Pour les applications qui utilisent des composants natifs ou des outils d’installation anciens, une validation avec l’éditeur devient particulièrement importante. Si l’éditeur ne confirme pas la prise en charge de Windows Server 2025, il faut consigner cette absence de garantie et évaluer le risque avant le basculement.

Les critères qui justifient l’évaluation de Windows Server 2025

Windows Server 2025 est une version LTSC actuelle selon les informations de version de Microsoft. Sa fiche de cycle de vie donne une fin du support standard au 13 novembre 2029 et une fin du support étendu au 14 novembre 2034. Ces dates fournissent un horizon de planification, mais ne prouvent pas que vos applications sont compatibles ni que la migration sera sans interruption. Elles figurent dans la fiche de cycle de vie de Windows Server 2025.

Le passage à Windows Server 2025 est à évaluer si une fonction précise de cette version répond à un besoin opérationnel, si un éditeur ne prend plus en charge Windows Server 2022 ou si l’entreprise renouvelle déjà ses serveurs et peut organiser des essais. Il est également raisonnable de l’étudier pour les nouveaux déploiements, à condition que les applications, les pilotes et les processus d’exploitation aient été vérifiés.

À l’inverse, maintenir temporairement Windows Server 2022 peut être le choix le moins risqué lorsque l’application est stable, que ses exigences sont satisfaites et que l’équipe n’a pas encore vérifié les dépendances de la nouvelle version. Le changement de système n’apporte pas de bénéfice automatique si le logiciel essentiel n’est pas certifié sur la cible ou si le personnel n’a pas de procédure testée pour revenir à l’environnement précédent.

Les besoins fonctionnels doivent être précis. Par exemple, si le projet vise une capacité liée au partage de fichiers, il faut confirmer les exigences et les limites de la fonctionnalité concernée dans la documentation Microsoft sur les fonctions SMB, puis vérifier les conditions applicables au déploiement visé. Une mention dans la documentation d’une fonction ne suffit pas à établir qu’elle est requise, activée ou adaptée à chaque environnement.

La méthode à suivre avant de fixer une date de migration

Une décision solide repose sur des vérifications reproductibles, pas seulement sur la comparaison des dates de support. La méthode ci-dessous permet de produire une décision présentable à l’équipe de sécurité, aux responsables applicatifs et à la direction.

Étape de l’inventaire. Depuis Server Manager, l’administrateur relève les rôles installés et les principaux services exécutés sur la machine. PowerShell peut compléter cet inventaire :

Get-ComputerInfo
Get-WindowsFeature | Where-Object Installed

Il faut aussi noter les applications, les tâches planifiées, les comptes de service, les dépendances réseau et les outils de sauvegarde. L’objectif est de distinguer les fonctions réellement utilisées des éléments présents mais devenus inutiles.

Étape de la collecte des exigences. Pour chaque application, l’équipe retrouve la documentation de l’éditeur et consigne les versions prises en charge, les composants obligatoires et les éventuelles contraintes de migration. Les conditions indiquées par le fournisseur doivent être vérifiées directement ; une expérience rapportée par un autre utilisateur ne constitue pas une garantie de compatibilité.

Étape de l’évaluation du risque. L’équipe confronte l’état des correctifs, l’exposition des accès d’administration, la qualité des sauvegardes et les obligations internes. Elle consigne les points conformes, les mesures correctives nécessaires et les dépendances qui restent inconnues. Une incertitude sur une application essentielle doit conduire à un test ou à une demande de confirmation à l’éditeur.

Étape de la préparation d’un environnement d’essai. L’équipe prépare une installation isolée de la version envisagée, puis restaure une copie représentative des données lorsque les règles de sécurité le permettent. Microsoft décrit les considérations générales de préparation, mise à niveau et migration de Windows Server. Les procédures de cette documentation doivent être adaptées aux applications et aux règles de l’organisation.

Étape de la validation opérationnelle. Les responsables métiers et techniques testent les parcours essentiels, les intégrations, les tâches automatiques, la supervision et la restauration. Les anomalies sont consignées avec leur conséquence, leur responsable et la condition nécessaire pour les corriger. Si un composant essentiel échoue, le basculement ne doit pas être considéré comme validé.

Étape de la décision et du retour arrière. L’équipe choisit entre maintien, poursuite des tests ou migration parallèle. Avant une mise en production, elle définit le point de retour, les données à préserver, les personnes habilitées à interrompre l’opération et la procédure de remise en service de l’ancien environnement. Une migration ne doit pas être lancée tant que la récupération des données critiques et les responsabilités ne sont pas comprises par les personnes concernées.

Comparer les options avant de retenir un scénario

Le tableau suivant met en regard le cycle de vie et les principales décisions possibles. Les dates de prise en charge sont celles publiées par Microsoft ; elles ne remplacent pas les exigences de l’éditeur de chaque application.

Pour un nouveau serveur ou un environnement parallèle, les options réellement proposées par XFP Cloud peuvent être vérifiées sur la page de configuration d’un serveur. Les systèmes Windows Server 2019, 2022 et 2025, les éditions Standard et Datacenter, ainsi que les options de langue annoncées — anglais, chinois traditionnel et chinois simplifié — doivent être rapprochés des besoins de l’application et des conditions de licence Microsoft. Les modalités de facturation se consultent séparément dans les informations de facturation ; elles ne constituent pas une estimation du coût de migration ou de licence.

Choisir une infrastructure cohérente avec la décision

Si le serveur actuel est une machine virtuelle partagée, il peut rester adapté à un service temporaire, à une charge légère ou à un projet qui exige une capacité élastique. Toutefois, selon les conditions de l’offre, les ressources CPU partagées peuvent rendre les performances moins prévisibles ; les plafonds de stockage, les règles de facturation du trafic et les possibilités de personnaliser le système ou les disques peuvent aussi limiter l’exploitation. Ces points doivent être vérifiés dans le contrat et la configuration réelle, plutôt que supposés identiques chez tous les fournisseurs.

Pour une application Windows qui doit fonctionner durablement avec des ressources dédiées, une machine physique AMD louée peut mieux convenir : XFP Cloud propose des serveurs AMD EPYC en location exclusive, avec Windows Server parmi les systèmes sélectionnables et un accès à distance par RDP. La page de configuration permet de vérifier les options disponibles au moment du choix. Cette solution ne remplace toutefois ni les licences que l’entreprise doit vérifier, ni les tests de compatibilité, ni son plan de sauvegarde et de migration.

La décision ne doit donc pas être dictée par la seule fin du support standard de Windows Server 2022. Si les mises à jour sont suivies, que les applications restent officiellement prises en charge et qu’aucune nouvelle fonction n’est nécessaire, le maintien peut être justifié. Si un renouvellement, une incompatibilité ou un besoin de ressources dédiées impose un nouvel environnement, l’évaluation d’un serveur physique XFP Cloud peut s’inscrire dans le projet, après vérification des logiciels, des langues, de l’accès RDP et des conditions de licence applicables.