Migracja SAP do AWS - przewodnik z dofinansowaniem MAP

Ten przewodnik jest skierowany do organizacji z produkcyjnym środowiskiem SAP (ECC, S/4HANA, BW, Solution Manager), które rozważają wyjście z on-premise lub kolokacji. Jeśli szukasz ogólnego przewodnika po migracji do AWS (nie tylko SAP), zobacz kompletny przewodnik migracji do chmury AWS.

Dlaczego firmy przenoszą SAP do AWS

Koniec cyklu odnawiania sprzętu

Środowisko SAP on-premise to zwykle wyspecjalizowane serwery o dużej pamięci (dla HANA) i macierze dyskowe, które trzeba wymieniać co 4-5 lat. Każda taka wymiana to projekt kapitałowy na setki tysięcy złotych, zaplanowany z rocznym wyprzedzeniem. Na AWS pamięć i moc obliczeniową dobiera się do faktycznego zapotrzebowania i płaci za użycie, a instancję można zmienić w oknie serwisowym zamiast czekać na dostawę sprzętu.

Presja terminu S/4HANA 2027

SAP zakończy wsparcie standardowe dla Business Suite 7 (w tym ECC) z końcem 2027 roku, z opcją wsparcia rozszerzonego do 2030. To wymusza na tysiącach firm decyzję o przejściu na S/4HANA. Migracja do AWS i konwersja na S/4HANA to naturalny moment, by połączyć oba projekty i sfinansować je z jednego budżetu MAP zamiast robić migrację sprzętu, a za dwa lata jeszcze raz ruszać z konwersją.

Elastyczność środowisk nieprodukcyjnych

W SAP typowo utrzymuje się kilka środowisk (rozwój, test, QA, szkolenia, produkcja). On-premise wszystkie działają non-stop, bo sprzęt i tak jest kupiony. Na AWS środowiska nieprodukcyjne można wyłączać poza godzinami pracy i w weekendy, co w środowisku SAP potrafi obniżyć rachunek za te systemy o 60-70%. To jeden z najszybszych efektów oszczędnościowych po migracji.

Certyfikacja SAP i zgodność

AWS jest certyfikowaną przez SAP platformą pod produkcyjne obciążenia, z instancjami zatwierdzonymi pod HANA (SAP HANA Hardware Directory). Dla branż regulowanych (KNF, sektor publiczny) istotne są certyfikaty AWS (ISO 27001, SOC 2, PCI DSS) oraz najbliższe regiony w UE: eu-central-1 (Frankfurt) i eu-west-1 (Irlandia), z opóźnieniem do Polski poniżej 30 ms i danymi pozostającymi na terenie UE (zgodność z RODO).

RISE with SAP czy wdrożenie samodzielne na AWS

To pierwsza i najważniejsza decyzja architektoniczna. Oba warianty działają na AWS, ale różnią się modelem odpowiedzialności i rozliczeń.

Kluczowa różnica dla tego przewodnika: dofinansowanie MAP dotyczy wdrożenia samodzielnego na AWS, nie RISE. RISE to subskrypcja kupowana od SAP, więc AWS nie dofinansowuje w niej pracy partnera. Jeśli zależy Ci na pełnej kontroli nad architekturą, integracji z resztą środowiska w AWS i pokryciu 70-80% kosztów projektu z MAP, wybierasz wdrożenie samodzielne. Jeśli priorytetem jest oddanie całości zarządzania SAP jednemu dostawcy i akceptujesz mniejszą elastyczność, RISE bywa uzasadniony. W praktyce doradzamy porównanie TCO obu wariantów w fazie oceny, bo różnica potrafi być znacząca w obie strony.

Dobór instancji pod SAP HANA

SAP HANA trzyma całą bazę w pamięci, więc dobór instancji to przede wszystkim dobór pamięci RAM, a dopiero potem CPU. AWS oferuje instancje certyfikowane przez SAP w kilku rodzinach.

Praktyczne zasady doboru:

• Sizing pod HANA robi się z raportu SAP. Dla nowej instalacji S/4HANA służy do tego SAP Quick Sizer, dla konwersji istniejącego systemu raport /SDF/HDB_SIZING uruchamiany na źródle. Dopiero z tego wynika docelowy rozmiar pamięci, a nie z obecnego rozmiaru bazy na dysku.
• Certyfikacja ma znaczenie. Pod produkcyjne HANA używa się wyłącznie instancji z SAP HANA Hardware Directory. Środowiska nieprodukcyjne mogą działać na instancjach niecertyfikowanych, co obniża koszt.
• Warstwę aplikacyjną (SAP NetWeaver, serwery dialogowe) skaluje się osobno. Tu nie potrzeba instancji o dużej pamięci, wystarczą standardowe rodziny obliczeniowe, a serwery dialogowe można skalować poziomo pod obciążenie użytkowników.
• Storage pod HANA to io2 lub gp3 z odpowiednią przepustowością, dobrane do wymagań SAP na przepustowość zapisu logów i danych.

