Jak przejść na SAP Cloud ERP bez ryzyka?

Migracja SAP ECC do SAP S/4HANA Cloud to nie wyłącznie projekt techniczny. To transformacja dotykająca każdego działu firmy — finansów, produkcji, zakupów, sprzedaży i logistyki. Musi się odbyć bez zatrzymania działalności operacyjnej.

Dla CIO firmy produkcyjnej priorytetem jest stabilność systemu i niskie ryzyko projektu. Właśnie ten aspekt liczy się najbardziej — bardziej niż lista funkcji czy harmonogram marketingowy dostawcy.

Ten przewodnik opisuje trzy ścieżki migracji SAP, metodologię bezpiecznego przejścia na SAP Cloud ERP krok po kroku, specyfikę polskiego rynku (KSeF, JPK, Biała Lista VAT) i moment, w którym gotowy pakiet wdrożeniowy jest bezpieczniejszą alternatywą niż projekt transformacji od zera. Docelowym rozwiązaniem dla średnich firm produkcyjnych jest Leverx ReadyCore Manufacturing for SAP GROW Fast — i ten artykuł wyjaśnia, dlaczego.

SAP ECC — koniec wsparcia w 2027 roku: co to oznacza w praktyce

SAP zaplanował zakończenie standardowego wsparcia mainstream dla SAP ECC w 2027 roku. Dla części klientów dostępna jest opcja rozszerzonego wsparcia za dodatkową opłatą, wydłużająca ten okres do 2030 roku — ale to rozwiązanie tymczasowe, nie alternatywa dla migracji.

Co realnie oznacza koniec wsparcia? Po tej dacie organizacje na SAP ECC przestają otrzymywać:

• regularne aktualizacje bezpieczeństwa,
• poprawki błędów krytycznych,
• aktualizacje legislacyjne — co szczególnie istotne dla firm działających w Polsce.

SAP ECC nie obsługuje natywnie KSeF. Kolejne zmiany w wymogach JPK czy Białej Liście VAT po 2027 roku mogą wymagać kosztownych, niestandardowych łatek od zewnętrznych dostawców — zamiast standardowej aktualizacji producenta.

Dla CIO planującego budżet na najbliższe lata kluczowe pytanie nie brzmi „czy migrować", lecz „kiedy zacząć projekt, żeby zakończyć go przed utratą wsparcia". Projekt migracji dla firmy mid-market trwa od kilku miesięcy do ponad roku, w zależności od ścieżki i złożoności środowiska — co oznacza, że organizacje planujące start projektu na 2027 rok i później ryzykują pracę na systemie bez pełnego wsparcia producenta w trakcie samego wdrożenia.

Trzy ścieżki migracji SAP ECC do S/4HANA — Greenfield, Brownfield, Bluefield

SAP definiuje trzy główne ścieżki przejścia z SAP ECC do SAP S/4HANA. Każda ma inny profil ryzyka, czasu realizacji i kosztów, i jest odpowiednia dla innego typu organizacji.

Co to jest SAP Greenfield?

SAP Greenfield to nowe wdrożenie SAP S/4HANA budowane od podstaw. Z poprzedniego systemu migrowane są tylko dane — kartoteki materiałów, dostawców i klientów, otwarte dokumenty finansowe i transakcyjne. Konfiguracja i procesy są projektowane od nowa, z SAP Best Practices jako punktem startowym, bez przenoszenia niestandardowych modyfikacji ze starego środowiska.

Greenfield sprawdza się dla firm z mocno dostosowanym SAP ECC, gdzie Brownfield oznaczałby migrację długu technicznego w całości; dla organizacji chcących wykorzystać migrację jako okazję do uporządkowania procesów biznesowych; dla firm wdrażających ERP po raz pierwszy; oraz dla producentów mid-market, których procesy są zbliżone do standardu branżowego. Zaletą jest czysta architektura Clean Core od pierwszego dnia i niższy koszt utrzymania w całym cyklu życia systemu — kosztem konieczności zaangażowania kluczowych użytkowników w warsztaty fit-gap i zmiany części nawyków pracy.

