Koniec utrzymania SAP ECC 31 grudnia 2027: skok ceny, a nie wyłączenie

31 grudnia 2027 SAP kończy podstawowe utrzymanie (mainstream maintenance) SAP ECC 6.0 i pozostałych kluczowych aplikacji SAP Business Suite 7. 1 stycznia 2028 nic się nie wyłączy. System działa dalej, użytkownicy dalej księgują faktury, a SAP nadal sprzeda Ci wsparcie. Zmienia się to, ile za nie płacisz i co dostajesz.

To rozróżnienie ma znaczenie, bo wiele krążących porad traktuje 2027 jak urwisko. Dla większości firm wciąż korzystających z ECC nim nie jest i one o tym wiedzą: największa grupa pozostałych użytkowników ECC planuje na 2030. Prawdziwe ryzyko jest inne. Praca, która naprawdę decyduje o terminie (własny kod ABAP, interfejsy, dane), zostaje oszacowana za późno, a 2030 okazuje się równie ciasny, jak był 2027.

Ten tekst jest dla dyrektorów IT i kierowników SAP w średnich firmach, w większości na rynkach niemieckojęzycznych, które wciąż pracują na ECC i muszą zdecydować, jak będą wyglądać najbliższe trzy lata.

Do czego SAP faktycznie się zobowiązał

Warunki są na stronie SAP o strategii utrzymania i po raz pierwszy ogłoszono je w lutym 2020:

• Do 31 grudnia 2027: podstawowe utrzymanie kluczowych aplikacji Business Suite 7, w tym SAP ERP 6.0, w trzech najnowszych pakietach rozszerzeń (enhancement packages). Jeśli Twój system jest na starszym pakiecie rozszerzeń, zanim oprzesz plan na dacie 2027, sprawdź SAP Note 2881788 (link na tej samej stronie).
• Od 1 stycznia 2028 do 31 grudnia 2030: opcjonalne rozszerzone utrzymanie (extended maintenance) za „premię w wysokości dwóch punktów procentowych od podstawy opłaty za utrzymanie”. Mówiąc prościej, stawka utrzymania, którą płacisz dziś, rośnie o dwa punkty.
• Jeśli nie wykupisz rozszerzonego utrzymania: automatycznie przechodzisz na utrzymanie indywidualne (customer-specific maintenance). Co ono obejmuje, opisuje SAP Note 52505, podlinkowana na tej samej stronie. Przeczytaj ją, zanim założysz, że to wystarczy.
• Dla S/4HANA: SAP zobowiązał się do utrzymania do końca 2040.

Dla mniejszej grupy istnieje jeszcze jedna droga. W sierpniu 2025 SAP przedstawił opcję przejściową SAP ERP, private edition: ograniczoną w czasie subskrypcję, która przenosi ECC na lata od 2031 do 2033 w prywatnej chmurze SAP. Warunki są surowe. „Systemy muszą zostać zmigrowane do SAP ERP, private edition na SAP HANA przed 31 grudnia 2030.” HANA jest jedyną wspieraną bazą danych, opcja jest dostępna tylko razem z planem max success na lata od 2031 do 2033, a SAP ustala minimum 2 TB dla systemów objętych tą subskrypcją. SAP mówi, że jest ona przeznaczona dla „naszych największych i najbardziej złożonych klientów SAP ERP”. „Równoważne warunki handlowe” oferowane przez SAP dotyczyły klientów, którzy zobowiązali się do private edition do końca 2025.

Niezależnie od wybranego poziomu zadaj SAP i swojemu partnerowi jedno pytanie na piśmie: które zmiany prawne (podatki, płace, formaty e-faktur) nadal będą trafiać do Twojego systemu ECC i do kiedy. Dla niemieckiej firmy sama ta odpowiedź może przesądzić, czy pozostanie przy ECC ma sens.

Co robi reszta rynku

DSAG, niemieckojęzyczna grupa użytkowników SAP, przeprowadziła swój Investment Report 2026 wśród 198 respondentów między 8 grudnia 2025 a 21 stycznia 2026. Z nich 54% wciąż korzysta z ECC albo starszego Business Suite, wobec 68% w 2024.

Jeśli chodzi o termin, prawie połowa respondentów planuje przejście na S/4HANA do końca 2030, co według DSAG oznacza płacenie za rozszerzone utrzymanie. Kolejne 37% chce przejść do końca 2027, a tylko 4% celuje w 2033 i opcję przejściową private edition.

Przewodniczący DSAG, Jens Hungershausen, podał przyczyny wprost: niedobór specjalistów, równoległe projekty transformacyjne i ograniczone budżety odsuwają harmonogramy, „nawet jeśli skutkuje to wyższymi kosztami utrzymania”.

Ruszają się też zamawiający publiczni. Nasze własne zestawienie ogłoszeń o zamówieniach publicznych w UE wskazuje mniej więcej 200 postępowań dotyczących migracji na S/4HANA na półrocze w latach 2025 i 2026 oraz ponad 300 w 2026 do początku października, w większości w Niemczech. Praca trwa. Rozkłada się na dłuższym horyzoncie, niż sugerują nagłówki o 2027.

