Azure Cloud Services (support étendu) prend sa retraite le 31 mars 2027 : migrer les rôles web et worker

Microsoft a déclaré Azure Cloud Services (support étendu) obsolète le 31 mars 2025 et le retire complètement le 31 mars 2027. Si l'une de vos applications métier tourne sous forme de rôles web et de rôles worker, elle doit fonctionner ailleurs sur Azure avant cette date. La FAQ sur le retrait répond sans détour aux deux questions que tout le monde pose en premier : Microsoft « ne peut pas accorder de demandes de prolongation », et « aucun outil de migration en un clic n'est disponible ».

Aujourd'hui, 3 octobre 2026, cela laisse six mois.

À qui s'adresse cet article

Le cas typique : une application ASP.NET sur .NET Framework, un rôle web en façade et un ou deux rôles worker qui traitent des files d'attente derrière, construite par une agence il y a huit ou dix ans. L'agence est souvent passée à autre chose, l'application fait toujours tourner le traitement des commandes ou un portail client, et personne n'a ouvert le fichier .csdef depuis la dernière migration.

Pour savoir si vous êtes concerné, ouvrez le portail Azure et listez les ressources de type « Cloud services (extended support) ». L'avis de retrait de Microsoft renvoie directement vers cette vue. Si elle est vide, c'est terminé pour vous.

Cet article ne traite pas de Cloud Services (classique), retiré en 2024. Si un éditeur héberge le produit pour vous, la migration est son affaire : demandez-lui sa date par écrit. Tout ce qui suit s'adresse aux équipes qui possèdent le code, ou qui le possèdent sur le papier et doivent trouver quelqu'un qui le comprend.

Pourquoi c'est plus difficile que la bascule de 2024

Beaucoup d'entreprises sont passées au support étendu en 2024, lors du retrait de la version classique. Cette bascule était peu coûteuse, par conception. La présentation du support étendu de Microsoft indique que les fichiers .csdef, .cscfg et .cspkg « sont conservés et leur format ne change pas », et qu'« aucune modification du code d'exécution n'est requise ». Il existait même une migration sur place. La même page recommandait le support étendu pour les applications qui n'évoluent plus, parce qu'« il offre une voie de migration rapide ».

Cette fois, il n'existe pas de cible équivalente. Selon les termes de Microsoft, Cloud Services « consiste à déployer des applications sous forme de VM. Le code que vous écrivez est étroitement couplé à une instance de VM ». Votre code sait qu'il tourne dans un rôle. Il lit sa configuration depuis le rôle, trouve de l'espace disque par le rôle, se fait installer des certificats par le rôle, et exécute des scripts d'installation en tant qu'administrateur avant le démarrage du rôle. Tout cela doit être remplacé.

Encore une chose avant de lire la documentation officielle. L'avis de retrait et la FAQ de Microsoft citent une seule destination, le cluster managé Service Fabric. La page de présentation en liste cinq, et la propre matrice de décision de migration de Microsoft en compare sept. Service Fabric est un choix par défaut, pas une obligation, et pour beaucoup de rôles web, c'est le mauvais.

Les cibles, et quand chacune convient

Les rôles web et worker n'ont pas à atterrir au même endroit. Choisissez une cible par rôle.

App Service (Windows). Ce qui se rapproche le plus d'un rôle web pour une application ASP.NET. Les instances Windows sont livrées avec les versions prises en charge de .NET Framework, si bien que Web Forms et MVC 5 tournent sans réécriture. Les rôles worker peuvent suivre sous forme de WebJobs, qui s'exécutent « dans la même instance qu'une application web » sans surcoût. La limite, c'est la machine elle-même : Microsoft oriente vers Managed Instance les applications qui ont besoin de composants COM, d'un accès au registre ou d'installeurs MSI, si bien que les tâches de démarrage élevées n'ont nulle part où aller sur un plan standard.

App Service Managed Instance. Conçu pour les anciennes applications web Windows. Selon la présentation de Microsoft, il est « en disponibilité générale pour les applications web Windows dans certaines régions », limité aux plans Pv4 et Pmv4, avec .NET Framework 3.5 et 4.8 préinstallés et des scripts d'installation PowerShell capables d'enregistrer des composants COM, d'écrire des clés de registre, d'exécuter des installeurs MSI et de configurer IIS. Cela couvre l'essentiel de ce que faisaient les tâches de démarrage élevées. Les limites : applications web uniquement (pas de WebJobs), pas de conteneurs, uniquement Entra ID et l'identité managée (pas de jonction de domaine, ni NTLM ni Kerberos), et au moment où nous écrivons, la seule région européenne listée est North Europe.

Container Apps. Bien adapté aux rôles worker une fois passés sur .NET moderne : mise à l'échelle pilotée par les files d'attente, tâches planifiées et déclenchées par événement, mise à l'échelle jusqu'à zéro. Mais les exigences relatives aux conteneurs précisent que « des images de conteneur basées sur Linux (linux/amd64) sont requises ». Le code sur .NET Framework n'y tourne pas tant qu'il n'a pas été porté.

