Migracja lift and shift do AWS - które narzędzie sprawdzi się najlepiej

Migracja lift and shift do AWS - które narzędzie sprawdzi się najlepiej

Słowo „lift and shift” sugeruje jedno proste działanie: podnieś maszynę i postaw ją w chmurze. W praktyce przy migracji do AWS masz kilka dróg, które prowadzą do tego samego celu, ale różnią się tym, ile automatyzacji dostajesz po drodze i czy w ogóle rehostujesz na EC2, czy przenosisz całą platformę. Devopsity, jako firma świadcząca profesjonalne usługi AWS, prowadzi takie migracje od analizy po wdrożenie, więc ten artykuł jest spisany z realnych projektów.

Odpowiedź w skrócie

Dla czystego lift and shift do AWS rekomendowanym silnikiem rehostu jest AWS Transform MGN (dawniej AWS Application Migration Service, MGN). To on fizycznie replikuje maszyny na EC2 przy minimalnej zmianie. Reszta decyzji zależy od źródła:

Innymi słowy: MGN prawie zawsze jest preferowanym narzędziem rehostu; prawdziwa decyzja to ile automatyzacji AWS Transform dokładasz wokół niego i czy w ogóle planujesz pozostanie na EC2.

Cztery drogi do lift and shift na AWS

AWS Transform MGN - domyślny silnik dla rehostu

AWS Transform MGN to narzędzie, które AWS rekomenduje do rehostu aplikacji na AWS. Instaluje lekki agent replikacji na maszynie źródłowej i replikuje bloki dysku do AWS w sposób ciągły, bez przestoju na czas replikacji. Gdy jesteś gotowy, uruchamiasz instancje testowe, weryfikujesz, a następnie wykonujesz cutover z krótkim oknem przełączenia.

Dlaczego to domyślny wybór dla lift and shift:

• Działa z dowolnym źródłem - VMware, serwery fizyczne, inne hypervisory, a nawet maszyny z innej chmury. Replikacja blokowa nie wymaga wiedzy o tym, co jest na dysku.
• Minimalna zmiana - maszyna ląduje na EC2 taka, jaka była. To jest dokładnie definicja rehostu.
• CloudEndure wchłonięty - wcześniejsze narzędzie CloudEndure Migration zostało włączone do MGN, więc dziś nie ma potrzeby sięgać po osobny produkt.

MGN to odpowiedź, gdy migrujesz rozproszony zbiór maszyn bez wspólnego mianownika w postaci jednego hypervisora.

AWS Transform dla VMware - warstwa automatyzacji nad MGN

Jeśli źródłem jest duże środowisko VMware, samo uruchomienie MGN to nie wszystko. Najwięcej godzin w projekcie VMware pochłaniają fazy przed replikacją: odkrycie co właściwie działa w środowisku, zmapowanie zależności między maszynami, pogrupowanie ich w fale migracyjne i przełożenie konfiguracji sieci. AWS Transform dla VMware automatyzuje właśnie te etapy agentami AI, z człowiekiem w pętli decyzyjnej, a samo przeniesienie wykonuje przez MGN.

Dlatego w praktyce najczęstszym wariantem dla VMware nie jest „MGN albo Transform”, tylko MGN plus Transform dla VMware - agentowa warstwa planowania na górze, sprawdzony silnik replikacji na dole. Opisaliśmy szerzej, jak AWS Transform zmienia ekonomię migracji, w artykule o AWS Transform i automatyzacji AI.

Uwaga na granicę: AWS Transform potrafi też konwertować kod (np. .NET z Azure) i refaktoryzować mainframe. To już nie jest lift and shift, tylko replatform albo modernizacja. Jeśli szukasz konwersji kodu, zobacz osobny artykuł o AWS Transform i konwersji .NET z Azure do AWS. W czystym lift and shift kod zostaje nietknięty.

VMware Cloud on AWS - gdy vSphere ma zostać vSphere

VMware Cloud on AWS (VMC) to inna filozofia: zamiast rehostować każdą VM na natywne EC2, przenosisz cały stos vSphere na dedykowany sprzęt w AWS i dalej zarządzasz nim tak, jak zarządzałeś on-premise (vCenter, vSAN, NSX), zwykle z użyciem HCX do samego przeniesienia. Dla zespołu nic się nie zmienia w sposobie pracy, zmienia się tylko lokalizacja.

To mocny wariant, gdy chcesz wyjść z własnego centrum danych bez przebudowy i bez przeuczania zespołu, albo gdy masz ścisły termin i nie chcesz ryzykować migracji VM-po-VM. Ale ma dwa zastrzeżenia, które zawsze omawiamy z klientem:

• Ekonomia po Broadcom. Po przejęciu VMware przez Broadcom model licencyjny i komercyjny VMC był przedmiotem zmian. Dla wielu nowych migracji rehost na natywne EC2 przez MGN okazuje się tańszy w dłuższym horyzoncie, bo nie płacisz za warstwę VMware.
• To nie jest modernizacja. VMC utrzymuje cię na vSphere. Jeśli celem jest w ogóle zejście z VMware, VMC jest przystankiem, a nie metą.

Pełne porównanie dróg wyjścia z VMware (VMC kontra rehost na EC2), z kosztami i finansowaniem, mamy w przewodniku migracji VMware do AWS.

Rehost ręczny i narzędzia zewnętrzne - kiedy mają sens

