Azure Cloud Services (Extended Support) va in pensione il 31 marzo 2027: spostare web role e worker role

Microsoft ha deprecato Azure Cloud Services (extended support) il 31 marzo 2025 e lo ritira definitivamente il 31 marzo 2027. Se una vostra applicazione gestionale gira come web role e worker role, prima di quella data deve girare da un'altra parte su Azure. Le FAQ sul ritiro rispondono senza giri di parole alle due domande che tutti fanno per prime: Microsoft «non può concedere proroghe», e «non esiste uno strumento di migrazione con un clic».

Da oggi, 3 ottobre 2026, restano sei mesi.

A chi si rivolge

Il caso tipico: un'applicazione ASP.NET su .NET Framework, un web role davanti e uno o due worker role dietro che elaborano code, costruita da un'agenzia otto o dieci anni fa. Spesso l'agenzia non c'è più, l'applicazione gestisce ancora l'elaborazione degli ordini o un portale clienti, e nessuno ha aperto il file .csdef dall'ultima migrazione.

Per capire se siete coinvolti, aprite il portale di Azure ed elencate le risorse di tipo «Cloud services (extended support)». L'avviso di ritiro di Microsoft rimanda direttamente a quella vista. Se è vuota, avete finito.

Questo articolo non parla di Cloud Services (classic), ritirato nel 2024. Se il prodotto ve lo ospita un fornitore, la migrazione è compito suo: chiedetegli la data per iscritto. Tutto ciò che segue è per i team che possiedono il codice, o lo possiedono sulla carta e devono trovare qualcuno che lo capisca.

Perché è più difficile del passaggio del 2024

Molte aziende sono passate all'extended support nel 2024, quando la versione classic è stata ritirata. Quel passaggio era economico per progetto. La panoramica di Microsoft sull'extended support dice che i file .csdef, .cscfg e .cspkg «vengono mantenuti e i formati non cambiano», e che «non sono necessarie modifiche al codice di runtime». C'era perfino una migrazione sul posto. La stessa pagina suggeriva l'extended support per le applicazioni che non evolvono, perché «offre un percorso di migrazione rapido».

Questa volta non esiste una destinazione equivalente. Con le parole di Microsoft, Cloud Services «consiste nel distribuire applicazioni come VM. Il codice che scrivete è strettamente legato a un'istanza di VM». Il vostro codice sa di girare in un role. Legge la configurazione dal role, trova lo spazio su disco tramite il role, si fa installare i certificati dal role ed esegue script di configurazione come amministratore prima che il role parta. Tutto questo va sostituito.

Un'altra cosa prima di leggere le indicazioni ufficiali. L'avviso di ritiro e le FAQ di Microsoft indicano una sola destinazione, il cluster gestito di Service Fabric. La pagina di panoramica ne elenca cinque, e la matrice decisionale per la migrazione della stessa Microsoft ne confronta sette. Service Fabric è un'opzione predefinita, non un obbligo, e per molti web role è quella sbagliata.

Le destinazioni, e quando conviene ciascuna

Web role e worker role non devono per forza finire nello stesso posto. Scegliete una destinazione per ogni role.

App Service (Windows). La cosa più vicina a un web role per un'applicazione ASP.NET. Le istanze Windows hanno già installate le versioni supportate di .NET Framework, quindi Web Forms e MVC 5 girano senza riscritture. I worker role possono seguire come WebJob, che girano «nella stessa istanza di una web app» senza costi aggiuntivi. Il limite è la macchina stessa: Microsoft indirizza verso Managed Instance le app che hanno bisogno di componenti COM, accesso al registro o installer MSI, quindi su un piano standard le attività di avvio con privilegi elevati non hanno dove andare.

App Service Managed Instance. Pensato per le web app Windows legacy. Secondo la panoramica di Microsoft, è «disponibile a livello generale per le web app Windows in alcune aree geografiche», limitato ai piani Pv4 e Pmv4, con .NET Framework 3.5 e 4.8 preinstallati e script di installazione PowerShell che possono registrare componenti COM, scrivere chiavi di registro, eseguire installer MSI e configurare IIS. Questo copre quasi tutto ciò che facevano le attività di avvio con privilegi elevati. I limiti: solo web app (niente WebJob), niente container, solo Entra ID e identità gestita (niente aggiunta al dominio, NTLM o Kerberos) e, nel momento in cui scriviamo, l'unica area europea elencata è North Europe.

Container Apps. Adatto ai worker role una volta portati su .NET moderno: scalabilità guidata dalle code, job pianificati e attivati da eventi, scalabilità fino a zero. Ma i requisiti per i container dicono che «sono richieste immagini container basate su Linux (linux/amd64)». Il codice su .NET Framework lì non gira finché non viene portato.