Rozważasz migrację SAP do AWS?

Umów bezpłatną 30-minutową rozmowę. Pomagamy zaplanować migracje SAP na AWS: RISE vs wdrożenie samodzielne, sizing HANA i przełączenie produkcji, oraz sprawdzamy, czy Twój projekt kwalifikuje się do dofinansowania AWS MAP (typowo 70-80% kosztów partnera).

Umów rozmowę Wyślij wiadomość

Strategie migracji SAP do AWS

Podejście do migracji zależy od tego, czy zostajesz na dotychczasowej bazie (np. ECC na AnyDB), czy przechodzisz na S/4HANA, oraz ile przestoju możesz zaakceptować.

Rehost (lift-and-shift)

Przeniesienie systemu SAP na AWS bez zmiany wersji i bazy danych. Najszybsza droga do chmury, dobra gdy priorytetem jest wyjście z on-premise przed odnowieniem sprzętu, a konwersję na S/4HANA planujesz później. Narzędzia: AWS Application Migration Service (MGN) do replikacji serwerów lub natywne mechanizmy SAP (backup/restore, kopia systemu).

Replatform (migracja z konwersją bazy na HANA)

Przeniesienie z jednoczesną zmianą bazy na SAP HANA, ale bez zmiany wersji aplikacji (np. Suite on HANA). Wykorzystuje SAP Database Migration Option (DMO) w narzędziu SUM, które konwertuje bazę w trakcie migracji.

Greenfield (nowa implementacja S/4HANA)

Wdrożenie S/4HANA od zera, z nowymi procesami i migracją tylko danych podstawowych i otwartych pozycji. Wybierane gdy obecne procesy są mocno przestarzałe albo obciążone latami modyfikacji, których nikt nie chce przenosić. Najwięcej pracy projektowej, ale najczystszy efekt.

Brownfield (konwersja systemu do S/4HANA)

Konwersja istniejącego ECC do S/4HANA z zachowaniem procesów, konfiguracji i historii. Realizowana przez SAP SUM z DMO. Mniej ryzykowna biznesowo niż greenfield (zachowujesz to, co działa), ale przenosi też dług techniczny.

Bluefield (podejście selektywne)

Wariant pośredni: nowa instalacja S/4HANA, do której selektywnie przenosisz wybrane dane i konfiguracje ze starego systemu. Kompromis między czystością greenfield a zachowaniem historii z brownfield.

Proces migracji krok po kroku

Licencjonowanie SAP na AWS

Migracja do AWS nie zmienia sposobu licencjonowania samego SAP: licencje SAP (aplikacja i HANA) pozostają umową z SAP niezależnie od tego, gdzie działa system. Model BYOL (Bring Your Own License) oznacza, że przenosisz posiadane licencje do chmury.

Kilka kwestii, o których warto pamiętać:

• Licencje aplikacji SAP i HANA są niezależne od AWS. AWS rozlicza infrastrukturę (instancje, storage, sieć), SAP rozlicza oprogramowanie. To dwie oddzielne pozycje.
• RISE with SAP łączy jedno i drugie w subskrypcję. Jeśli wybierzesz RISE, oprogramowanie i infrastruktura są w jednym kontrakcie z SAP, ale tracisz dostęp do dofinansowania MAP i części elastyczności kosztowej.
• Systemy operacyjne pod SAP (SUSE Linux for SAP, Red Hat for SAP) mają na AWS własny model rozliczania: albo w cenie instancji (subskrypcja godzinowa), albo BYOS (Bring Your Own Subscription).
• Warto zaplanować audyt licencyjny przed migracją, żeby przenosić tylko to, co faktycznie jest używane, i nie płacić za nadmiarowe licencje w nowym środowisku.

Minimalizacja przestoju

Ile przestoju wymaga migracja SAP, zależy głównie od wybranej strategii i rozmiaru bazy HANA.

• Rehost dużej bazy HANA przez backup/restore to okno serwisowe liczone w godzinach, zależne od rozmiaru bazy i przepustowości łącza. Dla dużych baz stosuje się HANA System Replication: replikujemy bazę do AWS na żywo, a w oknie serwisowym wykonujemy tylko przełączenie (takeover), co skraca przestój do minut.
• Konwersja brownfield do S/4HANA (SUM z DMO) ma dłuższe okno serwisowe, bo konwersja bazy odbywa się w jego trakcie. Skraca się je przez tryb downtime-optimized DMO oraz próbne przełączenia, które pozwalają zmierzyć i zoptymalizować faktyczny czas.
• Greenfield minimalizuje przestój produkcji (nowy system budowany równolegle), ale przenosi ciężar na migrację danych i równoległą pracę obu systemów w okresie przejściowym.

