Koniec wsparcia SAP GRC: playbook migracji 2026-2031

Rozmowa o końcu wsparcia SAP GRC Access Control zmienia ton od 2024 roku. Przez lata była przypisem — GRC 12 działa do 2030, zajmiemy się tym później. W 2026 coraz częściej to główne pytanie. CIO, komitety audytu wewnętrznego i centra kompetencji SAP pytają o to samo: co konkretnie dzieje się po 2030, kiedy trzeba działać i jakie są realistyczne opcje.

Ten przewodnik to spojrzenie praktyka na decyzję o końcu wsparcia SAP GRC: kluczowe daty, praktyczne różnice między 10.x, 11.x i 12.x, implikacje dla środowisk S/4HANA, cztery ścieżki naprzód oraz 90-dniowy playbook migracji zweryfikowany na 15 podpisanych referencjach korporacyjnych.

Daty: oś czasu końca wsparcia SAP GRC

Najedź kursorem na każdą wersję, aby zobaczyć praktyczne implikacje. Znacznik GRC 12.0 to ten, na którym większość przedsiębiorstw powinna się skupić — koniec wsparcia mainstream 31 grudnia 2027 (unified GRC 12.0) oraz 31 grudnia 2030 dla GRC AC 12.0 na starszych bazach danych (Oracle, DB2, MSSQL).

Dwie praktyczne obserwacje z tych dat. Po pierwsze, organizacje na GRC 10.x lub 11.x w 2026 są już po zakończeniu mainstream — płacą extended support lub akceptują ryzyko. Po drugie, klienci GRC 12.0 na Oracle/DB2/MSSQL mają dodatkowe 3 lata w porównaniu do klientów HANA — ale ten czas często jest przeznaczony na migrację S/4HANA (która wymaga HANA), więc nie jest to darmowy okres.

Co faktycznie zmienia się po 2027 dla GRC 12.0

Nomenklatura końca wsparcia SAP jest precyzyjna, ale nie dramatyczna. Po zakończeniu mainstream maintenance degradacja postępuje równolegle: brak nowych funkcji, brak patchy bezpieczeństwa poza krytycznymi, ograniczone wsparcie techniczne, brak certyfikacji dla nowych wersji przeglądarek/OS. Platforma nadal działa, ale każdy rok zwiększa koszty utrzymania i ryzyko audytowe.

• Brak nowych funkcji. Produkt zamrożony w stanie z 2030 roku. Brak wsparcia dla nowych modułów SAP, brak dodawania agentów AI, brak ulepszeń UI ani analityki.
• Brak patchy dla nie-krytycznych bugów. Defekty funkcjonalne pojawiające się po 2030 nie są naprawiane. Workaroundy stają się normą operacyjną.
• Stopniowo redukowane patche bezpieczeństwa. SAP zobowiązuje się do aktualizacji bezpieczeństwa podczas extended maintenance (do 2033 na Enterprise Support), ale priorytet przesuwa się na następców cloud-native. Patche dla mniej krytycznych CVE mogą przyjść później.
• Brak wsparcia dla nowych integracji. Kiedy SAP wydaje nowe funkcje S/4HANA Cloud, usługi BTP lub AI biznesowe, obciążenie integracyjne spada na klientów. GRC 12 był zaprojektowany pod feature set S/4HANA z lat 2020-2023, nie pod krajobraz 2030+.
• Wzrasta uwaga zewnętrznych audytorów. Audytorzy Wielkiej Czwórki (EY, KPMG, Deloitte, PwC) flagują organizacje działające na platformach po mainstream w swoich ustaleniach ITGC. Twierdzenie „jesteśmy na wspieranym oprogramowaniu” staje się coraz trudniejsze do napisania każdego roku.

