Disaster Recovery 3 lipca 2026 4 min czytania

Pięcioletni serwer ERP spowalnia firmę: jak zaplanować migrację SQL do prywatnej chmury

Migracja ERP i SQL na serwery G2E obejmuje zależności, próbę na kopii roboczej i pełne zamknięcie okresu bez powrotu do starej maszyny.

Pięcioletni serwer ERP spowalnia firmę: jak zaplanować migrację SQL do prywatnej chmury

Pięcioletni serwer ERP może działać bez awarii, a mimo to wydłużać raporty, dokumenty magazynowe i rozliczenia. Sam wiek sprzętu nie odpowiada na pytanie, czy ograniczeniem jest SQL, aplikacja, dysk, połączenie zdalne czy zadanie cykliczne. Dziennik migracji łączy objawy użytkowników z zależnościami technicznymi, zanim powstanie specyfikacja nowego środowiska. Prywatna infrastruktura G2E daje miejsce dla serwerów ERP, bazy, dostępu i backupu. Projekt kończy się dopiero wtedy, gdy firma zamknie pełny okres księgowy w nowym środowisku bez powrotu do starego serwera.

Objawy przed specyfikacją

Pierwsze zapisy dotyczą czynności, przy których ludzie czekają: wystawienia dokumentu, przyjęcia magazynowego, naliczenia, raportu finansowego albo importu danych. Do każdego objawu dochodzą częstotliwość, wpływ na dział i informacja, skąd pochodzi obserwacja.

Księgowość opisuje raporty oraz okresy największego obciążenia. Magazyn wskazuje przerwy przy przyjęciach i wydaniach, a sprzedaż opóźnienia dokumentów. Nową infrastrukturę dobiera się do rzeczywistej pracy firmy, a nie do ogólnego przekonania, że stary serwer potrzebuje większego następcy.

Administrator zestawia te informacje z obciążeniem SQL, zadaniami cyklicznymi, pracą dysku, sesjami zdalnymi i logami aplikacji. Powolny raport może wynikać z zapytania albo blokady, której większa maszyna nie usunie. Już na początku trzeba więc oddzielić ograniczenia infrastruktury od zmian wymaganych w ERP lub bazie.

Zależności poza główną bazą

Obok SQL działają usługi integracyjne, wydruki, importy bankowe, połączenia ze sklepem, harmonogramy, certyfikaty, katalogi dokumentów i konta techniczne. Brak jednego elementu może zatrzymać pracę, choć ekran logowania do ERP nadal odpowiada.

Mapa środowiska obejmuje wersję aplikacji i SQL, wielkość oraz przyrost baz, raporty, konta usługowe, uprawnienia i ścieżki połączeń. Przy każdym składniku znajduje się źródło konfiguracji oraz informacja, czy przechodzi do nowej lokalizacji, pozostaje na miejscu czy działa przejściowo między obiema.

Osobno opisuje się dostęp użytkowników. Biuro, magazyn, oddział i osoby pracujące zdalnie mogą korzystać z różnych dróg. RDS lub VPN wchodzi do zakresu projektu wtedy, gdy prowadzi do ERP, bazy albo dokumentów. Przeniesiona baza bez działającego dostępu nie przywróci codziennej pracy.

Dotyczy to środowisk Comarch, enova365 i InsERT tak samo jak innych systemów opartych na SQL. Nazwa produktu nie zastępuje wiedzy o wersji, integracjach, licencjach oraz sposobie pracy. Warunki licencyjne klient i integrator ustalają z producentem aplikacji.

Nowe środowisko według pracy firmy

Projekt na prywatnej infrastrukturze G2E może wykorzystać serwery wirtualne dla ERP i SQL, prywatne połączenia, dostęp przez RDS lub VPN oraz backup. Rozmiar i układ wynikają z mapy procesów, danych oraz zależności. Nie są kopią parametrów starego urządzenia jeden do jednego.

Dobór zasobów uwzględnia przebieg raportów, aktywność użytkowników, przyrost bazy i okna zadań. Większa konfiguracja może na pewien czas ukryć złe zapytanie, a zbyt mała przeniesie dotychczasowe ograniczenie. Uzasadnienie zapisane przy zasobie ułatwia później odróżnienie potrzebnego zapasu od kosztu bez związku z obciążeniem.