Co to jest SAP Brownfield?

SAP Brownfield to techniczna konwersja (technical conversion to SAP S/4HANA) istniejącego systemu SAP ECC. Cała konfiguracja, dane historyczne i — co kluczowe — niestandardowe modyfikacje są zachowane i migrowane do nowego środowiska.

Brownfield jest właściwym wyborem dla organizacji z małą liczbą niestandardowych modyfikacji, dla firm, dla których dostęp do transakcji historycznych w nowym systemie jest wymogiem biznesowym, oraz dla tych, które wcześniej już porządkowały swoją architekturę SAP. Zaletą jest zachowanie danych historycznych i mniejsza zmiana dla użytkowników — wyzwaniem jest przeniesienie długu technicznego do S/4HANA i konieczność analizy wpływu każdej modyfikacji na nową architekturę, co dla środowisk z dużą liczbą customizacji znacząco podnosi ryzyko i koszt projektu.

Co to jest Bluefield (Selective Data Transition)?

Ważne doprecyzowanie: „Bluefield" to nieformalna nazwa rynkowa, stosowana powszechnie przez konsultantów i partnerów wdrożeniowych — SAP oficjalnie posługuje się terminem Selective Data Transition (SDT). Eksperci SAP zwracają na to uwagę, więc warto znać oba określenia.

Niezależnie od nazwy, to podejście hybrydowe łączące elementy Greenfield i Brownfield. Firma decyduje, które procesy i dane migrować konwersyjnie, a które projektować od nowa, co umożliwia etapowe wdrożenie — spółka po spółce, region po regionie lub moduł po module.

Bluefield jest właściwy dla holdingów i grup przemysłowych z wieloma podmiotami prawnymi chcących rozłożyć ryzyko projektu, dla firm wychodzących stopniowo z niestandardowych modyfikacji przy zachowaniu ciągłości operacyjnej, oraz dla organizacji, w których część procesów jest już bliska standardowi, a część wymaga głębokiej transformacji. Koszt zarządzania projektem jest wyższy niż w pozostałych ścieżkach, ze względu na techniczną złożoność dwóch podejść realizowanych równolegle.

Porównanie ścieżek migracji SAP (SAP Brownfield vs Greenfield vs Bluefield)

Którą ścieżkę wybrać dla średniej firmy produkcyjnej w Polsce?

Dla większości polskich firm produkcyjnych z segmentu mid-market, działających na SAP ECC, zatrudniających od 100 do 1000 osób i osiągających przychody na poziomie 50–500 mln PLN, rekomendowanym podejściem jest wdrożenie Greenfield z wykorzystaniem predefiniowanych procesów branżowych.

Powód pierwszy: większość firm mid-market ma w SAP ECC setki lub tysiące niestandardowych modyfikacji nagromadzonych przez lata dostosowywania systemu. Brownfield dla takiego środowiska oznacza migrację całego długu technicznego, co czyni projekt ryzykownym i kosztownym. Powód drugi: procesy produkcyjne w segmencie mid-market są zazwyczaj zbliżone do standardu SAP Best Practices — predefiniowane procesy branżowe pokrywają zwykle 80–90% potrzeb typowej polskiej firmy produkcyjnej bez niestandardowych modyfikacji. Powód trzeci: dla podejścia Greenfield w modelu GROW with SAP typowy harmonogram wdrożenia dla standardowego zakresu wynosi 16 tygodni.

Pięć obaw CIO przy migracji SAP — i ile w nich prawdy

Strach przed migracją ERP jest racjonalny — wynika z konkretnych doświadczeń branżowych, nie z awersji do zmian. Warto nazwać te obawy wprost i ocenić, które są uzasadnione, a które wynikają z przestarzałego obrazu projektów ERP.

SAP S/4HANA Cloud vs on-premise — co wybrać przy migracji