Platforma nie "przestaje dzialac" 31 grudnia 2030 - stopniowo staje sie drozsza i bardziej ryzykowna w utrzymaniu. Wiekszosc przedsiebiorstw, ktore przezyly podobne cykle EOL produktow SAP (ECC 6.0 ma te sama date 2030 dla mainstream), traktuje rok EOL jako rok decyzji, a nie rok migracji. Migracja odbywa sie w ciagu 18-24 miesiecy poprzedzajacych date EOL.

Implikacje dla S/4HANA

Najsilniejszym sygnałem w rozmowie o końcu wsparcia SAP GRC jest roadmapa modernizacji. Strategiczny kierunek SAP dla governance, risk i compliance to Cloud Identity Access Governance (Cloud IAG) — nie GRC 12.0. To sygnał inwestycyjny: rozwój produktu, integracje z Joule (AI), Fiori UX i S/4HANA foundation trafiają do Cloud IAG. GRC 2026 dostaje utrzymanie, nie inwestycje.

Dla organizacji na S/4HANA — lub planujących migrację — powstaje pytanie planistyczne niezależne od daty EOL. Roadmapa S/4HANA (public i private cloud) coraz mocniej zakłada Cloud IAG jako natywną warstwę access governance. Kontynuacja GRC 12.0 na S/4HANA jest technicznie możliwa, ale strategicznie sprzeczna z kierunkiem SAP.

That decision typically narrows to three options.

GRC 2026: czym naprawdę jest następca

Zamieszanie wokół końca wsparcia SAP GRC wynika głównie z języka. Oficjalna pozycja SAP, wyrażona w oświadczeniu No Customers Left Behind (początek 2026), stwierdza że rozwiązania SAP GRC NIE są end-of-life — wydanie 2026 to nowa wersja istniejącego produktu, dostarczana przez standardowe utrzymanie. W praktyce jednak wydanie 2026 wprowadza tyle zmian architektonicznych, że większość klientów opisuje przejście jako migrację, nie upgrade. Najedź na każdą sekcję poniżej, aby zobaczyć co się faktycznie zmienia.

Nastepne pytanie — jakie sa cztery praktyczne sciezki naprzod — to na to wlasnie wiekszosc CIO chce poswiecic czas spotkania.

Cztery ścieżki do przodu

Ścieżka 1: SAP Cloud IAG (natywny następca SAP)

Zamierzony przez SAP następca GRC AC. Cena subskrypcyjna, cloud-native, zintegrowany z resztą stacku SAP cloud. Cena ~30-80k EUR/rok w zależności od liczby użytkowników i modułów. Klienci raportują 3-6 miesięcy wdrożenia w środowiskach SAP-first. Dobre dopasowanie dla organizacji już w SAP BTP.

Właściwa odpowiedź dla: organizacji w pełni zaangażowanych w stack SAP cloud, średnich środowisk bez złożonych wymagań SoD, klientów SAP BTP z dostępem do Joule AI.

Ścieżka 2: Alternatywna platforma GRC (smartGRC, Pathlock, Saviynt, SailPoint)

Platformy zastępujące, które obsługują governance dostępu dla SAP — i coraz częściej dla systemów non-SAP — za ułamek ceny SAP GRC AC. smartGRC, Pathlock, Saviynt, SailPoint w tej kategorii. Różnią się architekturą, focus (SAP-first vs identity-first), regionem hostingu i modelem cenowym. TCO 3-letnie zazwyczaj 60-85% niższe niż SAP GRC AC.

Właściwa odpowiedź dla: organizacji, których potrzeby access governance wychodzą poza to co pokrywa Cloud IAG, klientów, którym zależy na 70-85% niższym TCO, organizacji z istotnymi systemami non-SAP w scope (30-70% ryzyka dostępu), przedsiębiorstw preferujących EU data residency.

W 2026 platforma smartGRC dodała smartSecurity — moduł monitoringu bezpieczeństwa SAP z agentami AI. Ciągle ocenia konfigurację SAP względem benchmarków (SBT, SAP Default, własne), śledzi status łatek Security Notes, wykrywa krytyczne uprawnienia (SAP_ALL, S_A.SYSTEM) i automatycznie mapuje każde odstępstwo na kontrole NIS2, ISO 27001, RODO i DORA — zamykając lukę, której SAP GRC AC nigdy nie pokryło.

