--- service: "Publicasta" schema_version: "1.0" article_id: 915 title: "AWS Transform konwertuje kod .NET z Azure, ale migracja nadal wymaga przeglądu architektury" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_transform_azure_code_conversion_migration_review?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-19T17:11:15+00:00" updated_at: "2026-10-19T17:11:15+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=ar" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=ar" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=de" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=de" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=en" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=en" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=es" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=es" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=fr" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=fr" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=pl" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=ru" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=ru" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=zh" markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=zh" json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=zh" --- # AWS Transform konwertuje kod .NET z Azure, ale migracja nadal wymaga przeglądu architektury > AWS Transform może tłumaczyć wybrane wywołania Azure SDK na odpowiedniki AWS w nowoczesnych aplikacjach .NET. Kluczowe pytanie brzmi nie to, czy wygenerowany kod się kompiluje, lecz czy po zmianie chmury nadal działają tożsamość, dane, obsługa błędów i operacje. AWS udostępnił ogólnie funkcję konwersji kodu w AWS Transform, która przepisuje wybrane wywołania Azure SDK w nowoczesnych aplikacjach .NET na ich odpowiedniki w AWS. Ogłoszenie opublikowane 16 października obejmuje konwersję Azure Functions do AWS Lambda, Azure Blob Storage do Amazon S3 oraz Azure Queue Storage do Amazon SQS. Konwersja Azure Cosmos DB do Amazon DynamoDB jest dostępna jako funkcja w wersji preview. ![Inżynier analizuje szczegółową migrację kodu .NET z Azure do AWS obejmującą pamięć masową, kolejki, funkcje bezserwerowe, kontrolę tożsamości i przegląd architektury.](https://publicasta.com/storage/projects/17/pages/915/2026/10/a7d39b2f-4e0a-4a39-97e1-43f1a81cb581.webp) Bezpośrednia korzyść jest łatwa do zrozumienia: zespół może przesłać aplikację, która już działa na platformie Azure, pozwolić agentowi zidentyfikować obsługiwane zależności chmurowe i otrzymać przekształconą bazę kodu zamiast rozpoczynać przepisywanie usługa po usłudze. Ważniejszy z punktu widzenia operacji jest fakt, że to konwersja kodu źródłowego, a nie pełna migracja do chmury. Nie odtwarza sieci Azure, nie przenosi danych, nie odwzorowuje zasad tożsamości ani nie potwierdza, że wynikowa aplikacja zachowuje takie same właściwości dotyczące awarii i spójności. To rozróżnienie powinno kształtować sposób, w jaki zespoły platformowe i inżynieryjne oceniają tę funkcję. AWS Transform należy traktować jako akcelerator ograniczonego strumienia prac modernizacyjnych, a nie jako zgodę na zmianę dostawcy po zaakceptowaniu wygenerowanego pull requesta. ## Co ogłosił AWS Agent modernizacyjny .NET w AWS Transform może analizować przesłany kod źródłowy, identyfikować użycie Azure SDK oraz uwzględniać wybory dotyczące konwersji w raporcie oceny i planie modernizacji. Zespół może zaakceptować te wybory, zmienić je albo z nich zrezygnować przed uruchomieniem transformacji. Dostępne ogólnie mapowania są celowo ograniczone: - Azure Functions można konwertować na funkcje AWS Lambda. - Wywołania Azure Blob Storage SDK można konwertować na wywołania Amazon S3 SDK. - Wywołania Azure Queue Storage można konwertować na wywołania Amazon SQS. - Konwersja Azure Cosmos DB do Amazon DynamoDB jest wymieniona jako funkcja w wersji preview. AWS informuje, że funkcja jest dostępna w ośmiu regionach: US East (N. Virginia), Asia Pacific (Mumbai, Tokyo i Seoul), Asia Pacific (Sydney), Canada (Central) oraz Europe (Frankfurt i London). Dokumentacja wyraźnie wskazuje też ważne ograniczenie: funkcja konwertuje kod aplikacji i nie obsługuje migracji infrastruktury chmurowej. To ograniczenie nie jest przypisem. W rzeczywistej usłudze SDK stanowi tylko jedną warstwę zależności od dostawcy. Funkcja Azure może opierać się na planie hostingu, zarządzanej tożsamości, ustawieniach aplikacji, prywatnych punktach końcowych, slotach wdrożeniowych, wiązaniach zdarzeń, kontach magazynu, odwołaniach do Key Vault, regułach monitorowania i ograniczeniach sieciowych. Zastąpienie przestrzeni nazw i wywołania metody pozostawia ludziom zadanie odkrycia i odtworzenia wszystkich tych założeń. Funkcja AWS odpowiada więc na konkretną część kosztu migracji: tłumaczenie kodu aplikacji zależnego od dostawcy. Nie usuwa potrzeby zdefiniowania architektury docelowej. ## Dlaczego „równoważna usługa” nie oznacza równoważnego działania Nazwy usług chmurowych sprzyjają fałszywej symetrii. Blob Storage i S3 to magazyny obiektowe. Azure Queue Storage i SQS to usługi kolejkowe. Azure Functions i Lambda to bezserwerowe platformy obliczeniowe. Na poziomie API takie porównania są użyteczne. W czasie działania pozostają jednak niepełne. Pierwsze pytanie zespołu migracyjnego nie powinno brzmieć, czy daną metodę można przetłumaczyć. Należy zapytać, czy kontrakt aplikacji przetrwa tę konwersję. Magazyn obiektowy dobrze pokazuje ten problem. Ścieżka kodu może przesyłać obiekt, ustawiać metadane, generować tymczasowy URL, a następnie zakładać określone opóźnienie widoczności, sposób nadpisywania, konwencję sum kontrolnych lub model autoryzacji. Usługa docelowa może obsługiwać analogiczną operację, korzystając jednak z innych wartości domyślnych, nagłówków, typów błędów, mechanizmów cyklu życia lub słownika zasad. Mechanicznie przekonwertowane wywołanie może się kompilować, a mimo to zmienić zachowanie obserwowane przez systemy korzystające z aplikacji. Kolejki stwarzają podobny problem. Producenta i konsumenta łączy coś więcej niż metoda wysyłania. Zależą oni od semantyki dostarczania, limitów czasu widoczności, przechowywania, maksymalnego rozmiaru wiadomości, oczekiwań dotyczących kolejności, obsługi kolejki wiadomości odrzuconych, zasad ponownego kierowania, obsługi duplikatów i czasu ponawiania prób. Konwersja z Azure Queue Storage do SQS może wygenerować poprawne wywołania AWS, nie dowodząc jednak, że konsument pozostaje bezpieczny przy ponownym dostarczaniu ani że dotychczasowy mechanizm obsługi komunikatów powodujących błędy nadal działa. Funkcje dodają kolejną warstwę. Funkcja Azure może być wywoływana przez żądanie HTTP, kolejkę, zegar, strumień zdarzeń lub powiązanie ukrywające elementy infrastruktury zależne od dostawcy. Lambda ma własne źródła zdarzeń, tryby wywołań, mechanizmy kontroli współbieżności, limity czasu, sposób pakowania wdrożenia, uprawnienia oraz model obserwowalności. Jeśli pierwotna aplikacja zakłada długotrwały proces, trwałość lokalnego systemu plików, określony sposób rozgrzewania albo kształt żądania generowany przez powiązanie, implementacja docelowa wymaga prac projektowych wykraczających poza tłumaczenie wywołań SDK. W praktyce wniosek jest prosty: pomyślne kompilowanie to wczesny sygnał, a nie kryterium akceptacji migracji. ## Właściwa interpretacja raportu z oceny Przepływ pracy AWS Transform jest użyteczny, ponieważ decyzje dotyczące konwersji podejmuje się przed transformacją. Powstaje w ten sposób moment, w którym zespół może przejrzeć proponowany cel, zamiast odkrywać wszystkie decyzje dopiero po wygenerowaniu kodu. Traktuj ten raport jako inwentarz zależności wraz z dołączonymi rekomendacjami. Zacznij od rozdzielenia trzech kategorii: 1. **Bezpośrednio obsługiwane wywołania.** Są to odwołania do SDK, które według narzędzia można konwertować. To kandydaci do automatycznej transformacji, a nie automatycznie poprawne wyniki. 2. **Sąsiednie zależności od dostawcy.** Obejmują tożsamość, konfigurację, sieć, wdrażanie, rejestrowanie, śledzenie, sekrety, powiązania zdarzeń oraz definicje infrastruktury. Mogą być widoczne w tym samym repozytorium, ale nie są objęte wymienionymi mapowaniami usług. 3. **Zachowanie biznesowe.** Obejmuje idempotencję, kolejność, retencję, intencję autoryzacji, walidację danych, procedury odzyskiwania oraz obsługę błędów widoczną dla użytkownika. Nie można go bezpiecznie wywnioskować z mapowania usług jeden do jednego. Raport należy również przeanalizować pod kątem wyboru usług docelowych. AWS opisuje domyślne cele, ale pozwala zespołom dostosować plan, w tym zrezygnować z części lub wszystkich konwersji oraz przekierować domyślne mapowanie. Ma to znaczenie, gdy architektura docelowa nie jest dosłownym zastąpieniem jednej usługi inną. Przykładowo zespół może zachować w aplikacji interfejs obiektowy, jednocześnie wprowadzając adapter magazynu, albo uznać po zmierzeniu wymagań dotyczących przepustowości i kolejności, że obciążenie kolejki powinno trafić do innej usługi integracyjnej. Przydatnym artefaktem przeglądu jest tabela z jednym wierszem na każdą zależność specyficzną dla dostawcy:
Zależność Zachowanie źródłowe Proponowany cel Zachowanie do potwierdzenia Właściciel
Przesyłanie obiektu Blob nadpisywanie, metadane, retencja operacja S3 spójność i działanie zasad zespół ds. magazynu
Odbieranie z kolejki zasady ponawiania i widoczności przepływ odbioru SQS obsługa duplikatów i komunikatów trujących zespół usług
Wyzwalacz funkcji kształt zdarzenia i limit czasu wywołanie Lambdy limit czasu, współbieżność i ponowienia zespół platformy
Tożsamość tożsamość zarządzana i zakresy rola IAM i zasady najmniejsze uprawnienia i rotacja zespół bezpieczeństwa
Celem nie jest biurokracja. Tabela zapobiega temu, by wygenerowany diff stał się faktycznym dokumentem architektury. ## Co ta funkcja robi dobrze Rzeczywiście można zyskać na wydajności, gdy aplikacja korzysta z obsługiwanych zestawów Azure SDK w konwencjonalnym kodzie .NET. Narzędzie potrafi znaleźć odwołania do usług, zaproponować plan modernizacji i przepisać znane wzorce na skalę, która w przeciwnym razie pochłonęłaby czas programistów. Może też pozostawić wyraźne oznaczenia w miejscach, gdzie konwersja jest niedostępna, w tym komentarze TODO, szkielety implementacji lub dokument z kolejnymi krokami, zgodnie z dokumentacją AWS. Jest to wartościowe w trzech sytuacjach. Pierwszą jest ocena portfela. Organizacja posiadająca wiele usług .NET może wykorzystać analizę, aby ustalić, jak silnie każda aplikacja jest związana z Azure. Wynik może pomóc w ustaleniu kolejności prac, nawet jeśli dana usługa nie jest jeszcze gotowa do migracji. Drugą jest powtarzalny etap tłumaczenia. Gdy kontrakty docelowe i wzorce infrastruktury zostaną uzgodnione, automatyczne edycje mogą usunąć dużą część mechanicznej pracy. Inżynierowie mogą poświęcić więcej czasu zachowaniu aplikacji, a mniej na zmienianie przestrzeni nazw, tworzenie klientów i rutynowych kształtów żądań. Trzecią jest kontrolowana gałąź modernizacji. Zespół może uruchomić konwersję na kopii aplikacji, porównać wynik z istniejącymi granicami abstrakcji i wykorzystać powstały diff do wskazania kodu, który należy odizolować przed rozpoczęciem migracji. Ta funkcja jest mniej przydatna, gdy repozytorium opiera się głównie na infrastrukturze jako kodzie, słabo udokumentowanych powiązaniach, niestandardowych integracjach z Azure, złożonych wzorcach dostępu do danych lub logice aplikacji, która traktuje zachowanie dostawcy jako część kontraktu biznesowego. Takie przypadki nadal mogą skorzystać z analizy kodu, ale konwersji nie należy mylić z kompletnym planem migracji. ## Problem tożsamości jest większy niż zmiana konstruktora klienta Migracje między dostawcami często kończą się niepowodzeniem na granicy między kodem aplikacji a autoryzacją. Aplikacje Azure powszechnie korzystają z tożsamości zarządzanych i przypisań ról. Aplikacje AWS używają ról i zasad IAM, a uprawnienia są przypisywane do ról wykonawczych, ról zadań, profili instancji lub innych tożsamości, zależnie od środowiska uruchomieniowego. Przekonwertowane wywołanie SDK samo w sobie nie ma żadnych uprawnień. Docelowe wdrożenie musi zapewniać tożsamość, która może wykonywać dokładnie wymagane działania na dokładnie określonych zasobach. Oznacza to mapowanie nie tylko relacji „może odczytać blob” na „może odczytać obiekt”, lecz także zakresu, warunków, nazw zasobów, kluczy szyfrujących, ścieżki sieciowej i odpowiedzialności operacyjnej za ten dostęp. Przegląd migracji powinien odpowiedzieć na pytania: - Która tożsamość wykonuje każdą funkcję, proces roboczy i zadanie wdrożeniowe? - Która polityka zasobu i polityka tożsamości wspólnie autoryzują wywołanie? - Czy środowisko docelowe używa kluczy szyfrowania zarządzanych przez klienta i kto może ich używać? - Czy obciążenie może dotrzeć do usługi zamierzoną ścieżką sieciową? - Czy dane uwierzytelniające są krótkotrwałe i rotowane bez zmian w aplikacji? - Co jest rejestrowane, gdy kontrola autoryzacji zakończy się niepowodzeniem? To właśnie tutaj konwersja oparta wyłącznie na kodzie może stworzyć mylące poczucie ukończenia prac. Aplikacja może się kompilować, testy mogą przechodzić przy zbyt szerokich uprawnieniach, a wdrożenie produkcyjne nadal może zakończyć się niepowodzeniem, ponieważ rzeczywista granica polityk nigdy nie została zaprojektowana. Z drugiej strony szybka poprawka polegająca na przyznaniu szerokiej roli może sprawić, że migracja „zadziała”, jednocześnie zwiększając skalę potencjalnych skutków incydentu. Test akceptacyjny bezpieczeństwa powinien zatem obejmować działania odrzucone, próby dostępu między zasobami oraz wdrożenie z czystego środowiska. Migracja nie jest ukończona, gdy żądanie w ścieżce poprawnego działania kończy się sukcesem; jest ukończona dopiero wtedy, gdy docelowy model tożsamości jest zrozumiały i ograniczony. ## Przenoszenie danych i semantyka danych nadal wymagają pracy człowieka AWS Transform nie przenosi danych znajdujących się za Azure Blob Storage, Azure Queue Storage ani Cosmos DB. Brzmi to oczywiście, ale wpływa na harmonogram projektu. Konwersja kodu i migracja danych mogą przebiegać równolegle dopiero po określeniu przez zespół, jak obie wersje będą współistnieć. W przypadku danych obiektowych plan musi obejmować inwentaryzację źródła, szacunki rozmiaru i liczby obiektów, obsługę metadanych i tagów, wymagania dotyczące szyfrowania, zasady przechowywania, dzienniki dostępu oraz strategię przełączenia. Kopia, która zachowuje bajty, ale traci metadane, nadal może zepsuć działanie odbiorców. Przełączenie zmieniające sposób generowania adresów URL lub semantykę autoryzacji może zepsuć klientów, nawet jeśli każdy obiekt został pomyślnie przeniesiony. W przypadku kolejek kopiowanie komunikatów rzadko jest neutralną operacją. Zespół musi zdecydować, czy stare komunikaty należy opróżnić, odtworzyć, odrzucić czy przetłumaczyć. Odtworzenie może dwukrotnie uruchomić skutki uboczne. Opróżnianie może wydłużyć okno migracji. Projekt z podwójnym zapisem może doprowadzić do rozbieżności, jeśli jeden dostawca zaakceptuje komunikat, a drugi go odrzuci. Bezpieczniejszy wybór zależy od idempotencji obciążenia i konsekwencji biznesowych. W przypadku baz danych status wersji zapoznawczej Cosmos DB do DynamoDB jest sygnałem, by zachować szczególną ostrożność. Systemy NoSQL często różnią się partycjonowaniem, indeksowaniem, spójnością, zakresem transakcji, językiem zapytań, limitami elementów i zachowaniem strumienia zmian. Przekonwertowana warstwa dostępu do danych nie potwierdza, że docelowy model danych będzie skalować się prawidłowo ani zwracać te same wyniki. Zespoły powinny zamodelować reprezentatywne wzorce dostępu i przeprowadzić kontrole jakości danych przed podjęciem decyzji o przełączeniu działającego systemu. Plan migracji powinien wskazywać źródło prawdy na każdym etapie. „Dane są w obu chmurach” nie jest strategią spójności. ## Testy powinny porównywać kontrakty, a nie tylko wyniki Konwencjonalny zestaw testów jednostkowych może potwierdzić, że przekonwertowany kod zwraca oczekiwane wartości z użyciem zamockowanych klientów. To konieczne, ale niewystarczające, ponieważ mocki zwykle zachowują abstrakcję zaprojektowaną przez pierwotnego dostawcę. Silniejszy plan testów ma kilka warstw. **Testy kontraktowe** weryfikują własne oczekiwania aplikacji: schematy komunikatów, metadane obiektów, decyzje autoryzacyjne, obsługę ponowień oraz klasyfikację błędów. Testy te powinny działać na docelowych usługach wszędzie tam, gdzie zachowanie ma znaczenie. **Testy różnicowe** uruchamiają równoważne obciążenia względem implementacji źródłowej i docelowej, a następnie porównują wyniki na poziomie biznesowym. Porównanie nie powinno wymagać identycznych błędów dostawcy ani identyfikatorów żądań. Powinno sprawdzać to, na czym polegają użytkownicy, usługi zależne i operatorzy. **Testy błędów** wprowadzają ograniczanie przepustowości, przekroczenia czasu, częściowe zapisy, wielokrotne dostarczenie, wygasłe dane uwierzytelniające, niedostępne zależności oraz nieprawidłowo sformatowane zdarzenia. Celem jest ujawnienie miejsc, w których modele awarii źródła i celu się rozchodzą. **Testy operacyjne** sprawdzają logi, metryki, ślady, alarmy, pulpity oraz procedury operacyjne. Zmigrowana usługa, która działa, ale nie może zostać zdiagnozowana, nie jest gotowa do produkcji. **Testy bezpieczeństwa** potwierdzają zasady najmniejszych uprawnień i weryfikują, że obciążenie nie może odczytywać, zapisywać ani wywoływać zasobów poza zamierzonym zakresem. W przypadku obciążeń bezserwerowych uwzględnij współbieżność i zachowanie przy zimnym starcie, marginesy limitów czasu, ponowienia źródła zdarzeń oraz wycofanie wdrożenia. W przypadku kolejek zmierz czas widoczności względem rzeczywistego rozkładu czasu przetwarzania, zamiast wybierać znaną wartość. W przypadku magazynu obiektowego przetestuj metadane, szyfrowanie, zapisy warunkowe oraz adresy URL dostępu. Przy konwersji baz danych odtwórz rzeczywiste kształty zapytań i porównaj stronicowanie, spójność oraz obsługę błędów. ## Bezpieczniejsza sekwencja migracji Zespół oceniający nową funkcję może ograniczyć ryzyko, zawężając zakres pierwszego projektu. Wybierz jedną usługę z jasno określonym właścicielem, ograniczoną liczbą obsługiwanych zależności dostawcy oraz możliwym do przetestowania wycofaniem. Nie zaczynaj od systemu, który łączy federację tożsamości, rozsyłanie zdarzeń do wielu odbiorców, dane regulowane i nieudokumentowane procedury operacyjne. Przed uruchomieniem konwersji utwórz mapę zależności źródłowych. Uwzględnij pakiety SDK, zmienne środowiskowe, powiązania, manifesty wdrożeniowe, sekrety, punkty końcowe sieci, magazyny danych, kolejki, wyzwalacze harmonogramu oraz integracje z monitorowaniem. Następnie zdefiniuj kontrakty docelowe. Ustal, jak aplikacja będzie reprezentować magazyn, komunikację, konfigurację, tożsamość i telemetrię. Jeśli wywołania specyficzne dla dostawcy są rozsiane po logice biznesowej, przed konwersją wprowadź adaptery lub je wzmocnij. Zwiększa to nakład pracy przygotowawczej, ale ułatwia przegląd wynikowego diffu i obniża koszt przyszłych zmian. Uruchom ocenę i przejrzyj każde proponowane mapowanie. Zapisz świadome rezygnacje. Traktuj nieobsługiwane wywołania jako zaplanowaną pracę, a nie jako porządki, które można zostawić na koniec. Utwórz infrastrukturę docelową osobno. Użyj ról IAM o wąsko określonym zakresie, szyfrowanych zasobów, prywatnej łączności tam, gdzie jest wymagana, logowania, alarmów, kopii zapasowych oraz mechanizmów kontroli wdrożeń. Nie używaj wygenerowanego kodu aplikacji jako zamiennika przeglądu infrastruktury. Przekonwertuj kod w gałęzi, skompiluj go i uruchom analizę statyczną. Następnie przetestuj go względem rzeczywistych usług docelowych, używając reprezentatywnych danych i wprowadzając awarie. Zachowaj implementację źródłową, dopóki biznesowe i operacyjne kontrakty migracji nie zostaną potwierdzone. Przy przełączaniu preferuj odwracalną sekwencję: wdróż bez kierowania ruchu, zweryfikuj odczyty, wykonaj niedestrukcyjne zapisy, porównaj telemetrię, skieruj niewielką część ruchu lub obciążenia i zdefiniuj wyzwalacz wycofania przed zwiększeniem udziału. Dokładny mechanizm będzie różny dla poszczególnych aplikacji, ale zasada pozostaje stała: konwersja powinna skrócić fazę mechaniczną, nie skracając fazy gromadzenia dowodów. ## Kwestia zarządzania dla zespołów platformowych AWS Transform zmienia ekonomikę tłumaczenia kodu, co oznacza, że więcej organizacji może próbować migracji między dostawcami przy mniejszych zespołach. To użyteczne, ale może też przesunąć ryzyko na wcześniejszy etap procesu. Gdy transformacja kodu staje się tania, decyzje architektoniczne i walidacja stają się ograniczonymi zasobami. Zespoły platformowe powinny ustanowić standardowy etap przeglądu dla wygenerowanych migracji. Powinien on wymagać: - pełny wykaz przekonwertowanych i nieprzekonwertowanych zależności dostawcy; - zatwierdzona architektura docelowa i model tożsamości; - plan migracji danych i wycofania zmian; - testy semantyki specyficznej dla dostawcy i zachowania w przypadku awarii; - dowody, że obserwowalność i obsługa incydentów działają w środowisku docelowym; - wyznaczony właściciel każdego nierozwiązanego TODO lub stuba; - udokumentowana decyzja dotycząca każdego zmienionego mapowania domyślnego. Bramka kontrolna powinna być proporcjonalna do ryzyka. Mała funkcja wewnętrzna, która przechowuje obiekty niewrażliwe, nie wymaga takiego samego procesu jak regulowana usługa transakcyjna. Obie potrzebują jednak wyznaczonego właściciela i sposobu wykazania, że przekonwertowane działanie jest akceptowalne. Kluczowa zasada: generowany kod musi nadawać się do przeglądu. Raport z oceny, plan modernizacji, różnice transformacji, dowody z testów i wyjątki należy przechowywać wraz z rejestrem zmian usługi. Jeśli konwersja zostanie później uruchomiona ponownie, zespół powinien móc wyjaśnić, co się zmieniło i dlaczego. ## Co obserwować dalej Obecne ogłoszenie obejmuje ograniczony zestaw mapowań Azure–AWS, a mapowanie Cosmos DB do DynamoDB pozostaje w wersji zapoznawczej. Sugeruje to, że AWS zaczyna od typowych, łatwo rozpoznawalnych punktów translacji, zamiast twierdzić, że przenośność jest uniwersalna. Zespoły powinny obserwować zmiany w obsługiwanych wersjach .NET, kolejnych usługach Azure, obsłudze infrastruktury oraz sposobie raportowania niepewnych konwersji przez narzędzie. Powinny też śledzić wyniki własnych testów. Wzorzec, który w małej usłudze wygląda na równoważny, może zachowywać się inaczej przy większym obciążeniu, podczas ponawiania prób lub przy bardziej restrykcyjnych zasadach tożsamości. Na razie praktyczna rada jest taka, by używać AWS Transform tam, gdzie działa najlepiej: do inwentaryzacji zależności i przyspieszania powtarzalnych zmian w kodzie. Architekturę, dane, tożsamość i akceptację produkcyjną należy pozostawić pod jawnym nadzorem człowieka. Funkcja może szybko utworzyć gałąź migracyjną. Nie sprawi jednak, że obie chmury będą współdzielić te same kontrakty. To właśnie musi rozstrzygnąć zespół platformowy przed zatwierdzeniem pierwszego pull requesta: nie „czy agent przekonwertował kod?”, lecz „jakie dowody pokazują, że usługa nadal działa poprawnie, bezpiecznie i operacyjnie po przeniesieniu granicy między dostawcami?”