Dla większości firm produkcyjnych z segmentu mid-market w Polsce SAP rekomenduje wariant cloud — niższe koszty infrastruktury, automatyczne aktualizacje i natywna gotowość na funkcje AI równoważą ograniczoną możliwość głębokiej customizacji rdzenia, która w praktyce coraz częściej jest postrzegana jako zaleta (Clean Core), nie ograniczenie. Wariant on-premise zachowuje sens dla organizacji z bardzo specyficznymi wymaganiami regulacyjnymi co do lokalizacji danych lub istniejącą, dużą inwestycją w infrastrukturę własną, której amortyzacja nie jest jeszcze zakończona.

Czynniki kosztowe migracji SAP

Koszt migracji SAP nie jest jedną liczbą — zależy od pięciu konkretnych czynników, które warto ocenić przed porównywaniem ofert różnych partnerów wdrożeniowych.

Liczba niestandardowych modyfikacji w SAP ECC. Każda modyfikacja wymaga oceny: czy ma odpowiednik w standardzie S/4HANA, czy może być zrealizowana przez konfigurację, czy wymaga rozszerzenia na SAP BTP. Im więcej customizacji, tym dłuższa i droższa analiza — niezależnie od wybranej ścieżki.

Wybrana ścieżka migracji. Greenfield z predefiniowanym zakresem ma zwykle bardziej przewidywalny koszt początkowy i niższy koszt utrzymania w długim okresie. Brownfield przy dużym długu technicznym bywa droższy, bo koszt analizy i przepisania customizacji rośnie nieproporcjonalnie do wielkości firmy.

Liczba integracji z systemami zewnętrznymi. Każda integracja z MES, WMS, systemem bankowym czy platformą EDI wymaga przeglądu i, często, migracji na standardowe API. Środowiska z dziesiątkami niezdokumentowanych integracji generują koszt odkrywania ich istnienia, zanim zaczną się prace migracyjne.

Wolumen i jakość danych. Duże wolumeny danych z licznymi duplikatami, brakującymi polami lub niespójnościami wymagają więcej iteracji czyszczenia przed migracją produkcyjną — co wydłuża fazę przygotowania i zwiększa budżet na narzędzia migracyjne.

Zakres szkoleń i zarządzania zmianą. Liczba użytkowników, liczba ról wymagających osobnych programów szkoleniowych oraz stopień przyzwyczajenia zespołu do starego interfejsu SAP GUI wpływają na budżet fazy Deploy i długość okresu hypercare potrzebnego do stabilizacji produktywności.

Predefiniowane pakiety wdrożeniowe redukują niewiadome kosztowe związane z pierwszym i drugim czynnikiem przez zamknięcie zakresu przed podpisaniem umowy — ale nie eliminują potrzeby oceny pozostałych trzech czynników w konkretnym środowisku klienta. Konkretny przykład takiego pakietu dla firm produkcyjnych opisujemy w dalszej części artykułu.

Checklist migracji SAP S/4HANA — co sprawdzić przed startem projektu

Poniższa lista kontrolna pomaga ocenić gotowość organizacji do migracji, niezależnie od wybranego partnera wdrożeniowego.

• Wykonano SAP Readiness Check — raport identyfikujący modyfikacje i obiekty wymagające uwagi przy konwersji.
• Zinwentaryzowano integracje — pełna lista systemów zewnętrznych podłączonych do SAP ECC, z opisem mechanizmu i właściciela biznesowego.
• Oceniono jakość danych źródłowych — analiza kartotek materiałów, dostawców i klientów pod kątem duplikatów i kompletności.
• Wybrano ścieżkę migracji — Greenfield, Brownfield lub Bluefield, na podstawie liczby customizacji i wymagań dotyczących danych historycznych.
• Zaplanowano obsługę okresu przejściowego JPK — sposób raportowania za miesiąc, w którym następuje go-live.
• Potwierdzono gotowość lokalizacji polskiej — KSeF, JPK, Biała Lista VAT, Split Payment skonfigurowane i przetestowane przed go-live.
• Zaplanowano szkolenia dla każdej roli — osobne programy dla finansistów, kupców, planistów produkcji i kierowników magazynu.
• Zaplanowano pełny rehearsal go-live — przeprowadzony tydzień przed rzeczywistym uruchomieniem, w pełnym oknie czasowym.
• Przygotowano plan rollback — procedurę powrotu do starego systemu w przypadku krytycznego problemu przy go-live.
• Zaplanowano hypercare — 2–4 tygodnie intensywnego wsparcia po go-live jako standardowy element projektu, nie opcja.