Ścieżka 3: Wsparcie rozszerzone / Custom Support

Kup 1-3 lata dodatkowego wsparcia SAP po dacie mainstream, planując migrację poprawnie. SAP oferuje Extended Support i Custom Support. Koszty rosną wykładniczo: pierwszy rok ~2x normalna cena maintenance, drugi ~4x, trzeci ~6x. To płatne zabezpieczenie czasu, nie strategia długoterminowa.

Właściwa odpowiedź dla: organizacji, które naprawdę potrzebują 1-2 lat więcej zanim będą mogły wykonać migrację (np. w trakcie transformacji S/4HANA, po niedawnym M&A, projekt IPO w toku). Nie strategia — bilet czasowy do wykonania czegoś innego.

Ścieżka 4: "Nic nie robić i zaakceptować ryzyko"

Technicznie możliwe, coraz mniej atrakcyjne. Po zakończeniu mainstream platforma nadal działa, ale każdy rok zwiększa: koszty utrzymania (specjaliści, którzy znają starszą platformę), ryzyko compliance (patche bezpieczeństwa, przeglądarka/OS niekompatybilność), ryzyko audytowe (jak wyjaśnić audytorowi używanie end-of-life software). Extended support kosztuje więcej niż migracja — dlatego migracje zwykle odbywają się na czas.

Playbook migracji w 90 dni

Ponizszy harmonogram to sekwencja, ktora sprawdzila sie w 15 wdrozeniach korporacyjnych migrujacych z SAP GRC AC do smartGRC. Te same fazy dotycza migracji do Cloud IAG lub innej alternatywy — roznica lezy w narzedziach uzywanych w dniach 15-60, a nie w samym schemacie.

Tygodnie 1-3: Ekstrakcja danych

Ekstrakcja z SAP GRC AC: reguły ryzyka SOD i katalog krytycznych dostępów (GRAC SOD), kontrole mitygujące (GRAC_MC), matryca ról (GRAC BRM), historyczne wnioski o dostęp (GRAC ARM), sesje FF (GRAC EAM ostatnie 6 mies). Format wyjścia: CSV + XML. Timing: 2-3 tygodnie.

Tygodnie 3-5: Wgrywanie katalogu ryzyk

Załaduj wyodrębnione reguły ryzyka do platformy docelowej. Na smartGRC to zautomatyzowane (agent AI mapowania obsługuje ~85% mapowań reguł SOD do transakcji SAP), resztę weryfikuje konsultant. Rezultat: rulebook 100-150 reguł SoD gotowy do runowania.

Tygodnie 5-7: Pilotażowy cykl przeglądu SoD

Przeprowadź pojedynczą jednostkę biznesową przez pełny przegląd SoD na nowej platformie równolegle do istniejącego przeglądu SAP GRC AC. Cel: identyczne wyniki co do liczby konfliktów SoD; różnice = braki w rulebook do skorygowania. Timing: 2 tygodnie kalendarzowe. Pełny opis metodologii przeglądu SoD znajdziesz w naszym kompletnym Przewodniku po SAP Podziale Obowiązków.

Tygodnie 7-9: Praca równoległa

Rozszerz do pełnego scope produkcyjnego, ale zachowaj SAP GRC AC jako system of record. Każdy wniosek o dostęp przechodzi przez oba. Porównanie wyników = ostateczna walidacja rulebook + potwierdzenie że nowa platforma pokrywa wszystkie use case. Timing: 4-6 tygodni.

Tygodnie 9-12: Przełączenie i wyłączenie

Przełącz system of record na nową platformę. Zachowaj SAP GRC AC w trybie read-only przez 6 miesięcy jako audit reference. Wycofanie SAP GRC AC po pomyślnym pierwszym cyklu audytu na nowej platformie. Timing przełącznika: 1 tydzień + 6 mies. read-only.