W każdym scenariuszu plan wycofania (rollback) jest przygotowany i przetestowany przed właściwym przełączeniem. Utrzymanie systemu źródłowego w trybie tylko do odczytu przez pierwsze dni po przełączeniu to standardowe zabezpieczenie.

Jak AWS MAP finansuje migrację SAP

Co to jest AWS Migration Acceleration Program (MAP)

MAP to program dofinansowania AWS dla organizacji migrujących z on-premise lub kolokacji. Obejmuje trzy fazy, a środowiska SAP należą do obciążeń, na których AWS zależy szczególnie, więc kwalifikują się do podwyższonego budżetu.

Dlaczego SAP kwalifikuje się do wyższego budżetu

AWS traktuje migracje SAP jako strategiczne i prowadzi dla nich ścieżkę z podwyższonymi limitami dofinansowania ponad standardowy MAP. Powód jest prosty: środowisko SAP to duże, stałe obciążenie, które po migracji zostaje na platformie na lata. W praktyce oznacza to dla klienta:

• Wyższe pułapy dofinansowania niż przy typowej migracji aplikacyjnej
• Dodatkowe kredyty na infrastrukturę docelową na czas migracji i stabilizacji
• Dostęp do architektów AWS wyspecjalizowanych w SAP oraz do programu SAP Competency partnera

To jest główny argument komercyjny: przy właściwie poprowadzonym wniosku MAP realny koszt migracji SAP po Twojej stronie spada o 70-80%, a moment przymusowej decyzji o S/4HANA (koniec wsparcia ECC w 2027) staje się okazją sfinansowaną w dużej części przez AWS, a nie tylko kosztem.

Kto się kwalifikuje

• Aktywne środowisko SAP (on-premise, kolokacja lub już częściowo w chmurze)
• Cel na natywnym AWS (wdrożenie samodzielne, nie RISE)
• Minimalna wielkość projektu na poziomie zaangażowania partnera typowym dla środowisk SAP (większość projektów SAP przekracza próg swobodnie)
• Certyfikowany partner MAP do złożenia i prowadzenia wniosku. Zajmujemy się tym od początku do końca.

Ile realnie można uzyskać

Poza pokryciem honorarium partnera typowo dochodzą kredyty AWS na infrastrukturę docelową na czas projektu oraz wsparcie architektów AWS. Datę odnowienia sprzętu lub kontraktu wsparcia SAP warto zgłosić na starcie, bo bywa punktem dźwigni, który odblokowuje dodatkowe środki.

Koszty i czas migracji SAP

Co najmocniej wpływa na koszt i czas: liczba systemów w środowisku, decyzja rehost vs konwersja do S/4HANA (konwersja to osobny projekt aplikacyjny), liczba integracji z systemami zewnętrznymi, wymagania na dostępność (HA/DR) oraz dopuszczalne okno przestoju (im krótsze, tym więcej pracy nad replikacją i próbnymi przełączeniami).

Po stronie oszczędności największe pozycje to koniec cyklu odnawiania sprzętu, wyłączanie środowisk nieprodukcyjnych poza godzinami pracy oraz Savings Plans na stałe obciążenie produkcyjne. Łącznie daje to typowo 20-50% redukcji kosztów infrastruktury względem on-premise, zależnie od tego, jak nieefektywne było środowisko wyjściowe.

Najczęściej zadawane pytania

Następne kroki - bezpłatna ocena migracji SAP

Każda migracja SAP zaczyna się od oceny środowiska. Analizujemy Twoje systemy (wersje, rozmiary HANA, integracje, wymagania na dostępność) i wracamy z konkretem:

1. Sizing docelowy na AWS - jakie instancje certyfikowane pod HANA, jaka architektura HA/DR
2. Rekomendacja strategii - rehost, brownfield czy greenfield, i dlaczego akurat ta
3. Realistyczny kosztorys i harmonogram - widełki kosztów wraz z projekcją dofinansowania MAP
4. Plan przełączenia - jak przejść z minimalnym wpływem na biznes

Prowadzimy migracje i modernizacje środowisk produkcyjnych dla firm z sektorów regulowanych, z naciskiem na zgodność, ciągłość działania i przełączenia bez przestojów. Niezależnie czy zbliża się koniec wsparcia ECC, odnowienie sprzętu pod HANA, czy dopiero rozważasz kierunek, pierwszy krok to zrozumienie, z czym mamy do czynienia.

Planujesz migrację SAP do chmury?

Umów bezpłatną 30-minutową rozmowę. Wstępnie ocenimy złożoność migracji środowiska SAP i sprawdzimy, czy Twój projekt kwalifikuje się do dofinansowania AWS MAP (typowo 70-80% kosztów partnera).

Umów ocenę migracji SAP