Metodologia bezpiecznej migracji SAP — 6 faz

Bezpieczna migracja SAP nie jest przypadkiem — to efekt metodologii SAP Activate, realizowanej konsekwentnie krok po kroku. Sześć faz, każda z konkretnymi zadaniami i kryteriami odbioru.

• Faza 1 — Discover. SAP Readiness Check skanuje środowisko SAP ECC i identyfikuje modyfikacje wymagające uwagi. Inwentaryzacja integracji i wstępna ocena jakości danych dopełniają obraz. Wynikiem jest Technical Fit Report z rekomendacją ścieżki migracji, szacunkowym zakresem i budżetem.

• Faza 2 — Prepare. Uruchomienie systemu deweloperskiego i testowego, konfiguracja podstawowych parametrów organizacyjnych, szkolenie wstępne zespołu projektowego klienta oraz pierwsza analiza jakości danych przez narzędzie migracyjne DataLark.

• Faza 3 — Explore. Warsztaty fit-gap dla każdego obszaru funkcjonalnego — finansów, zakupów, sprzedaży, produkcji. Kluczowi użytkownicy porównują standardowe procesy SAP z obecnym sposobem działania i decydują, co jest obsługiwane bez zmian, co wymaga konfiguracji, a co rozszerzenia przez SAP BTP. Priorytetem jest dopasowanie procesu do standardu, nie odwrotnie.

• Faza 4 — Realize. Konfiguracja systemu zgodnie z decyzjami z fazy Explore, prace integracyjne ze standardowymi API, iteracyjne migracje testowe danych oraz testy jednostkowe kluczowych procesów. Dla pakietu mid-market ta faza zajmuje typowo 4–5 tygodni.

• Faza 5 — Deploy. Testy akceptacyjne użytkownika (UAT), szkolenia specyficzne dla każdej roli, pełny rehearsal go-live tydzień przed startem oraz ostateczna walidacja danych przez kluczowych użytkowników każdego działu.

• Faza 6 — Run. Migracja produkcyjna w oknie weekendowym zgodnie z run-bookiem, z planem rollback w razie poważnego problemu. Po uruchomieniu — hypercare trwający 2–4 tygodnie, a następnie przejście w standardowe wsparcie AMS.

Najczęstsze błędy przy migracji SAP

Pięć błędów powtarza się w projektach, które trafiają do LeverX po nieudanej pierwszej próbie realizowanej samodzielnie lub przez innego partnera.

Wybór ścieżki migracji przed analizą stanu obecnego. Decyzja „robimy Brownfield, bo jest szybszy" podjęta bez SAP Readiness Check często okazuje się błędna, gdy analiza ujawnia setki niestandardowych modyfikacji, które trzeba by przenieść.

Migrowanie niestandardowego kodu bez oceny alternatyw. Część modyfikacji SAP ECC ma swój odpowiednik w standardowej funkcjonalności S/4HANA. Migrowanie ich mechanicznie, bez sprawdzenia, czy nie da się ich zastąpić standardem, oznacza utrzymywanie kosztu, którego można uniknąć.

Niedoszacowanie czasu na migrację i walidację danych. Jednorazowa migracja danych „na sucho", bez kilku iteracji testowych, regularnie ujawnia problemy z jakością danych dopiero w tygodniu go-live — najgorszym możliwym momencie na ich odkrycie.