Gdzie naprawdę jest praca

Techniczna konwersja z ECC na S/4HANA jest dobrze wspierana narzędziami przez SAP i jego partnerów. Jeśli masz lekko dostosowane ECC z kilkoma standardowymi interfejsami, Twój integrator robił to wiele razy i większość tego, co poniżej, nie jest Twoim problemem.

Staje się Twoim problemem proporcjonalnie do tego, ile zbudowałeś sam.

Własny kod ABAP: tu projekty się opóźniają

S/4HANA to nie ECC na nowej bazie danych. Części modelu danych się zmieniły. Klienci i dostawcy stają się partnerami biznesowymi (business partners). Księgowania finansowe i magazynowe skonsolidowano w mniejszej liczbie szerszych tabel. Niektóre transakcje i funkcje usunięto albo zastąpiono.

Własny kod, który czyta tabele bezpośrednio, opiera się na punkcie rozszerzeń (exit), który się przeniósł, albo po cichu zakłada kolejność sortowania (HANA jej nie gwarantuje, chyba że zapytanie o nią prosi), może przejść kontrolę składni i mimo to robić nie to, co trzeba. Ten ostatni rodzaj boli najbardziej, bo wychodzi w testach integracyjnych albo po uruchomieniu, a nie w skanie kodu.

Proces, który działa:

1. Najpierw zmierz użycie. Włącz rejestrowanie użycia na produkcji (monitor wywołań ABAP, transakcja SCMON) i zostaw je włączone przez pełne zamknięcie roku. W długo żyjących systemach spora część własnych obiektów często nigdy się nie uruchamia. Kod, którego nikt nie wykonuje, się usuwa, a nie migruje.
2. Uruchom narzędzia analityczne na tym, co zostało. Kontrole SAP znajdują potencjalne problemy. Nie powiedzą Ci, które z nich mają znaczenie dla biznesu.
3. Sklasyfikuj każdy obiekt. Wycofać, zastąpić standardową funkcjonalnością, naprawić na miejscu albo przebudować poza rdzeniem. Jedna decyzja na obiekt, z wyznaczonym właścicielem biznesowym.
4. Testuj według procesów, a nie obiektów. Zmiana kodu to tania część. Udowodnienie, że order-to-cash i zamknięcie miesiąca nadal dają te same liczby, to część kosztowna.

Projekty opóźniają się tu z nudnego powodu: nikt nie policzył wystarczająco wcześnie. Wielkość własnego kodu jest znana tylko z grubsza, ludzie, którzy go napisali, często już odeszli, a prawdziwe ustalenia przychodzą w drugim cyklu testów, gdy data została już ogłoszona wewnątrz firmy.

Interfejsy i PI/PO na tym samym zegarze

ECC rzadko stoi samo. IDoc do magazynu, wywołania RFC i BAPI z hali produkcyjnej, płaskie pliki do banku i doradcy podatkowego, portal klienta czytający widok bazy danych, który ktoś utworzył w 2011. Każde z nich trzeba znaleźć, przetestować, a w niektórych przypadkach przebudować.

Jeśli te interfejsy przechodzą przez SAP Process Integration albo Process Orchestration, w tych samych datach jest drugi termin. Architecture Center SAP mówi, że PI/PO zbliża się do „końca standardowego utrzymania w 2027”, że klienci mogą przedłużyć utrzymanie do 2030 i że potem wsparcie SAP się kończy. SAP kieruje klientów PI/PO do SAP Integration Suite, który ma ocenę migracji i narzędzia do migracji oparte na kreatorach.

Narzędzia pomagają przy standardowych obiektach. Nie powiedzą Ci, które interfejsy wciąż czemuś służą, a własną logikę mapowania nadal musi przeczytać człowiek. Buduj inwentarz z konfiguracji middleware, logów i zaplanowanych zadań, a nie z ankiety. Potem planuj przeprowadzkę ERP i middleware razem. Jeśli robi się je jedno po drugim, każdy interfejs testuje się dwa razy.

Migracja danych

Przy konwersji systemu dane przenoszą się razem z systemem, a wraz z nimi ich jakość. Konwersja na partnerów biznesowych to zwykle pierwsza kolizja: zdublowani klienci, dostawcy, którzy są też klientami, adresy w polach tekstowych, numery podatkowe w niewłaściwych miejscach. Wszystko to trzeba wyczyścić przed konwersją, a nie w jej trakcie.

Przy nowym wdrożeniu wyodrębniasz, czyścisz, przekształcasz i ładujesz dane, a trudną częścią jest uzgodnienie. Dział finansów zatwierdza wynik wtedy, gdy zgadzają się salda i pozycje otwarte, a nie wtedy, gdy kończy się zadanie ładowania. Zbuduj migrację jako powtarzalny kod, który można uruchomić kilkanaście razy na coraz czystszych danych, automatycznie porównując wyniki przy każdym uruchomieniu.