Klient lub integrator odpowiada za ERP, SQL, połączenia i migrację, a G2E stanowi ich warstwę infrastrukturalną. To rozróżnienie nie wymaga powtarzania przy każdym kroku. Ważne, by usterka aplikacji nie była leczona przypadkową zmianą serwera, a problem z łącznością nie trafiał do producenta ERP.

Próba na kopii roboczej

Kopia robocza obejmuje aplikację, bazę, konfigurację i połączenia potrzebne do przejścia zwykłych procesów. Sprzedaż wystawia dokument, magazyn wykonuje przyjęcie i wydanie, księgowość porównuje salda oraz raporty, a integracje realizują importy i zadania automatyczne. Kilku użytkowników pracuje równolegle w zakresie zbliżonym do codziennego obciążenia.

Każdy dział ocenia własny skutek. Szybkie uruchomienie programu nie wystarcza, gdy nie działa wydruk, import bankowy albo połączenie ze sklepem. Rozbieżność otrzymuje nazwę konkretnej usługi, zapytania lub konfiguracji; ogólna etykieta „problem z chmurą” nie wystarcza.

Dane produkcyjne pozostają pod kontrolą uzgodnionych ról. Konta użytkowników odpowiadają ich pracy, a uprawnienia techniczne integratora są oddzielne. Próba pokazuje także, które zadania trzeba zatrzymać przed właściwym przełączeniem, aby nie powstały dwa miejsca równoległego zapisu.

Jedno miejsce zapisu po przełączeniu

Termin migracji wynika z rytmu księgowości, sprzedaży i magazynu oraz dostępności integratora. Przed rozpoczęciem użytkownicy kończą bieżące operacje, zadania cykliczne zostają rozliczone, a aktualne dane zabezpieczone. Od ustalonego momentu nowa instalacja jest jedynym miejscem produkcyjnej pracy.

Granica wycofania określa, kiedy dalsza naprawa kosztuje więcej niż uruchomienie poprzedniego środowiska. Trzeba też wiedzieć, jakie dokumenty powstały po przełączeniu i jak zostaną potraktowane przy cofnięciu. Reguła wynika ze skutków dla firmy, a nie z samego faktu, że aplikacja uruchomiła się na nowym serwerze.

Oczekiwany czas przywrócenia działania określa RTO, natomiast RPO wyznacza dopuszczalną utratę danych. Finanse, operacje i IT ustalają te cele według kosztu przerwy oraz znaczenia dokumentów. Zakres backupu i moment jego wykonania wskazują, do jakiego stanu można wrócić; sama obecność kopii jest tylko podstawą techniczną.

Po przełączeniu użytkownicy powtarzają procesy wykonane wcześniej na kopii roboczej. Krytyczny brak połączenia zatrzymuje dalsze użycie nawet wtedy, gdy ekran aplikacji odpowiada szybko. Stary serwer pozostaje dostępny tylko w uzgodnionym zakresie wycofania i późniejszego archiwum, bez obsługi wybranych działów po cichu.

Zamknięcie okresu bez starego serwera

Zwykły dzień nie ujawnia wszystkich obciążeń. Zamknięcie okresu łączy raporty, salda, zadania automatyczne oraz pracę kilku działów. To właściwy moment, aby ocenić środowisko w najważniejszym rytmie firmy bez wymyślania uniwersalnego benchmarku.

Po tym cyklu można zestawić koszty migracji z dalszym utrzymaniem starego sprzętu: serwisem, czasem użytkowników, ręcznymi obejściami i ryzykiem przestoju. Jednocześnie widać, które usprawnienia należały do infrastruktury, a które wymagały zmiany zapytań lub konfiguracji ERP.

Zamknięty okres księgowy, bieżąca praca magazynu i sprzedaży, poprawnie wykonane zadania integracyjne oraz brak doraźnego powrotu na stary serwer wyznaczają koniec migracji. Od tego momentu nowe środowisko przestaje być projektem migracyjnym i staje się zwykłym miejscem pracy firmy.

Chcesz omówić podobne środowisko dla swojego systemu?

Przejdź do formularza kontaktowego. Opisz workload, a dobierzemy właściwy profil infrastruktury.

Nie przegap żadnej analizy

Otrzymuj co tydzień analizy techniczne, wzorce architektury i aktualności infrastruktury chmurowej. Selekcja dla doświadczonych inżynierów.

Dołącz do 12 000+ specjalistów IT. Wypisz się w dowolnym momencie.