Framework decyzji zero-ryzyka

Branża migracji sprzedaje najpierw zobowiązanie, walidacja później — podpisz kontrakt, zacznij projekt, w połowie drogi odkryj że platforma nie pasuje do Twojego środowiska. GRC Advisory sprzedaje odwrotnie: 90-dniowy parallel run z ograniczonym scope + platformą smartGRC. Klient widzi identyczne wyniki na obu systemach zanim podejmuje decyzję o pełnej migracji.

Dlaczego 15 lat doświadczenia GRC Advisory ma znaczenie

Powód, dla którego 90-dniowy timeline działa, to nie oprogramowanie — to ekspertyza migracji. GRC Advisory wdraża SAP GRC od 15 lat i jest oficjalnym partnerem SAP Service. Znamy wewnętrzną strukturę GRAC SOD i typowe pułapki migracji na pamięć. To skraca fazę odkrywczą która dominuje w projektach z generycznymi integratorami.

Nie każdy moduł i każdy dataset musi migrować. Większość klientów nie potrzebuje pełnej reimplementacji 1:1 każdego historycznego obiektu — dużo danych SAP GRC jest uśpione (zamknięte kampanie UAR z 2019, archiwalne provisioning tickets, wygasłe sesje firefighter) i nie ma znaczenia operacyjnego dla codziennej pracy.

Zamienia to projekt odkrycia + migracji trwający 6-12 miesięcy z generycznym partnerem wdrożeniowym w 90-dniowy parallel run z GRC Advisory. Różnica leży w narzędziach na dniach 15-60 (nie w wysiłku), plus w AI-driven mappings i experience library z 15 poprzednich migracji SAP GRC AC.

Punkt decyzyjny w 12. tygodniu

Na końcu 90-dniowego parallel run komitet wykonawczy widzi trzy artefakty:

• Reconciliation report — every SoD conflict flagged by SAP GRC AC in the last 90 days, mapped against smartGRC's output on the same access base. Match rate is typically 96-98% at this point; the remaining discrepancies are documented rule interpretation differences, not bugs.
• Firefighter log review comparison — the same production sessions reviewed by both platforms. smartGRC's AI agent flags anomalies that the standard SAP GRC session-by-session review does not catch (this is the "Firefighter AI vs Human 6:0" case study in operation).
• 5-year TCO comparison — SAP GRC 2026 upgrade + ongoing maintenance vs smartGRC subscription. For mid-market estates (400-600 SAP users), the delta is typically €400-600k over 5 years in favour of smartGRC.

Trzy wyniki są możliwe: (a) klient migruje — SAP GRC AC przechodzi w read-only, potem wycofanie, opłaty SAP maintenance są anulowane; (b) klient decyduje się na Cloud IAG lub inną platformę na podstawie danych z parallel run; (c) klient decyduje kontynuować na SAP GRC AC — ale teraz z danymi zamiast założeń.

Co naprawdę chce usłyszeć komitet audytowy

Rozmowa z komitetem audytowym o koncu wsparcia SAP GRC rzadko dotyczy technologii. Dotyczy trzech pytan. Po pierwsze, czy istnieje podpisany plan z data? — decyzja "analizujemy opcje" jest nieakceptowalna po 2027 roku. Po drugie, kto jest wlascicielem ryzyka migracji? — CFO, CIO, CISO czy szef audytu wewnetrznego. Po trzecie, jaki jest plan awaryjny, jesli migracja sie oposni? Extended support to standardowy plan awaryjny; fakt, ze kosztuje wiecej niz sama migracja, to dokladnie powod, dla ktorego migracja zwykle konczy sie w terminie.

Najsilniejsza pozycja, z jaką można wejść na to spotkanie: podpisana decyzja o platformie docelowej, wskazany executive sponsor, zaplanowany 90-dniowy proof-of-concept oraz udokumentowany fallback Extended Support na wypadek, gdyby POC znalazł blokera. Reszta to szczegóły procesowe.