Azure Cloud Services (Extended Support) kończy działanie 31 marca 2027: przenoszenie ról web i worker

Microsoft uznał Azure Cloud Services (extended support) za przestarzałe 31 marca 2025 i całkowicie wycofuje tę usługę 31 marca 2027. Jeśli któraś z Twoich aplikacji biznesowych działa jako role web i role worker, przed tą datą musi już działać gdzie indziej na Azure. FAQ o wycofaniu odpowiada bez ogródek na dwa pytania, które wszyscy zadają najpierw: Microsoft „nie może przyznać przedłużenia”, a „nie ma narzędzi do migracji jednym kliknięciem”.

Licząc od dziś, 3 października 2026, zostaje sześć miesięcy.

Dla kogo to jest

Typowy przypadek: aplikacja ASP.NET na .NET Framework, rola web z przodu i jedna albo dwie role worker przetwarzające kolejki z tyłu, zbudowana przez agencję osiem czy dziesięć lat temu. Agencji często już nie ma w pobliżu, aplikacja wciąż obsługuje przetwarzanie zamówień albo portal klienta, a od ostatniej migracji nikt nie otwierał pliku .csdef.

Żeby sprawdzić, czy Cię to dotyczy, otwórz portal Azure i wyświetl zasoby typu „Cloud services (extended support)”. Komunikat Microsoftu o wycofaniu prowadzi prosto do tego widoku. Jeśli jest pusty, sprawa jest zamknięta.

Ten artykuł nie dotyczy Cloud Services (classic), które wycofano w 2024. Jeśli produkt hostuje dla Ciebie dostawca, migracja jest jego zadaniem: poproś go o datę na piśmie. Wszystko poniżej jest dla zespołów, które są właścicielami kodu albo są nimi na papierze i muszą znaleźć kogoś, kto go rozumie.

Dlaczego to trudniejsze niż przeprowadzka z 2024

Wiele firm przeszło na extended support w 2024, gdy wycofywano wersję classic. Ta przeprowadzka była z założenia tania. Omówienie extended support przygotowane przez Microsoft mówi, że pliki .csdef, .cscfg i .cspkg „są przenoszone dalej, a ich formaty się nie zmieniają” oraz że „nie są wymagane żadne zmiany w kodzie uruchomieniowym”. Była nawet migracja w miejscu. Ta sama strona proponowała extended support dla aplikacji, które się nie rozwijają, bo „zapewnia szybką ścieżkę migracji”.

Tym razem nie ma odpowiednika jeden do jednego. Słowami Microsoftu Cloud Services „polega na wdrażaniu aplikacji jako maszyn wirtualnych. Kod, który piszesz, jest ściśle powiązany z instancją maszyny wirtualnej”. Twój kod wie, że działa w roli. Czyta konfigurację z roli, znajduje miejsce na dysku przez rolę, dostaje certyfikaty instalowane przez rolę i uruchamia skrypty konfiguracyjne jako administrator, zanim rola wystartuje. Wszystko to trzeba zastąpić.

Jeszcze jedno, zanim przeczytasz oficjalne wytyczne. Komunikat Microsoftu o wycofaniu i FAQ wskazują jeden cel, Service Fabric managed cluster. Strona z omówieniem wymienia pięć, a własna macierz decyzyjna migracji Microsoftu porównuje siedem. Service Fabric to wartość domyślna, a nie wymóg, i dla wielu ról web jest to zły wybór.

Cele i kiedy który pasuje

Role web i worker nie muszą trafić w to samo miejsce. Wybierz cel dla każdej roli osobno.

App Service (Windows). Najbliższy odpowiednik roli web dla aplikacji ASP.NET. Instancje Windows mają zainstalowane wspierane wersje .NET Framework, więc Web Forms i MVC 5 działają bez przepisywania. Role worker mogą pójść za nimi jako WebJobs, które działają „w tej samej instancji co aplikacja internetowa” bez dodatkowych kosztów. Ograniczeniem jest sama maszyna: aplikacje potrzebujące komponentów COM, dostępu do rejestru albo instalatorów MSI Microsoft kieruje do Managed Instance, więc podwyższone zadania startowe nie mają dokąd pójść w standardowym planie.