Azure Kubernetes Service. Fait tourner des conteneurs Windows Server dans des pools de nœuds Windows : un rôle .NET Framework peut donc être conteneurisé et déplacé. La matrice de décision juge élevées à la fois sa complexité de migration et sa charge d'exploitation. Il convient si vous exploitez déjà Kubernetes, pas comme premier cluster pour une seule application ancienne.

Virtual Machine Scale Sets. La matrice le décrit comme « plus proche du modèle Cloud Services, offrant un lift-and-shift plus facile ». Vous récupérez la VM, avec les correctifs, la construction des images et la configuration d'IIS que le rôle faisait autrefois pour vous.

Cluster managé Service Fabric. La destination désignée par Microsoft. Les rôles worker s'y transposent proprement. Les rôles web, souvent pas : Service Fabric « ne prend pas en charge IIS », et le guide de conversion classe ASP.NET Web Forms comme non pris en charge, la voie proposée étant la conversion vers ASP.NET Core MVC. Le guide de migration vers Service Fabric ajoute que les clusters managés « ne prennent actuellement pas en charge les conteneurs » : une application qui dépend d'IIS a donc besoin d'un cluster traditionnel, plus lourd à exploiter.

Tableau de décision

Ce qui change dans le code

Cherchez Microsoft.WindowsAzure.ServiceRuntime dans la solution. Chaque fichier qui l'importe est sur la liste.

RoleEntryPoint

Un rôle worker est une classe qui hérite de RoleEntryPoint et redéfinit OnStart, Run et OnStop. Si Run se termine, l'instance redémarre. Service Fabric réunit les trois dans une seule méthode RunAsync, qui doit s'arrêter « lorsque le CancellationToken de la méthode RunAsync est signalé ». Sur App Service ou dans un conteneur, la même logique devient une application console ou un service d'arrière-plan hébergé, avec une boucle et un jeton d'annulation.

La partie que l'on oublie, c'est l'arrêt. OnStop vous laissait un instant pour terminer le message en cours. Vérifiez que le nouvel hôte transmet un signal d'annulation, et qu'un message abandonné en cours de traitement peut sans risque être traité deux fois.