Zawsze możesz zaimportować obraz maszyny (VM Import/Export) albo odtworzyć serwer ręcznie i zrobić redeploy. Dla kilku maszyn, z zespołem który wie co robi, bywa to wystarczające. Problem pojawia się w skali: ręczny rehost nie ma automatycznej replikacji ciągłej, więc okno cutoveru jest dłuższe, a koordynacja wielu maszyn zamienia się w arkusz kalkulacyjny i zarządzanie ryzykiem. Narzędzia zewnętrzne, które kiedyś wypełniały tę lukę (jak CloudEndure), zostały wchłonięte przez MGN, więc dziś rzadko jest powód, by sięgać poza natywne usługi AWS.

Jak wybieramy w praktyce

Decyzję sprowadzamy do źródła migracji, nie do cennika narzędzia:

1. Jedno źródło, jeden hypervisor VMware, duża skala - MGN jako silnik, AWS Transform dla VMware jako warstwa planowania.
2. Mieszane źródła (fizyczne, różne hypervisory, inna chmura) - MGN samodzielnie; Transform dla VMware nie ma tu zastosowania.
3. Chcesz zostać na vSphere - VMC, ze świadomością kosztów po Broadcom.
4. Kilka maszyn, prosty przypadek - rehost ręczny bywa wystarczający, ale policz koszt czasu zespołu zanim uznasz go za najtańszy.

Niezależnie od ścieżki lift and shift to zwykle pierwszy etap, nie meta. Przenosisz się szybko i bez zmian, a optymalizację (rightsizing, usługi zarządzane, modernizację) robisz po wylądowaniu w AWS. Logikę doboru strategii opisaliśmy w przewodniku po 7 strategiach migracji (7 R), a realne widełki kosztów w kalkulatorze kosztów migracji do AWS.

Najczęściej zadawane pytania

Które rozwiązanie do migracji do AWS lepiej sprawdzi się przy lift and shift?

Dla czystego lift and shift (rehost bez zmian w kodzie) rekomendowanym silnikiem jest AWS Transform MGN - replikuje maszyny blokowo na EC2 i działa z dowolnym źródłem (VMware, fizyczne, inne hypervisory, inna chmura). Dla dużego środowiska VMware dokłada się AWS Transform dla VMware, który automatyzuje discovery, mapowanie zależności i planowanie fal, a przeniesienie wykonuje przez MGN. Jeśli chcesz zachować stos vSphere zamiast rehostować na natywne EC2, alternatywą jest VMware Cloud on AWS. Wybór zależy od źródła migracji, nie od chmury docelowej, bo ta jest ustalona jako AWS. Devopsity, jako firma świadcząca profesjonalne usługi AWS, dobiera ścieżkę do źródła i przeprowadza całą migrację, od analizy po wdrożenie.

Czym różni się AWS Transform MGN od AWS Transform dla VMware?

To nie są konkurenci, tylko dwie warstwy. AWS Transform MGN (dawniej AWS Application Migration Service) to silnik replikacji, który fizycznie przenosi maszyny na EC2. AWS Transform dla VMware to warstwa automatyzacji nad nim: agentowe discovery środowiska vSphere, mapowanie zależności, planowanie fal i konwersja sieci. W dużych projektach VMware najczęściej używa się ich razem - Transform planuje, MGN przenosi.

Kiedy VMware Cloud on AWS jest lepszy niż rehost na EC2?

VMware Cloud on AWS (VMC) jest lepszy, gdy chcesz wyjść z własnego centrum danych bez przebudowy i bez przeuczania zespołu, albo gdy masz ścisły termin i nie chcesz ryzykować migracji VM-po-VM. Utrzymujesz vSphere (vCenter, vSAN, NSX) na sprzęcie w AWS. Dwa zastrzeżenia: po zmianach Broadcom ekonomia VMC bywa droższa niż rehost na natywne EC2, a VMC z definicji nie jest modernizacją - zostajesz na VMware. Jeśli celem jest zejście z VMware, VMC to przystanek, nie meta.

Czy do lift and shift potrzebuję jeszcze CloudEndure?

Nie. CloudEndure Migration zostało wchłonięte przez AWS Application Migration Service (dziś AWS Transform MGN), więc jego możliwości replikacji są dostępne natywnie w MGN. Dla nowej migracji lift and shift do AWS nie ma powodu sięgać po osobny produkt CloudEndure.

Czy lift and shift to dobry pomysł na dłużej?

Lift and shift to zwykle pierwszy etap, nie meta. Pozwala przenieść się do AWS szybko i bez zmian w kodzie, często pod presją czasu (koniec umowy hostingowej, odnowienie licencji VMware). Po wylądowaniu w AWS warto zoptymalizować: rightsizing, usługi zarządzane, a tam gdzie to się opłaca - modernizację. Sam rehost bez późniejszej optymalizacji potrafi kosztować więcej niż środowisko, z którego migrowałeś, więc traktuj go jako start, nie koniec.

Następne kroki - bezpłatna ocena migracji

Dobór narzędzia do lift and shift zaczyna się od zrozumienia źródła. Analizujemy Twoje środowisko (co migrujesz, z jakiego hypervisora, jaka skala, jakie zależności) i wracamy z konkretem: rekomendacją ścieżki (MGN samodzielnie, MGN + Transform dla VMware, czy VMC), realistycznym harmonogramem i projekcją dofinansowania AWS MAP, które typowo pokrywa 70-80% kosztów partnera.

Realizujemy migracje do AWS dla firm pod realnymi ograniczeniami regulacyjnymi i wymaganiami dostępności. Devopsity jest partnerem AWS i doradza oraz wdraża całą migrację, nie tylko rysuje plan na slajdzie.

Planujesz lift and shift do AWS?

Umów bezpłatną 30-minutową rozmowę. Dobierzemy ścieżkę do Twojego źródła migracji i sprawdzimy, czy projekt kwalifikuje się do dofinansowania AWS MAP (typowo 70-80% kosztów partnera).

Umów ocenę migracji