App Service Managed Instance. Zbudowane dla starszych aplikacji internetowych Windows. Według omówienia Microsoftu jest „ogólnie dostępne dla aplikacji internetowych Windows w wybranych regionach”, ograniczone do planów Pv4 i Pmv4, z preinstalowanymi .NET Framework 3.5 i 4.8 oraz skryptami instalacyjnymi PowerShell, które mogą rejestrować komponenty COM, zapisywać klucze rejestru, uruchamiać instalatory MSI i konfigurować IIS. To obejmuje większość tego, co robiły podwyższone zadania startowe. Ograniczenia: tylko aplikacje internetowe (bez WebJobs), bez kontenerów, wyłącznie Entra ID i tożsamość zarządzana (bez przyłączania do domeny, NTLM czy Kerberos), a w chwili pisania jedynym wymienionym regionem europejskim jest North Europe.

Container Apps. Dobre dla ról worker, gdy już działają na nowoczesnym .NET: skalowanie sterowane kolejką, zadania harmonogramowane i wyzwalane zdarzeniami, skalowanie do zera. Ale wymagania dotyczące kontenerów mówią: „wymagane są obrazy kontenerów oparte na Linuksie (linux/amd64)”. Kod na .NET Framework nie uruchomi się tam, dopóki nie zostanie przeniesiony.

Azure Kubernetes Service. Uruchamia kontenery Windows Server w pulach węzłów Windows, więc rolę na .NET Framework można skonteneryzować i przenieść. Macierz decyzyjna ocenia zarówno złożoność migracji, jak i narzut operacyjny jako wysokie. Pasuje, jeśli już korzystasz z Kubernetes, a nie jako pierwszy klaster dla jednej starej aplikacji.

Virtual Machine Scale Sets. Macierz opisuje je jako „bliższe modelowi Cloud Services, oferujące łatwiejsze przeniesienie bez zmian (lift-and-shift)”. Odzyskujesz maszynę wirtualną, a razem z nią poprawki systemu, budowanie obrazów i konfigurację IIS, które dotąd robiła za Ciebie rola.

Service Fabric managed cluster. Cel wskazany przez Microsoft. Role worker dobrze się na niego mapują. Role web często nie: Service Fabric „nie obsługuje IIS”, a przewodnik po konwersji wymienia ASP.NET Web Forms jako nieobsługiwane, ze ścieżką w postaci konwersji na ASP.NET Core MVC. Przewodnik po migracji do Service Fabric dodaje, że klastry zarządzane „obecnie nie obsługują kontenerów”, więc aplikacja zależna od IIS potrzebuje tradycyjnego klastra, z większym zakresem utrzymania.

Tabela decyzyjna

Co zmienia się w kodzie

Przeszukaj rozwiązanie pod kątem Microsoft.WindowsAzure.ServiceRuntime. Każdy plik, który to importuje, trafia na listę.

RoleEntryPoint

Rola worker to klasa, która dziedziczy po RoleEntryPoint i nadpisuje OnStart, Run i OnStop. Jeśli Run zakończy działanie, instancja jest restartowana. Service Fabric łączy wszystkie trzy w jedno RunAsync, które powinno się zatrzymać, „gdy CancellationToken metody RunAsync zostanie zasygnalizowany”. W App Service albo w kontenerze ta sama logika staje się aplikacją konsolową albo hostowaną usługą w tle z pętlą i tokenem anulowania.

Często pomijaną częścią jest zamykanie. OnStop dawało chwilę na dokończenie przetwarzanej wiadomości. Upewnij się, że nowy host przekazuje sygnał anulowania i że wiadomość porzuconą w trakcie przetwarzania można bezpiecznie przetworzyć dwa razy.