Azure Kubernetes Service. Esegue container Windows Server in pool di nodi Windows, quindi un role su .NET Framework si può containerizzare e spostare. La matrice decisionale giudica alte sia la complessità della migrazione sia l'onere operativo. Ha senso se Kubernetes lo usate già, non come primo cluster per una sola applicazione legacy.

Virtual Machine Scale Sets. La matrice lo definisce «più vicino al modello di Cloud Services, con un lift-and-shift più semplice». Riavete la VM, insieme alle patch, alla costruzione delle immagini e alla configurazione di IIS che prima faceva il role per voi.

Cluster gestito di Service Fabric. La destinazione indicata da Microsoft. I worker role ci si adattano bene. I web role spesso no: Service Fabric «non supporta IIS», e la guida alla conversione elenca ASP.NET Web Forms tra le tecnologie non supportate, con la conversione ad ASP.NET Core MVC come percorso. La guida alla migrazione verso Service Fabric aggiunge che i cluster gestiti «al momento non supportano i container», quindi un'applicazione che dipende da IIS ha bisogno di un cluster tradizionale, con più cose da gestire.

Tabella decisionale

Cosa cambia nel codice

Cercate Microsoft.WindowsAzure.ServiceRuntime nella soluzione. Ogni file che lo importa va nella lista.

RoleEntryPoint

Un worker role è una classe che eredita da RoleEntryPoint e sovrascrive OnStart, Run e OnStop. Se Run termina, l'istanza si ricicla. Service Fabric riunisce tutti e tre in un unico RunAsync che dovrebbe fermarsi «quando viene segnalato il CancellationToken del metodo RunAsync». Su App Service o in un container, la stessa logica diventa un'applicazione console o un servizio in background ospitato, con un ciclo e un token di annullamento.

La parte che sfugge è l'arresto. OnStop vi dava un momento per finire il messaggio in lavorazione. Assicuratevi che il nuovo host trasmetta un segnale di annullamento, e che un messaggio abbandonato a metà elaborazione si possa elaborare due volte senza danni.

Spesso anche i web role ne hanno uno, di solito WebRole.cs. Se il suo OnStart fa qualcosa (ritocchi a IIS, riscaldamento della cache), scoprite cosa prima di cancellarlo.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") legge le impostazioni dal .cscfg. Fuori da Cloud Services non lo fornisce nessuno. Prima di spostare qualsiasi cosa, incapsulate ogni chiamata in una piccola interfaccia di configurazione, poi puntate quell'interfaccia sulle impostazioni dell'app, sulle variabili d'ambiente o su Key Vault nel nuovo host. È la modifica più economica del progetto e rende il resto testabile su un portatile.

Altri tre usi da cercare:

• RoleEnvironment.Changed, che applicava le modifiche di configurazione senza riavvio. Service Fabric ha un evento equivalente. Altrove, date per scontato che una modifica di impostazione riavvii il processo e verificate cosa succede al lavoro in corso.
• RoleEnvironment.CurrentRoleInstance usato per eleggere un'istanza per il lavoro pianificato. I WebJob attivati girano su una sola istanza; quelli continui girano su tutte le istanze, salvo restrizioni. Decidete in modo esplicito.
• I rami RoleEnvironment.IsAvailable e IsEmulated. Separano il percorso «cloud» da quello «locale», e uno dei due sta per diventare codice morto.

.cscfg e .csdef

Il .cscfg contiene le impostazioni per ambiente, il numero di istanze e le impronte dei certificati. Il .csdef contiene endpoint, dimensione della VM, archiviazione locale, attività di avvio, archivi dei certificati e a volte diversi siti IIS dentro un unico web role. Passateli entrambi riga per riga e annotate dove vivrà ogni voce dopo: un'impostazione dell'app, un riferimento a Key Vault, codice dell'infrastruttura, o da nessuna parte. Gli endpoint interni che permettono ai role di chiamarsi direttamente hanno bisogno di un sostituto, un indirizzo di servizio o una coda.

Certificati

L'extended support aveva già costretto a spostare i certificati in Key Vault, quindi quella parte del lavoro del 2024 ora ripaga. Cambia il modo in cui il codice li trova. Un .csdef installa i certificati in un archivio con nome, spesso LocalMachine. Su App Service Windows, l'impostazione WEBSITE_LOAD_CERTIFICATES li rende disponibili in Current User\My. Il codice che apre l'archivio LocalMachine non trova nulla, e la prima chiamata che ha bisogno del certificato fallisce. Sui container Linux, caricatelo invece da Key Vault all'avvio.

Attività di avvio