Pomijanie pełnego rehearsal go-live. Pójście na produkcję z nieprzetestowanym harmonogramem godzinowym migracji (run-book) jest jednym z najczęstszych powodów przedłużających się przestojów przy uruchomieniu.

Traktowanie szkoleń jako formalności. Krótkie, ogólne szkolenie dla wszystkich użytkowników naraz, bez programów dopasowanych do konkretnej roli, prowadzi do dłuższego okresu obniżonej produktywności po go-live niż dobrze zaplanowany, dedykowany program szkoleniowy.

Specyfika polskiego rynku — KSeF, JPK, Biała Lista VAT

Polska jest jednym z bardziej wymagających rynków regulacyjnych w Europie pod kątem cyfrowych obowiązków podatkowych. Dla CIO planującego migrację SAP ECC zgodność lokalizacji jest wymogiem bezwzględnym, nie opcją do rozważenia później.

KSeF — harmonogram wejścia obowiązku i co to znaczy dla migracji

Obowiązek wystawiania faktur w Krajowym Systemie e-Faktur (KSeF) wchodzi w Polsce fazowo: od 1 lutego 2026 roku dla podatników, których wartość sprzedaży przekroczyła 200 mln zł, oraz od 1 kwietnia 2026 roku dla pozostałych przedsiębiorców VAT. Mikroprzedsiębiorcy z niewielką sprzedażą miesięczną mają dodatkowy czas do 1 stycznia 2027 roku, a sankcje za naruszenia obowiązków związanych z wystawianiem faktur w KSeF zaczną obowiązywać od 1 stycznia 2027 roku.

Dla firmy planującej migrację SAP ECC oznacza to, że wybór systemu z natywną obsługą KSeF jest już dziś warunkiem koniecznym, nie przyszłym wymogiem. SAP S/4HANA Cloud Public Edition obsługuje KSeF jako wbudowany element polskiej lokalizacji — przy każdej fakturze sprzedaży system automatycznie wysyła ją do KSeF, odbiera UPO i archiwizuje dokument. SAP ECC, w przeciwieństwie do S/4HANA Cloud, nie obsługuje KSeF natywnie i wymaga osobnej integracji lub modułu zewnętrznego, którego utrzymanie po 2027 roku — gdy ECC traci standardowe wsparcie SAP — może stać się coraz trudniejsze i kosztowniejsze.

JPK — ciągłość raportowania w miesiącu go-live

Częstym pytaniem przy migracji jest ciągłość raportowania JPK_V7M w miesiącu, w którym odbywa się go-live — dane są częściowo w starym systemie, częściowo w nowym. To standardowy scenariusz planowany w fazie Prepare: dla okresu przejściowego JPK jest generowany na podstawie danych z obu systemów, stary ECC dostarcza dane do dnia go-live, nowy S/4HANA Cloud — za okres po go-live.

Biała Lista VAT i ciągłość rozliczeń

Biała Lista podatników VAT wymaga weryfikacji rachunku bankowego dostawcy przy płatnościach powyżej 15 000 PLN. W SAP S/4HANA Cloud weryfikacja jest wbudowana w standardowy proces płatności i archiwizowana jako dowód należytej staranności. Migracja w trakcie roku podatkowego wymaga szczególnej uwagi na ciągłość danych — otwarcie bilansu w nowym systemie musi być zgodne z zamknięciem w starym, a salda kont, otwarte pozycje i niezrealizowane różnice kursowe powinny być weryfikowane przez audytora wewnętrznego przed uruchomieniem.

Clean Core jako fundament bezpiecznej migracji

Jedną z najważniejszych decyzji przy migracji jest określenie, które elementy obecnego środowiska migrować, a które przebudować z zastosowaniem architektury Clean Core. Zasada: dane migrujemy, logikę biznesową przebudowujemy. Każda niestandardowa modyfikacja ABAP migrowana mechanicznie do S/4HANA to element długu technicznego w nowym środowisku — droższe aktualizacje, bardziej kruche integracje, mniej elastyczny system w przyszłości.