Role web też często mają taką klasę, zwykle WebRole.cs. Jeśli jej OnStart cokolwiek robi (poprawki IIS, rozgrzewanie pamięci podręcznej), ustal co, zanim ją usuniesz.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") czyta ustawienia z .cscfg. Poza Cloud Services nic tego nie dostarcza. Zanim cokolwiek przeniesiesz, opakuj każde wywołanie w jeden mały interfejs konfiguracyjny, a potem skieruj ten interfejs na ustawienia aplikacji, zmienne środowiskowe albo Key Vault w nowym hoście. To najtańsza zmiana w projekcie, a sprawia, że resztę da się testować na laptopie.

Trzy inne zastosowania, których warto szukać:

• RoleEnvironment.Changed, które stosowało zmiany konfiguracji bez restartu. Service Fabric ma odpowiednie zdarzenie. Gdzie indziej zakładaj, że zmiana ustawienia restartuje proces, i przetestuj, co to robi z pracą w toku.
• RoleEnvironment.CurrentRoleInstance używane do wyboru jednej instancji do pracy harmonogramowanej. WebJobs wyzwalane działają na jednej instancji; ciągłe działają na wszystkich, chyba że się je ograniczy. Zdecyduj to świadomie.
• Gałęzie RoleEnvironment.IsAvailable i IsEmulated. Oddzielają ścieżkę „chmurową” od „lokalnej”, a jedna z nich za chwilę stanie się martwym kodem.

.cscfg i .csdef

.cscfg przechowuje ustawienia dla poszczególnych środowisk, liczbę instancji i odciski palca certyfikatów. .csdef przechowuje punkty końcowe, rozmiar maszyny wirtualnej, magazyn lokalny, zadania startowe, magazyny certyfikatów, a czasem kilka witryn IIS w jednej roli web. Przejdź przez oba pliki linia po linii i zapisz, gdzie każdy wpis znajdzie się potem: w ustawieniu aplikacji, w odwołaniu do Key Vault, w kodzie infrastruktury albo nigdzie. Wewnętrzne punkty końcowe, przez które role wywołują się nawzajem bezpośrednio, potrzebują zamiennika: adresu usługi albo kolejki.

Certyfikaty

Extended support już wymusił przeniesienie certyfikatów do Key Vault, więc ta część pracy z 2024 się zwraca. Zmienia się sposób, w jaki kod je znajduje. .csdef instaluje certyfikaty w nazwanym magazynie, często LocalMachine. W App Service na Windows ustawienie WEBSITE_LOAD_CERTIFICATES udostępnia je w Current User\My. Kod, który otwiera magazyn LocalMachine, nic nie znajdzie, a pierwsze wywołanie potrzebujące certyfikatu się nie powiedzie. W kontenerach linuksowych ładuj certyfikat z Key Vault przy starcie.

Zadania startowe

Otwórz Startup.cmd. Tu mieszkają niespodzianki, zwykle uruchamiane z executionContext="elevated": czcionki do generowania PDF, komponent COM, moduł przepisywania adresów IIS, zmiana w rejestrze dotycząca TLS. Każdą linię czeka jeden z trzech losów: przestaje być potrzebna, trafia do skryptu instalacyjnego w Managed Instance albo zostaje wbudowana w obraz kontenera lub maszyny wirtualnej.

Magazyn lokalny

Zasób LocalStorage w .csdef, czytany przez RoleEnvironment.GetLocalResource, dawał każdej instancji dysk roboczy. Na prawdziwe pliki tymczasowe używaj katalogu tymczasowego platformy. Wszystko, co musi przetrwać restart, w tym pliki, które ktoś uznał za trwałe, idzie do Blob Storage.

Web Forms

To decyzja, która napędza resztę. Web Forms jest zbudowane na System.Web i nie ma wersji na ASP.NET Core, więc przeniesienie aplikacji Web Forms do Service Fabric albo Container Apps oznacza przepisanie jej interfejsu użytkownika. App Service, Managed Instance, kontener Windows albo zestaw skalowania mogą ją uruchomić bez zmian. Przenieś ją taką, jaka jest, a modernizację zrób osobnym projektem z własnym budżetem. Przepisywanie interfejsu nie powinno leżeć na ścieżce krytycznej z datą wyłączenia usługi.