Aprite Startup.cmd. È qui che si nascondono le sorprese, di solito eseguite con executionContext="elevated": font per la generazione di PDF, un componente COM, un modulo di rewrite di IIS, una modifica al registro per TLS. Ogni riga ha tre destini possibili: non serve più, si sposta in uno script di installazione su Managed Instance, oppure finisce dentro un'immagine container o VM.

Archiviazione locale

Una risorsa LocalStorage nel .csdef, letta tramite RoleEnvironment.GetLocalResource, dava a ogni istanza un disco di appoggio. Per i veri file temporanei usate la directory temporanea della piattaforma. Tutto ciò che deve sopravvivere a un riavvio, compresi i file che qualcuno ha dato per permanenti, va in Blob Storage.

Web Forms

È la decisione che guida tutto il resto. Web Forms si basa su System.Web e non ha una versione ASP.NET Core, quindi spostare un'applicazione Web Forms su Service Fabric o Container Apps significa riscriverne l'interfaccia utente. App Service, Managed Instance, un container Windows o un insieme di scalabilità possono eseguirla senza modifiche. Spostatela così com'è e fate della modernizzazione un progetto separato con il suo budget. Una riscrittura dell'interfaccia non deve stare sul percorso critico di una data di spegnimento.

Il resto

Lo scambio VIP tra due cloud service diventa uno slot di distribuzione su App Service o una revisione su Container Apps. I log inviati tramite l'estensione di diagnostica (WAD) hanno bisogno di una nuova destinazione, di solito Application Insights. App Service standard e Container Apps non offrono il desktop remoto; Managed Instance lo consente tramite Azure Bastion, solo per la diagnostica.

Un piano di sei mesi

A ritroso dal 31 marzo 2027, con le feste di dicembre nel mezzo.

Ottobre: inventario e scelta delle destinazioni. Elencate ogni distribuzione in extended support. Per ogni role, registrate la versione di .NET Framework, Web Forms o MVC, ogni chiamata a RoleEnvironment, attività di avvio, risorsa di archiviazione locale, certificato ed endpoint. Poi verificate la parte scomoda: riuscite a costruire il pacchetto distribuito a partire dai sorgenti che avete? Con i sistemi costruiti da agenzie a volte la risposta è no, e ottobre è il mese per scoprirlo. Scegliete una destinazione per ogni role.

Novembre: un role, dall'inizio alla fine. Aggiungete l'incapsulamento della configurazione, scrivete l'ambiente di destinazione come codice dell'infrastruttura e fate girare un role (di solito il worker più semplice) in un ambiente di test con log, certificati e una pipeline.

Dicembre e gennaio: portare il resto. Sostituite punti di ingresso, attività di avvio e archiviazione locale. Fate un test di carico su un ambiente di staging con dati simili a quelli di produzione: un WebJob o un container potrebbe non eguagliare la capacità di elaborazione di una VM dedicata al role.

Febbraio: esercizio in parallelo. Fate girare il nuovo ambiente su traffico reale. Per i worker che condividono una coda con i vecchi role, rendete prima idempotente l'elaborazione oppure fermate i vecchi worker prima di avviare i nuovi.

Inizio marzo: passaggio. Cambiate il DNS con margine. Tenete la vecchia distribuzione ferma ma intatta per una o due settimane, poi eliminatela. Non pianificate il passaggio nell'ultima settimana di marzo: a quel punto un passaggio fallito non ha un secondo tentativo.

Se invece partite a gennaio, rinunciate del tutto alla modernizzazione. Scegliete la destinazione che richiede meno modifiche al codice (App Service, Managed Instance o insiemi di scalabilità), spostate, e fate il refactoring dopo.

Cosa non è chiaro

Microsoft dice che il servizio sarà «ritirato definitivamente» e che la migrazione serve «per evitare interruzioni del servizio». Le pagine che abbiamo letto non dicono cosa succede a una distribuzione ancora in esecuzione il 1° aprile 2027. Non pianificate di scoprirlo. Anche aree geografiche e piani di Managed Instance probabilmente cambieranno nei prossimi mesi, quindi verificateli al momento della decisione, non su questo articolo.

Dove trovare aiuto

Prendiamo in carico applicazioni costruite da altri, capiamo come funzionano e le spostiamo: l'inventario, la destinazione per ogni role, le modifiche a RoleEnvironment e alle attività di avvio, e il passaggio. Il nostro lavoro di manutenzione dei sistemi legacy copre .NET Framework e Web Forms; se la migrazione la sta facendo il vostro team e servono braccia in più, vedete la staff augmentation.

Se avete una distribuzione su Cloud Services e una scadenza a sei mesi, scrivete a office@c9group.dev.