Inwentaryzacja customizacji przed migracją dzieli je na trzy grupy: funkcje już zastąpione przez standard S/4HANA (np. nowy interfejs Fiori zastępujący niestandardowe ekrany), funkcje możliwe do realizacji przez konfigurację (bez modyfikacji kodu) oraz funkcje wymagające rozszerzenia przez SAP BTP, gdzie działają poza rdzeniem, nie naruszając jego czystości. Wynikiem tej analizy jest ocena gotowości do Clean Core — podstawa wyceny projektu migracji.

Migracja integracji bez przerw w działaniu

Integracje z systemami zewnętrznymi to element migracji, którego CIO obawia się najbardziej. Pierwszym krokiem jest pełna inwentaryzacja: system zewnętrzny, kierunek przepływu danych, mechanizm integracji (IDOC, RFC, BAPI, plik flat, niestandardowy ABAP), częstotliwość i właściciel biznesowy. Taka inwentaryzacja regularnie ujawnia integracje, o których dział IT nie wiedział — przygotowane nieformalnie przez użytkowników biznesowych i działające bez dokumentacji.

SAP S/4HANA Cloud oferuje ponad 1000 standardowych interfejsów API, udokumentowanych i gwarantowanych jako backward-compatible. Większość tradycyjnych integracji opartych na IDOC, RFC i BAPI ma swój odpowiednik w standardowych API OData lub REST. Migracja na standardowe API jest jednorazowym wysiłkiem, który przynosi długoterminową stabilność — bez konieczności ponownej pracy przy każdej kwartalnej aktualizacji. Integracje bez odpowiednika w standardzie (np. ze starszymi systemami SCADA) są realizowane przez SAP BTP Integration Suite, działający poza rdzeniem systemu.

Kiedy predefiniowany pakiet ma sens — ReadyCore Manufacturing

Dla firm mid-market spełniających profil opisany wcześniej w tym artykule, predefiniowany pakiet wdrożeniowy bywa bezpieczniejszą alternatywą niż projekt transformacji budowany od zera — z czterech konkretnych powodów.

Procesy biznesowe wbudowane w pakiet (Order-to-Cash, Source-to-Pay, Plan-to-Produce, Record-to-Report) to SAP Best Practices, przetestowane w tysiącach wdrożeń — firma waliduje, czy gotowe procesy pasują do jej potrzeb, zamiast projektować je od podstaw i liczyć, że zadziałają. Polska lokalizacja jest certyfikowana i aktualizowana przez SAP, nie przez lokalnego partnera, co eliminuje ryzyko spóźnionej aktualizacji po zmianie przepisów. Zamknięty zakres uzgodniony przed podpisaniem umowy strukturalnie ogranicza ryzyko scope creep — każda zmiana poza zakresem jest osobnym change requestem z osobną wyceną. Wreszcie, iteracyjna migracja danych przez DataLark, narzędzie LeverX, ujawnia problemy z jakością danych na długo przed go-live, nie w pierwszym tygodniu operacyjnym.

Organizacje o bardziej złożonych wymaganiach — grupy wielozakładowe, firmy z wieloma podmiotami prawnymi w kilku krajach, producenci z wysoce niestandardowymi procesami — potrzebują indywidualnego projektu SAP S/4HANA Enterprise. Decyzja między tymi dwiema ścieżkami wymaga analizy konkretnego środowiska, nie ogólnych kryteriów — to właśnie cel bezpłatnej sesji technicznej opisanej w sekcji kontaktowej.

10 zasad bezpiecznej migracji SAP do chmury