Reszta

Zamiana VIP między dwiema usługami w chmurze zamienia się w sloty wdrożeniowe w App Service albo rewizje w Container Apps. Logi wysyłane przez rozszerzenie diagnostyczne (WAD) potrzebują nowego miejsca docelowego, zwykle Application Insights. Standardowe App Service i Container Apps nie oferują pulpitu zdalnego; Managed Instance pozwala na niego przez Azure Bastion, wyłącznie do diagnostyki.

Plan na sześć miesięcy

Licząc wstecz od 31 marca 2027, z grudniowymi świętami w środku.

Październik: inwentaryzacja i wybór celu. Spisz każde wdrożenie extended support. Dla każdej roli zapisz wersję .NET Framework, Web Forms albo MVC, każde wywołanie RoleEnvironment, zadanie startowe, zasób magazynu lokalnego, certyfikat i punkt końcowy. Potem sprawdź niewygodną część: czy z kodu źródłowego, który masz, da się zbudować wdrożony pakiet? Przy systemach zbudowanych przez agencje odpowiedź bywa przecząca, a październik to miesiąc, w którym trzeba się tego dowiedzieć. Wybierz cel dla każdej roli.

Listopad: jedna rola od początku do końca. Dodaj opakowanie konfiguracji, opisz środowisko docelowe jako kod infrastruktury i uruchom jedną rolę (zwykle najprostszą rolę worker) w środowisku testowym, z logami, certyfikatami i potokiem.

Grudzień i styczeń: przeniesienie reszty. Zastąp punkty wejścia, zadania startowe i magazyn lokalny. Przetestuj obciążeniowo środowisko przejściowe na danych zbliżonych do produkcyjnych: WebJob albo kontener mogą nie dorównać przepustowością dedykowanej maszynie wirtualnej roli.

Luty: praca równoległa. Uruchom nowe środowisko na prawdziwym ruchu. W przypadku ról worker współdzielących kolejkę ze starymi rolami albo najpierw zadbaj o idempotentne przetwarzanie, albo zatrzymaj stare role, zanim uruchomisz nowe.

Początek marca: przełączenie. Przełącz DNS z zapasem czasu. Zostaw stare wdrożenie zatrzymane, ale nienaruszone, przez tydzień lub dwa, a potem je usuń. Nie planuj przełączenia na ostatni tydzień marca: nieudane przełączenie nie będzie miało wtedy drugiej próby.

Jeśli zaczynasz dopiero w styczniu, całkowicie zrezygnuj z modernizacji. Wybierz cel wymagający najmniejszych zmian w kodzie (App Service, Managed Instance albo zestawy skalowania), przenieś aplikację i refaktoryzuj później.

Co nie jest jasne

Microsoft mówi, że usługa zostanie „całkowicie wycofana” i że migracja jest potrzebna, „aby uniknąć przerw w działaniu usługi”. Strony, które przeczytaliśmy, nie mówią, co stanie się z wdrożeniem, które wciąż będzie działać 1 kwietnia 2027. Nie planuj, że się tego dowiesz. Regiony i plany Managed Instance prawdopodobnie też zmienią się w najbliższych miesiącach, więc potwierdź je w chwili podejmowania decyzji, a nie na podstawie tego artykułu.

Gdzie szukać pomocy

Przejmujemy aplikacje zbudowane przez innych, ustalamy, jak działają, i je przenosimy: inwentaryzacja, cel dla każdej roli, zmiany w RoleEnvironment i zadaniach startowych oraz przełączenie. Nasza praca w ramach utrzymania systemów odziedziczonych obejmuje .NET Framework i Web Forms; jeśli migrację prowadzi Twój zespół i potrzebuje dodatkowych rąk do pracy, zobacz wsparcie zespołów (staff augmentation).

Jeśli masz wdrożenie Cloud Services i datę za sześć miesięcy, napisz na office@c9group.dev.