Les rôles web en ont souvent un aussi, généralement WebRole.cs. Si son OnStart fait quoi que ce soit (réglages d'IIS, préchauffage du cache), découvrez quoi avant de le supprimer.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") lit les paramètres depuis le .cscfg. Rien en dehors de Cloud Services ne le fournit. Avant de déplacer quoi que ce soit, encapsulez chaque appel dans une petite interface de configuration unique, puis faites-la pointer vers les paramètres d'application, les variables d'environnement ou Key Vault sur le nouvel hôte. C'est la modification la moins coûteuse du projet, et elle rend tout le reste testable sur un ordinateur portable.

Trois autres usages à rechercher :

• RoleEnvironment.Changed, qui appliquait les changements de configuration sans redémarrage. Service Fabric a un événement équivalent. Ailleurs, partez du principe qu'un changement de paramètre redémarre le processus et testez l'effet sur le travail en cours.
• RoleEnvironment.CurrentRoleInstance, utilisé pour élire une instance chargée des travaux planifiés. Les WebJobs déclenchés s'exécutent sur une seule instance ; les WebJobs continus s'exécutent sur toutes les instances, sauf restriction. Décidez explicitement.
• Les branches RoleEnvironment.IsAvailable et IsEmulated. Elles séparent le chemin « cloud » du chemin « local », et l'un des deux est sur le point de devenir du code mort.

.cscfg et .csdef

Le .cscfg contient les paramètres propres à chaque environnement, le nombre d'instances et les empreintes des certificats. Le .csdef contient les points de terminaison, la taille de VM, le stockage local, les tâches de démarrage, les magasins de certificats et parfois plusieurs sites IIS au sein d'un même rôle web. Passez-les tous les deux en revue ligne par ligne et notez où chaque entrée vivra ensuite : un paramètre d'application, une référence Key Vault, du code d'infrastructure, ou nulle part. Les points de terminaison internes qui permettent aux rôles de s'appeler directement doivent être remplacés, soit par l'adresse d'un service, soit par une file d'attente.

Les certificats

Le support étendu a déjà imposé le passage des certificats dans Key Vault : cette partie du travail de 2024 porte ses fruits. Ce qui change, c'est la façon dont le code les trouve. Un .csdef installe les certificats dans un magasin nommé, souvent LocalMachine. Sur App Service Windows, le paramètre WEBSITE_LOAD_CERTIFICATES les met à disposition dans Current User\My. Le code qui ouvre le magasin LocalMachine n'y trouve rien, et le premier appel qui a besoin du certificat échoue. Sur des conteneurs Linux, chargez-le plutôt depuis Key Vault au démarrage.

Les tâches de démarrage

Ouvrez Startup.cmd. C'est là que se cachent les surprises, généralement exécutées avec executionContext="elevated" : des polices pour la génération de PDF, un composant COM, un module de réécriture IIS, une modification du registre pour TLS. Chaque ligne connaît l'un de trois sorts : devenue inutile, déplacée dans un script d'installation sur Managed Instance, ou intégrée à une image de conteneur ou de VM.

Le stockage local

Une ressource LocalStorage dans le .csdef, lue via RoleEnvironment.GetLocalResource, donnait à chaque instance un disque de travail. Utilisez le répertoire temporaire de la plateforme pour les vrais fichiers de travail. Tout ce qui doit survivre à un redémarrage, y compris les fichiers que quelqu'un a supposés permanents, part dans Blob Storage.

Web Forms

C'est la décision qui conditionne tout le reste. Web Forms repose sur System.Web et n'a pas de version ASP.NET Core : déplacer une application Web Forms vers Service Fabric ou Container Apps signifie réécrire son interface utilisateur. App Service, Managed Instance, un conteneur Windows ou un scale set peuvent tous la faire tourner sans modification. Déplacez-la telle quelle et faites de la modernisation un projet distinct, avec son propre budget. Une réécriture d'interface n'a pas sa place sur le chemin critique d'une date d'arrêt.

Le reste

Le VIP swap entre deux cloud services devient des emplacements de déploiement sur App Service ou des révisions sur Container Apps. Les journaux envoyés par l'extension de diagnostic (WAD) ont besoin d'une nouvelle destination, généralement Application Insights. App Service standard et Container Apps n'offrent pas de bureau à distance ; Managed Instance le permet via Azure Bastion, uniquement pour le diagnostic.

Un plan sur six mois

En remontant depuis le 31 mars 2027, avec les fêtes de fin d'année au milieu.

Octobre : inventaire et choix des cibles. Recensez tous les déploiements en support étendu. Pour chaque rôle, notez la version de .NET Framework, Web Forms ou MVC, chaque appel à RoleEnvironment, chaque tâche de démarrage, ressource de stockage local, certificat et point de terminaison. Vérifiez ensuite la partie inconfortable : pouvez-vous reconstruire le paquet déployé à partir des sources dont vous disposez ? Avec des systèmes construits par une agence, la réponse est parfois non, et octobre est le mois pour le découvrir. Choisissez une cible par rôle.

Novembre : un rôle, de bout en bout. Ajoutez l'interface de configuration, écrivez l'environnement cible sous forme de code d'infrastructure, et faites tourner un rôle (généralement le worker le plus simple) dans un environnement de test, avec journaux, certificats et chaîne de déploiement.

Décembre et janvier : portage du reste. Remplacez les points d'entrée, les tâches de démarrage et le stockage local. Testez en charge un environnement de préproduction avec des données proches de la production : un WebJob ou un conteneur peut ne pas égaler le débit d'une VM de rôle dédiée.

Février : fonctionnement en parallèle. Faites tourner le nouvel environnement sur du trafic réel. Pour les workers qui partagent une file d'attente avec les anciens rôles, rendez d'abord le traitement idempotent, ou arrêtez les anciens workers avant de démarrer les nouveaux.

Début mars : bascule. Basculez le DNS avec de la marge. Gardez l'ancien déploiement arrêté mais intact pendant une ou deux semaines, puis supprimez-le. Ne programmez pas la bascule pour la dernière semaine de mars : une bascule ratée n'aurait alors pas de seconde chance.

Si vous commencez plutôt en janvier, renoncez complètement à la modernisation. Choisissez la cible qui demande le moins de modifications de code (App Service, Managed Instance ou scale sets), déplacez, et refactorisez ensuite.

Ce qui n'est pas clair

Microsoft indique que le service sera « entièrement retiré » et qu'une migration est nécessaire « pour éviter une interruption de service ». Les pages que nous avons lues ne disent pas ce qu'il advient d'un déploiement qui tourne encore le 1er avril 2027. Ne prévoyez pas d'en faire l'expérience. Les régions et les plans de Managed Instance vont aussi probablement évoluer dans les mois qui viennent : confirmez-les au moment de décider, pas d'après cet article.

Où trouver de l'aide

Nous reprenons des applications construites par d'autres, comprenons comment elles tournent, et les déplaçons : l'inventaire, la cible par rôle, les modifications liées à RoleEnvironment et aux tâches de démarrage, et la bascule. Notre travail de maintenance de systèmes anciens couvre .NET Framework et Web Forms ; si votre propre équipe mène la migration et a besoin de bras supplémentaires, voyez le renforcement d'équipe.

Si vous avez un déploiement Cloud Services et une échéance dans six mois, écrivez à office@c9group.dev.