1. Zacznij od Technical Fit Assessment, nie od wyboru rozwiązania.
2. Traktuj dane i logikę osobno — dane migruj, logikę przebuduj z Clean Core.
3. Zamknij zakres przed projektem, nie w jego trakcie.
4. Włącz kluczowych użytkowników biznesowych do fazy Explore.
5. Migruj dane iteracyjnie, z wielokrotną walidacją, nie jednorazowo.
6. Przeprowadź pełny rehearsal go-live tydzień przed startem.
7. Zaplanuj hypercare jako standardowy element projektu, nie opcję.
8. Wybierz partnera z doświadczeniem w polskiej lokalizacji SAP.
9. Archiwizuj dane historyczne zgodnie z wymogami podatkowymi i audytowymi.
10. Nie migruj długu technicznego — jeśli Brownfield oznacza przeniesienie setek modyfikacji, rozważ Greenfield.

Czy migracja do SAP S/4HANA jest właściwym krokiem dla Twojej firmy?

Odpowiedź zależy od konkretnego stanu środowiska ERP, liczby customizacji i priorytetów biznesowych — nie da się jej udzielić bez analizy. Dlatego pierwszym krokiem nie jest wybór dostawcy, lecz bezpłatna sesja techniczna z ekspertem SAP.

Podczas SAP Cloud ERP Technical Fit & Migration Session eksperci LeverX ocenią stan obecnego środowiska SAP ECC, zidentyfikują optymalną ścieżkę migracji (Greenfield, Brownfield lub Bluefield), oszacują realny czas i zakres projektu oraz odpowiedzą na konkretne pytania techniczne — bez prezentacji sprzedażowej i bez zobowiązań. Wynikiem sesji jest pisemny Technical Fit Report; jeżeli ReadyCore Manufacturing nie jest właściwym rozwiązaniem dla danej firmy, eksperci LeverX zaproponują alternatywę.

Ponad 20 lat doświadczenia w SAP

1 500+ zrealizowanych projektów

2 200+ certyfikowanych specjalistów

FAQ — Najczęstsze pytania o migrację SAP ECC do S/4HANA Cloud

Co to jest SAP Greenfield?

SAP Greenfield to nowe wdrożenie SAP S/4HANA budowane od podstaw, z SAP Best Practices jako punktem startowym. Z poprzedniego systemu migrowane są tylko dane — kartoteki, otwarte dokumenty finansowe i transakcyjne — a konfiguracja i procesy są projektowane od nowa, bez przenoszenia niestandardowych modyfikacji ze starego środowiska.

Co to jest SAP Brownfield?

SAP Brownfield to techniczna konwersja istniejącego systemu SAP ECC do SAP S/4HANA, w której cała konfiguracja, dane historyczne i niestandardowe modyfikacje są zachowane i przenoszone do nowego środowiska. Jest szybsza dla środowisk bliskich standardowi SAP, ale przenosi cały dotychczasowy dług techniczny do nowego systemu.

Czym różni się SAP Brownfield od Greenfield?https://leverx.com/pl/solutions/sap-hana-cloud

Brownfield zachowuje konfigurację, dane historyczne i niestandardowe modyfikacje SAP ECC, przenosząc je technicznie do S/4HANA. Greenfield migruje tylko dane, a procesy projektuje od nowa na bazie SAP Best Practices, eliminując dług techniczny. Dla firm z dużą liczbą customizacji Greenfield jest zwykle bezpieczniejszy; dla środowisk bliskich standardowi Brownfield bywa szybszy.

Czym jest Bluefield (Selective Data Transition) w migracji SAP?

Bluefield to nieformalna nazwa rynkowa — SAP oficjalnie nie używa tego terminu, lecz Selective Data Transition (SDT). Niezależnie od nazwy, to podejście hybrydowe łączące elementy Greenfield i Brownfield. Firma decyduje, które procesy migrować konwersyjnie, a które projektować od nowa, co umożliwia etapowe wdrożenie spółka po spółce lub region po regionie. Jest właściwe dla holdingów z wieloma podmiotami prawnymi.

Co oznacza koniec wsparcia SAP ECC w 2027 roku?