Na każdej ścieżce najpierw zarchiwizuj to, czego już nie potrzebujesz. Mniej danych oznacza krótsze przebiegi konwersji i krótsze okno przestoju.

Rozszerzenia zgodne z clean core

W projekcie pod presją terminu kusi, żeby przenieść każdą modyfikację i obiecać sobie porządki później. Później nie nadchodzi.

SAP nazywa alternatywę clean core: zostaw standardowy system bez modyfikacji i buduj rozszerzenia na interfejsach, które SAP publikuje i utrzymuje w stabilnej postaci, wewnątrz S/4HANA albo obok niego na SAP Business Technology Platform. Nie wszystko może być czyste od pierwszego dnia. Regułę, której da się faktycznie trzymać, można sformułować prościej: nic nowego nie powstaje po staremu. Każda modyfikacja, której unikniesz teraz, to modyfikacja, której nie będziesz testować ponownie przy każdej przyszłej aktualizacji.

Ramy decyzji

Są trzy realistyczne ścieżki i czwarta, której poświęca się mniej uwagi.

Uruchomienie S/4HANA do 31 grudnia 2027. Pasuje do firm, które już zaczęły, mają system w większości standardowy i zarezerwowanego partnera. Od dziś to piętnaście miesięcy, a niewiele działów finansów zaakceptuje przełączenie w środku zamknięcia roku. Jeśli analiza własnego kodu nie została zrobiona, to prawdopodobnie nie jest Twoja ścieżka.

Rozszerzone utrzymanie i uruchomienie do 2030. W tę stronę zmierza większość rynku. Kosztem jest premia dwóch punktów; potwierdź z SAP, jak się ją stosuje, jeśli uruchomisz system w trakcie okresu. Ryzyko polega na tym, że 2030 będzie traktowany tak, jak traktowano 2027: jako odległy, aż nagle przestanie taki być.

Opcja przejściowa private edition do 2033. To oznacza umowę RISE with SAP, HANA, przeniesienie systemu do SAP ERP, private edition przed 31 grudnia 2030, plan max success i minimum 2 TB. Dla średniej firmy rzadko jest to najtańszy sposób na kupienie czasu.

Odejście od SAP. Dla części średnich producentów i dystrybutorów mniejszy ERP to realna opcja. Praca nad interfejsami i danymi się nie zmniejsza. Staje się większością projektu.

Najbliższe sześć miesięcy, niezależnie od wyboru

Od teraz do końca marca 2027 wszystko poniższe się opłaci, na każdej ścieżce:

1. Potwierdź punkt wyjścia. Pakiet rozszerzeń, baza danych, umowa utrzymaniowa. Poproś swój zespół SAP po stronie dostawcy na piśmie o warunki rozszerzonego utrzymania, które Cię dotyczą.
2. Włącz rejestrowanie użycia już teraz, żeby objęło zamknięcie roku 2026.
3. Przeprowadź analizę własnego kodu i wyjdź z niej z liczbą, a nie z wrażeniem: ile obiektów, ile w użyciu, ile dotyka zmienionych części modelu danych.
4. Zbuduj inwentarz interfejsów, łącznie ze wszystkim, co przechodzi przez PI/PO, z właścicielem i decyzją dla każdego interfejsu.
5. Zacznij czyszczenie danych podstawowych, najpierw klientów i dostawców.
6. Przestań dodawać modyfikacje. Nowy rozwój od dziś stosuje zasady clean core.
7. Wpisz podwyżkę opłaty za utrzymanie na 2028 do budżetu na 2027 jako znany koszt, a nie niespodziankę.
8. Zarezerwuj zasoby: partnera, wewnętrzny zespół SAP i programistów, którzy opiekują się systemami wokół SAP. Niedobór specjalistów to jeden z powodów, które członkowie DSAG podają dla opóźniających się harmonogramów.

Licząc wstecz od uruchomienia w 2030: cykle testów i próby przełączenia w 2030, budowa i naprawy w 2029, projektowanie i czyszczenie danych w 2028, analiza teraz. Zapasu jest w tym mniej, niż się wydaje.

Gdzie szukać pomocy

Nie jesteśmy firmą doradczą od funkcjonalności SAP i nie prowadzimy konwersji na S/4HANA; pracujemy obok partnera, który je prowadzi, nad inwentarzem i przebudową interfejsów, kodem migracji danych i jej uzgodnieniem oraz nad aplikacjami zbudowanymi wokół ECC, które muszą przetrwać przeprowadzkę. Tę pracę opisuje nasza strona o modernizacji ERP, a utrzymanie systemów odziedziczonych obejmuje systemy, które zostają tam, gdzie są, do czasu przeprowadzki. Jeśli chcesz, żeby środowisko wokół Twojego ERP zostało policzone, zanim podpiszesz program, napisz na office@c9group.dev.