Modernizacja OS/DB pod SAP
Zmień bazę danych i system operacyjny pod aplikacją, bez ruszania samej aplikacji
Twój SAP działa na warstwie, o której rzadko myślisz, dopóki nie zacznie sprawiać problemów: na konkretnej bazie danych i konkretnym systemie operacyjnym. Gdy baza wychodzi z certyfikacji, system operacyjny kończy wsparcie, koszty licencji rosną albo szykujesz się do konwersji do S/4HANA, trzeba zmodernizować ten fundament. Przeprowadzamy migrację bazy do SAP HANA i migrację systemu operacyjnego do Linux, AIX, Windows narzędziami SAP, z minimalnym downtime.
anyDB → HANA
Oracle, DB2, SQL Server do SAP HANA
OS → Linux
migracja systemu operacyjnego
heterogeneous
system copy ze zmianą OS lub DB
SAP tools
SWPM, DMO, R3load
Aplikacja SAP działa, ale fundament pod nią się starzeje
W architekturze SAP aplikacja to jedno, a baza danych i system operacyjny pod nią to drugie. Ta warstwa fundamentu rzadko jest tematem rozmów, dopóki coś nie zmusi do działania: koniec wsparcia, rosnące koszty licencji, konwersja do S/4HANA albo przestarzały sprzęt. Wtedy okazuje się, że modernizacja fundamentu to projekt sam w sobie.
Pewnie znasz przynajmniej jedną z tych sytuacji:
-
Twoja baza danych wychodzi z certyfikacji SAP.
SAP konsekwentnie pcha klientów w stronę bazy SAP HANA i ogranicza wsparcie dla baz trzecich (Oracle, DB2, SQL Server) pod nowszymi wersjami. Twoja kombinacja bazy i wersji SAP może przestać być certyfikowana, co oznacza brak wsparcia dla całego środowiska. -
Płacisz wysokie licencje za bazę danych.
Licencje Oracle, DB2 czy innych baz trzecich pod SAP to często znaczący koszt. Migracja do bazy SAP HANA albo do innej bazy zmienia strukturę kosztów, szczególnie gdy łączysz to z przejściem do chmury. -
Twój system operacyjny kończy wsparcie.
Stare wersje Windows Server, AIX, Solaris czy HP-UX wychodzą ze wsparcia. SAP na niewspieranym systemie operacyjnym to ryzyko bezpieczeństwa i brak aktualizacji kernela dla nowych komponentów. -
Szykujesz się do S/4HANA, ale jesteś na bazie trzeciej.
S/4HANA działa wyłącznie na HANA. Jeśli planujesz konwersję, a obecnie jesteś na Oracle czy SQL Server, migracja bazy do HANA jest krokiem, który i tak musisz wykonać. Można go zrobić osobno albo połączyć z konwersją. -
Twój sprzęt jest u kresu i myślisz o chmurze.
Serwery pod SAP starzeją się, a odnowienie to duża inwestycja w hardware. To naturalny moment, żeby przy okazji zmienić bazę, system operacyjny albo przejść do chmury, zamiast kupować kolejny sprzęt pod stare środowisko.
Modernizujemy fundament narzędziami SAP, z analizą zależności i minimalnym downtime
Migracja OS/DB to projekt czysto techniczny, ale o dużym wpływie na ciągłość działania, bo dotyczy fundamentu, na którym stoi produkcyjny SAP. Klucz to dobór właściwej metody (zależnie od tego, co zmieniasz), narzędzia SAP i dokładne planowanie downtime. Prowadzimy to jako projekt BASIS, z pełną kontrolą nad każdym krokiem.
Prowadzimy modernizację OS/DB w czterech etapach:
Analiza i dobór metody
Sprawdzamy, co modernizujesz: tylko bazę, tylko system operacyjny, czy oba naraz, ewentualnie w połączeniu z upgrade lub przejściem do chmury. Od tego zależy metoda: DMO (gdy migracja bazy do HANA, opcjonalnie z upgrade) lub klasyczny heterogeneous system copy (gdy zmiana systemu operacyjnego). Robimy sizing docelowego sprzętu lub instancji (Quick Sizer).
Przygotowanie systemu i środowiska docelowego
Przygotowujemy system źródłowy (w razie potrzeby weryfikacja wersji, konwersja do Unicode oraz obligatoryjny podział środowisk dual-stack (ABAP/Java split), wynikający z faktu, że SAP HANA wymaga architektury typu single-stack) ii środowisko docelowe (baz danych SAP HANA na certyfikowanym sprzęcie lub w chmurze, system operacyjny Linux). Sprawdzamy kompatybilność add-onów i kombinacji OS/DB z platformą informacyjną SAP PAM ( Product Availability Matrix).
Migracja techniczna (export/import)
Wykonujemy migrację właściwą metodą: dla zmiany bazy do HANA używamy DMO (łączy migrację z opcjonalnym upgrade) lub klasycznego export/import (R3load, Migration Monitor) dla zmiany systemu operacyjnego. Optymalizujemy parallel export/import, żeby skrócić downtime. Najpierw na środowiskach testowych, z pomiarem czasu i przebiegami optymalizującymi.
Walidacja, optymalizacja i stabilizacja
Po migracji walidujemy spójność danych, optymalizujemy wydajność (parametry bazy danych SAP HANA, table placement dla scale-out), testujemy procesy. Po go-live stabilizujemy i przekazujemy lub przejmujemy bieżące zarządzanie nowym środowiskiem..
Twoja baza wychodzi z certyfikacji albo system operacyjny kończy wsparcie?
Przeanalizujemy Twoje środowisko OS/DB, dobierzemy metodę migracji i oszacujemy downtime. Pokażemy, czy łączyć to z upgrade lub przejściem do chmury, czy zrobić to osobno.
Co dokładnie obejmuje modernizacja warstwy OS/DB
Modernizacja OS/DB to kilka rodzajów zmian, które można wykonać osobno lub łączyć. Każda ma inne narzędzia i inne ryzyka.
01
Migracja bazy danych do SAP HANA (anyDB → HANA)
Przeniesienie SAP z bazy trzeciej (Oracle, DB2, SQL Server, MaxDB, Sybase ASE) na SAP HANA, bazę in-memory SAP. To najczęstszy scenariusz, napędzany wymogiem HANA dla S/4HANA, wydajnością i strukturą kosztów. Wymaga, by ECC był na odpowiednio nowej wersji (zwykle EHP7 lub nowszej).
02
Migracja systemu operacyjnego (do Linux)
Przeniesienie SAP ze starszego systemu operacyjnego (Windows Server, AIX, Solaris, HP-UX) na Linux (SUSE lub Red Hat), który jest standardem dla HANA i nowoczesnych wdrożeń SAP. Zmiana systemu operacyjnego wymaga klasycznego heterogeneous system copy, bo DMO sam nie zmienia systemu operacyjnego serwera aplikacyjnego.
03
Migracja anyDB do anyDB
Czasem cel to nie HANA, tylko inna baza trzecia (na przykład zmiana z drogiej licencji na inną). Realizujemy też takie migracje, gdy mają uzasadnienie kosztowe lub strategiczne.
04
Unicode conversion
Przejście z systemu non-Unicode na Unicode (wymóg nowszych wersji SAP), realizowane przez SWPM przy okazji migracji.
05
System move i hardware refresh
Przeniesienie SAP na nowy sprzęt lub do chmury, z zachowaniem lub zmianą bazy i systemu operacyjnego. Naturalny moment na modernizację całego środowiska zamiast inwestycji w stary hardware.
DMO czy klasyczny system copy: dobór metody do tego, co zmieniasz
Wybór metody migracji zależy od tego, co dokładnie modernizujesz. To rozróżnienie często umyka, a ma realne konsekwencje dla zakresu i czasu projektu.
DMO (Database Migration Option) of SUM
DMO łączy migrację bazy danych do HANA z opcjonalnym upgrade SAP, Unicode conversion i innymi krokami w jednym przebiegu. To efektywne, gdy migrujesz bazę do HANA i przy okazji aktualizujesz system. Ważne ograniczenie: DMO migruje bazę i aktualizuje aplikację, ale sam nie zmienia systemu operacyjnego serwera aplikacyjnego. Wariant DMO with System Move pozwala dodatkowo przenieść system na nowy host.
Classical migration (heterogeneous system copy)
Gdy zmieniasz system operacyjny serwera bazodanowego, używamy klasycznej metody backup/restore lub export/import (SWPM z R3load i Migration Monitor). System jest eksportowany ze źródła i importowany na docelowym systemie operacyjnym i bazie. To metoda wymagana przy zmianie systemu operacyjnego i przy bardziej złożonych scenariuszach.
Narzędzia, których używamy:
- SWPM (Software Provisioning Manager): narzędzie system copy (SWPM 1.0 dla systemów non-S/4, SWPM 2.0 dla S/4).
- R3load, R3ldctl, R3szchk: silniki export i import danych.
- Migration Monitor: orkiestracja równoległego eksportu i importu, kluczowa dla skrócenia downtime.
- DMO of SUM: połączona migracja i upgrade do HANA.
Jak dobieramy metodę
Tylko migracja baza do SAP HANA, ewentualnie z upgrade: DMO. Zmiana systemu operacyjnego: klasyczna operacja SAP system copy. Oba naraz lub przeniesienie na nowy host: kombinacja metod. Decyzję podejmujemy po analizie tego, co modernizujesz i jaki masz zapotrzebowanie na łączenie zmian.
Modernizacja fundamentu to często część większej układanki
Migracja OS/DB rzadko jest celem samym w sobie. Najczęściej jest fragmentem większej decyzji o przyszłości SAP. Pomagamy ułożyć ją we właściwej kolejności wobec innych projektów.
OS/DB a konwersja do S/4HANA
S/4HANA działa wyłącznie na bazie SAP HANA, więc migracja bazy do HANA jest prerekwizytem konwersji. Można ją zrobić osobno (najpierw migracja do HANA na ECC, potem konwersja) albo połączyć (DMO łączy migrację do HANA z konwersją). Doradzamy, co ma sens dla Twojego ryzyka i harmonogramu.
OS/DB a migracja do chmury
Przeniesienie SAP do chmury to naturalny moment na zmianę bazy i systemu operacyjnego, zamiast przenoszenia starego środowiska jeden do jednego. Wariant DMO with System Move pozwala połączyć migrację bazy z przeniesieniem na hyperscaler.
OS/DB a upgrade
DMO łączy migrację bazy z upgrade SAP w jednej procedurze, co bywa efektywne, gdy i tak planujesz oba.
Modernizacja jako osobny projekt
Czasem modernizacja OS/DB ma sens jako samodzielny projekt: koniec wsparcia bazy lub systemu operacyjnego, redukcja kosztów licencji, hardware refresh, bez jednoczesnej konwersji czy przejścia do chmury. Wtedy prowadzimy ją end-to-end jako czysty projekt BASIS.
Dlaczego warto modernizować OS/DB z 7Technology
To kompetencja zespołu BASIS, który mamy w organizacji
Migracja OS/DB to projekt BASIS: SWPM, DMO, R3load, sizing HANA, optymalizacja. Mamy te kompetencje u siebie, więc prowadzimy migrację od analizy po stabilizację, bez zlecania kluczowych części na zewnątrz.
Dobieramy metodę do tego, co naprawdę zmieniasz
DMO, klasyczny system copy, DMO with System Move. Każda metoda pasuje do innego scenariusza. Dobieramy ją na podstawie analizy, zamiast forsować jedną, co ma realny wpływ na zakres, ryzyko i downtime.
Układamy modernizację we właściwej kolejności
Migracja OS/DB rzadko jest osobna. Pomagamy ułożyć ją wobec konwersji do S/4HANA, migracji do chmury i upgrade, żeby nie robić tej samej pracy dwa razy ani nie powodować podwójnego ryzyka.
Minimalizujemy downtime produkcji
Migracja fundamentu produkcyjnego SAP to ryzyko przestoju. Optymalizujemy równoległy export/import (Migration Monitor), testujemy czasy na środowiskach nieprodukcyjnych i planujemy cutover/go-live tak, żeby zmieścić się w oknie, które zaakceptujesz.
Zostajemy po migracji
Nowe środowisko (HANA, Linux) wymaga bieżącego zarządzania: monitoring, optymalizacja, aktualizacje. W modelu Managed Services SAP przejmujemy tę odpowiedzialność.
Co mówią o nas klienci
"Migracja produkcyjnego SAP była dla nas projektem o najwyższym ryzyku. 7Technology przeprowadziło nas przez nią bez ani jednego nieplanowanego przestoju."
Lucyna Michniewicz
CIO @ VOX
"Szukaliśmy partnera, który weźmie odpowiedzialność za całość, a nie odeśle nas do kolejnego podwykonawcy. Po kilku latach współpracy wiem, że trafiliśmy dobrze."
Edyta Sapijaszko
CIO @ Herbapol
"Automatyzacja procesów na WEBCON BPS zdjęła z naszych zespołów dziesiątki godzin pracy ręcznej miesięcznie. Wdrożenie poszło sprawnie i zgodnie z planem."
Magdalena Obidowska
Project Manager @ Oceanic
Projekty, za które wzięliśmy odpowiedzialność
Środowisko IT dealera Mercedes-Benz w Google Cloud
Migracja kluczowych systemów biznesowych do chmury, a następnie przejęcie i integracja środowiska IT nowego salonu w Sosnowcu - bez przerwy w pracy sprzedaży i serwisu.
System:
Środowisko IT - ok. 55 systemów (m.in. ERP, DMS, systemy kadrowo-płacowe i księgowe, SAP)
Technologia:
Google Cloud Platform, Terraform, SAP
Kluczowe osiągnięcia:
Jedno środowisko dla 5 lokalizacji; przejęcie salonu bez przestoju
Automatyzacja sortowania półtusz w chłodni
Decyzję o przydziale półtuszy do zamówienia zamiast operatora podejmuje algorytm, a rozjazdy na torach przestawiają się same - na podstawie sześciu parametrów każdej sztuki.
System:
System MES 7Technology + dedykowany moduł automatyzacji chłodni
Technologia:
RFID w hakach, sterowniki PLC, integracja z wagami i klasyfikacją mięsności
Kluczowe osiągnięcia:
Kilku pracowników na zmianę → 1 operator; reakcja na zmianę zamówienia w kilka sekund
Od papierowych kart do pełnej identyfikowalności z 7MES
Wdrożenie objęło cały zakład - od rampy przyjęć, przez rozbiór i produkcję, po kontrolę załadunku pod dokiem - z pełną genealogią każdej partii.
System:
7MES (autorski system klasy MES 7Technology)
Technologia:
Comarch ERP XL, wagi hakowe / najazdowe / stanowiskowe / laboratoryjne, skanery i terminale dotykowe
Kluczowe osiągnięcia:
Kompletacja krótsza o 4–5 godzin; genealogia partii od ręki zamiast w dni
Cztery lata cyfryzacji na WEBCON BPS, SAP i AI
Kilkanaście procesów w WEBCON zintegrowanych z SAP, a najnowszy etap zamienił ponad 40 000 dokumentów surowcowych w przeszukiwalną bazę wiedzy dla działu badań.
System:
WEBCON BPS + SAP (moduły FI i MM)
Technologia:
WEBCON BPS, SAP Gateway (OData, REST API), Google Cloud (Gemini, BigQuery, Looker Studio), OCR, KSeF, Autenti
Kluczowe osiągnięcia:
Wyszukiwanie surowca z 2–4 godzin do poniżej 30 sekund
Powiązane technologie i usługi
Technologie
Usługi
Konsultacje
Często zadawane pytania o modernizację OS/DB pod SAP
Migracja OS/DB to zmiana warstwy fundamentu pod aplikacją SAP: systemu operacyjnego, bazy danych lub obu, bez zmiany samej aplikacji. W terminologii SAP to heterogeneous system copy, gdy zmienia się system operacyjny lub baza. Typowe scenariusze to migracja bazy do SAP HANA (z Oracle, DB2, SQL Server) i migracja systemu operacyjnego na Linux.
Migracja OS/DB zmienia fundament techniczny (baza, system operacyjny) pod aplikacją, nie zmieniając samej aplikacji. Konwersja do S/4HANA zmienia aplikację (z ECC na S/4HANA). Są powiązane: S/4HANA wymaga bazy HANA, więc migracja bazy do HANA jest prerekwizytem konwersji. Można je zrobić osobno albo połączyć.
Kilka powodów: SAP ogranicza wsparcie dla baz trzecich pod nowszymi wersjami, HANA jest wymagana dla S/4HANA, daje wydajność in-memory, a migracja zmienia strukturę kosztów licencji (szczególnie przy drogich licencjach Oracle). Jeśli planujesz S/4HANA, migracja do HANA jest krokiem, który i tak wykonasz.
DMO (Database Migration Option) to opcja Software Update Manager, która łączy migrację bazy do HANA z opcjonalnym upgrade SAP i Unicode conversion w jednej procedurze. Stosujemy je, gdy migrujesz bazę do HANA, ewentualnie z jednoczesnym upgrade. Ważne: DMO sam nie zmienia systemu operacyjnego serwera aplikacyjnego. Do zmiany systemu operacyjnego potrzebny jest klasyczny system copy. Wariant DMO with System Move pozwala dodatkowo przenieść system na nowy host.
Tak. Migracja systemu operacyjnego (na przykład z Windows, AIX czy Solaris na Linux) realizowana jest przez klasyczny heterogeneous system copy (export/import z SWPM, R3load, Migration Monitor). Linux jest standardem dla HANA, więc migracja bazy do HANA często idzie w parze z migracją systemu operacyjnego na Linux.
Zależy on od wielkości bazy i metody. Optymalizujemy równoległy export/import przez Migration Monitor, żeby skrócić czas. Testujemy na środowiskach nieprodukcyjnych przed wejściem zmian na systemy produkcyjne. Dla dużych baz stosujemy techniki minimalizujące downtime. Konkretny szacunek dajemy po analizie systemu i pomiarze na środowisku testowym.
Tak. Migracja do bazy danych SAP HANA wymaga, by system był na odpowiednio nowej wersji (dla ECC zwykle Enhancement Package 7 lub nowszy). Starsze wersje nie wspierają HANA. Jeśli jesteś na starszej wersji, najpierw może być potrzebny upgrade lub Enhancement Package, co można połączyć z migracją przez DMO. Sprawdzamy to w fazie analizy.
Zależy od sytuacji. Łączenie (DMO z upgrade, DMO with System Move do chmury, migracja do bazy SAP HANA z konwersją) bywa efektywne, bo robisz kilka zmian w jednym oknie. Ale łączenie zwiększa złożoność i ryzyko jednego projektu. Czasem rozsądniej rozdzielić, żeby ograniczyć ryzyko. Doradzamy na podstawie Twojego zapotrzebowania na zmiany, ryzyka i harmonogramu.
Nowy środowisko (HANA, Linux) wymaga bieżącego zarządzania: monitoring wydajności, optymalizacja parametrów HANA, aktualizacje, backup. W modelu Managed Services SAP przejmujemy tę odpowiedzialność. Migracja OS/DB to początek życia na nowym fundamencie, który trzeba utrzymywać.