SAP planuje zakończenie standardowego wsparcia mainstream dla SAP ECC w 2027 roku, z opcją płatnego rozszerzonego wsparcia do 2030 roku dla części klientów. Po tej dacie organizacje na ECC tracą dostęp do regularnych aktualizacji bezpieczeństwa i poprawek legislacyjnych SAP, co jest istotnym ryzykiem dla firm w Polsce, gdzie obowiązki podatkowe (KSeF, JPK) zmieniają się regularnie.

Ile trwa migracja SAP ECC do S/4HANA Cloud?

Czas zależy od ścieżki i liczby customizacji. Predefiniowany pakiet dla firm mid-market, taki jak ReadyCore Manufacturing — pakiet LeverX w ramach programu GROW with SAP — zakłada typowy harmonogram 16 tygodni, potwierdzony w dotychczas zrealizowanych projektach. Indywidualne projekty SAP S/4HANA Enterprise trwają zwykle 12–24 miesiące, zależnie od zakresu i złożoności.

Czy SAP S/4HANA Cloud obsługuje KSeF i JPK po migracji z SAP ECC?

Tak. SAP S/4HANA Cloud Public Edition zawiera wbudowaną polską lokalizację — KSeF, JPK w kilku wariantach, Białą Listę VAT i Split Payment — aktualizowaną automatycznie co kwartał przez SAP. Jest to istotne, bo obowiązek wystawiania faktur w KSeF wchodzi w Polsce fazowo od 1 lutego 2026 r. (duzi podatnicy) i od 1 kwietnia 2026 r. (pozostali podatnicy VAT).

Jakie są główne czynniki kosztowe migracji SAP?

Koszt zależy głównie od liczby niestandardowych modyfikacji w SAP ECC, wybranej ścieżki migracji, liczby integracji z systemami zewnętrznymi, wolumenu i jakości danych do migracji oraz zakresu szkoleń użytkowników. Predefiniowane pakiety jak ReadyCore Manufacturing eliminują część niewiadomych kosztowych przez zamknięty zakres ustalony przed projektem.

SAP S/4HANA Cloud czy on-premise — co wybrać?

SAP S/4HANA Cloud oznacza niższe koszty infrastruktury, automatyczne aktualizacje kwartalne i natywną gotowość na AI (SAP Joule), kosztem ograniczonej możliwości głębokiej customizacji rdzenia. Wariant on-premise daje pełną kontrolę nad infrastrukturą i większą swobodę modyfikacji, kosztem wyższych nakładów na utrzymanie. Dla większości firm mid-market w Polsce SAP rekomenduje wariant cloud.

Jakie są najczęstsze błędy przy migracji SAP?

Najczęstsze błędy to: wybór ścieżki migracji przed wykonaniem SAP Readiness Check, migrowanie niestandardowego kodu bez oceny, czy nie da się go zastąpić standardem, niedoszacowanie czasu na migrację i walidację danych, pomijanie pełnego rehearsal go-live oraz traktowanie szkoleń jako formalności, nie elementu krytycznego dla adopcji nowego systemu.

Czy ReadyCore Manufacturing jest przeznaczony dla każdej firmy produkcyjnej?

Nie. ReadyCore Manufacturing — pakiet LeverX w ramach programu GROW with SAP — jest zaprojektowany dla średnich firm produkcyjnych z jednym lub kilkoma zakładami w Polsce i procesami zbliżonymi do standardu SAP. Firmy wielozakładowe, z wysoce niestandardowymi procesami lub złożoną architekturą wielu podmiotów prawnych zwykle wymagają indywidualnego projektu SAP S/4HANA Enterprise.

Jak zapewnić ciągłość integracji przy migracji SAP do chmury?

Ciągłość zapewnia inwentaryzacja wszystkich istniejących integracji przed projektem, ocena możliwości migracji na standardowe API SAP S/4HANA Cloud (ponad 1000 interfejsów OData/REST) oraz konfiguracja integracji bez odpowiednika w standardzie przez SAP BTP Integration Suite. Migracja na standardowe API jest jednorazowym wysiłkiem zapewniającym stabilność przez kolejne aktualizacje kwartalne.