Migracja danych do nowej wersji WAPRO

Migracja danych do nowej wersji WAPRO to proces, który wymaga staranności — zwłaszcza przy przejściu między istotnie różniącymi się wersjami programu lub przy zmianie silnika bazy danych. Poniżej opisujemy, jak serwis komputerowy planuje i realizuje taką migrację.

Migracja zaczyna się od analizy różnic między obecną a docelową wersją programu — nowe wersje WAPRO mogą wymagać innej wersji silnika bazy danych (np. przejście z Firebird 2.5 na Firebird 3.0) lub zmiany struktury tabel, co producent zwykle obsługuje automatycznym skryptem konwersji uruchamianym przy pierwszym otwarciu bazy w nowej wersji programu.

Przed rozpoczęciem prac trzeba ustalić, gdzie znajduje się aktywna baza danych, z jakiego programu korzystają poszczególne stanowiska oraz które elementy konfiguracji są związane z konkretnym komputerem. Sama instalacja nowej wersji WAPRO nie zawsze oznacza zakończenie migracji. Konieczne może być również przeniesienie plików bazodanowych, ustawień połączenia, dokumentów powiązanych z bazą oraz dodatkowych komponentów używanych przez firmę.

Etapy bezpiecznej migracji

• Wykonanie pełnej kopii zapasowej bazy danych w obecnej wersji, przed jakąkolwiek ingerencją.
• Instalacja nowej wersji programu i, jeśli wymagana, nowej wersji silnika bazy danych na środowisku testowym lub kopii roboczej.
• Konwersja bazy danych do nowego formatu z wykorzystaniem wbudowanego kreatora migracji WAPRO.
• Weryfikacja poprawności danych po migracji — zgodność stanów magazynowych, kartotek kontrahentów, historii dokumentów.
• Migracja pozostałych stanowisk klienckich dopiero po potwierdzeniu poprawności działania na stanowisku głównym.

Przygotowanie do migracji danych WAPRO

Dobre przygotowanie ogranicza ryzyko przestoju i ułatwia szybkie wykrycie ewentualnych problemów. Przed pracami warto ustalić, kto w firmie potwierdzi poprawność danych po konwersji. Osoba korzystająca z magazynu może sprawdzić stany i dokumenty przyjęć, pracownik zajmujący się sprzedażą może zweryfikować faktury oraz korekty, a osoba odpowiedzialna za rozliczenia powinna sprawdzić zestawienia i dokumenty wystawione przed migracją.

Warto również przygotować listę wszystkich stanowisk, na których działa WAPRO. Powinna ona obejmować komputer główny lub serwer, stanowiska klienckie, laptopy używane czasowo poza biurem oraz ewentualne komputery przeznaczone do pracy zdalnej. Dzięki temu można uniknąć sytuacji, w której część pracowników korzysta już z nowej wersji, a część nadal łączy się ze starą bazą albo ma niezgodną wersję programu.

Na tym etapie sprawdzamy także wolne miejsce na dysku, uprawnienia użytkowników, działanie sieci lokalnej oraz możliwość wykonania kopii zapasowej. Brak miejsca, zablokowany plik bazy lub niewystarczające uprawnienia systemowe mogą przerwać konwersję jeszcze przed jej zakończeniem.

Kopia zapasowa przed konwersją

Pełna kopia zapasowa jest najważniejszym zabezpieczeniem całego procesu. Powinna zostać wykonana przed aktualizacją programu, wymianą silnika bazy danych i przenoszeniem plików na nowy komputer. Kopia musi obejmować rzeczywistą, aktualnie używaną bazę, a nie pustą bazę testową lub wcześniejszy plik zapisany w innej lokalizacji.

Po wykonaniu kopii warto sprawdzić, czy plik faktycznie istnieje, ma spodziewany rozmiar i można go odczytać. Sama obecność pliku na dysku nie gwarantuje, że kopia będzie możliwa do wykorzystania. W zależności od konfiguracji można przygotować również dodatkową kopię na innym nośniku. Oryginalna baza nie powinna być nadpisywana do czasu zakończenia testów i zaakceptowania nowego środowiska.

Przed rozpoczęciem backupu należy zamknąć WAPRO na wszystkich stanowiskach. Jeżeli któryś z użytkowników pozostawi otwarty dokument, raport lub połączenie z bazą, kopia może zostać wykonana w niewłaściwym momencie. Dotyczy to również automatycznych procesów, integracji i programów pomocniczych, które mogą korzystać z bazy w tle.

Konwersja bazy do nowego formatu

Konwersja zmienia strukturę bazy tak, aby mogła działać z nową wersją WAPRO. W zależności od zakresu aktualizacji program może dodać nowe pola, zmienić sposób zapisu określonych informacji albo dostosować bazę do innej wersji silnika. Właśnie dlatego nie należy otwierać jedynej kopii produkcyjnej w nowej wersji bez wcześniejszego zabezpieczenia danych.

Proces konwersji powinien być wykonany zgodnie z instrukcjami programu i producenta. Nie należy przerywać pracy komputera, zamykać kreatora ani uruchamiać równolegle kilku instancji WAPRO. Jeżeli konwersja zgłosi komunikat o błędzie, trzeba go zapisać i zatrzymać dalsze próby na bazie produkcyjnej do czasu ustalenia przyczyny.

Na środowisku testowym można sprawdzić, czy migracja przebiega prawidłowo i jak długo trwa. Kopia robocza pozwala także przećwiczyć konfigurację połączeń oraz uruchomienie programu na stanowiskach klienckich. Dopiero po takim sprawdzeniu można zaplanować właściwe okno migracyjne.

Weryfikacja danych po migracji

Po zakończeniu konwersji nie wystarczy sprawdzić, czy program się uruchamia. Należy zweryfikować dane z punktu widzenia codziennej pracy firmy. W pierwszej kolejności sprawdzamy logowanie użytkowników, dostęp do baz, otwieranie kartotek i wyszukiwanie dokumentów. Następnie porównujemy wybrane informacje z kopią lub wydrukami wykonanymi przed migracją.

• kartoteki towarów i usług wraz z jednostkami, symbolami oraz cenami;
• kartoteki kontrahentów, dane adresowe i informacje potrzebne do wystawiania dokumentów;
• stany magazynowe dla wybranych towarów i magazynów;
• historię faktur, paragonów, dokumentów magazynowych i korekt;
• numerację dokumentów oraz możliwość wystawienia nowego dokumentu;
• raporty, zestawienia i wydruki używane w codziennej pracy;
• uprawnienia użytkowników oraz dostęp do poszczególnych modułów.

Praktycznym testem jest przeprowadzenie kilku typowych operacji: wyszukanie istniejącego kontrahenta, otwarcie wcześniejszej faktury, sprawdzenie stanu magazynowego, wystawienie dokumentu testowego oraz wykonanie raportu. Jeżeli firma korzysta z drukarek, czytników kodów, podpisów elektronicznych lub innych urządzeń, ich działanie również trzeba zweryfikować po aktualizacji.

Migracja przy wymianie sprzętu

Częstym scenariuszem jest migracja danych WAPRO przy okazji wymiany starego serwera na nowy komputer. Wtedy proces obejmuje dodatkowo przeniesienie samego silnika bazy danych na nowe środowisko, skonfigurowanie sieci tak, by stanowiska klienckie widziały nowy serwer pod właściwym adresem, oraz aktualizację ustawień połączenia na każdym stanowisku roboczym. Warto to zaplanować w okresie mniejszego obciążenia firmy, ponieważ migracja większej bazy danych może potrwać od kilkunastu minut do kilku godzin, w zależności od jej rozmiaru i wydajności sprzętu.

Przy wymianie komputera trzeba rozdzielić kilka czynności. Najpierw zabezpieczamy dane na starym urządzeniu, następnie przygotowujemy nowy komputer, instalujemy wymagane składniki i przenosimy bazę. Dopiero po sprawdzeniu poprawności działania konfigurujemy pozostałe stanowiska. Stary komputer powinien pozostać dostępny do czasu potwierdzenia, że nowy serwer działa stabilnie.

Istotny jest również adres serwera. Jeżeli stanowiska klienckie łączą się z bazą przez nazwę komputera, po zmianie urządzenia może być konieczna aktualizacja rozpoznawania tej nazwy. Jeżeli w konfiguracji zapisano konkretny adres IP, trzeba sprawdzić, czy nowy komputer korzysta z właściwej konfiguracji sieciowej. Błędny adres lub zablokowany port może sprawić, że program uruchomi się lokalnie, ale nie połączy się z bazą.

Przeniesienie stanowisk klienckich

Stanowiska klienckie powinny być aktualizowane dopiero po przygotowaniu i przetestowaniu stanowiska głównego. Wersja programu na komputerze użytkownika musi odpowiadać wersji działającej po stronie serwera. Niezgodność wersji może powodować komunikaty o błędnym formacie bazy, problemy z logowaniem albo brak dostępu do wybranych modułów.

Na każdym komputerze sprawdzamy instalację programu, ustawienia połączenia, dostęp do udziałów sieciowych oraz uprawnienia użytkownika. W przypadku laptopów używanych poza siedzibą trzeba uwzględnić, czy mają one łączyć się z bazą wyłącznie w biurze, przez połączenie zdalne czy przez inne rozwiązanie skonfigurowane w firmie. Nie należy zakładać, że ustawienia ze starego komputera automatycznie zadziałają po migracji.

Po aktualizacji każdego stanowiska warto wykonać krótki test. Użytkownik powinien zalogować się do programu, otworzyć kartotekę, wyszukać dokument i sprawdzić podstawowy wydruk. Pozwala to od razu wykryć problem lokalny, zamiast odkrywać go dopiero podczas pracy całego zespołu.

Najczęstsze problemy podczas migracji

Jednym z częstszych problemów jest uruchomienie nowej wersji programu na bazie, która nie została prawidłowo skopiowana lub znajduje się w innej lokalizacji niż wskazana w konfiguracji. Inną przyczyną może być uruchomiony proces bazy danych, który blokuje plik albo nie pozwala na wykonanie konwersji.

Problemy mogą wynikać także z niezgodnych uprawnień systemowych. Program może działać na koncie administratora, ale nie uruchamiać się prawidłowo na koncie standardowego użytkownika. Dlatego testy należy wykonywać z użyciem rzeczywistych kont pracowników, a nie wyłącznie konta technicznego.

Warto zwrócić uwagę na programy antywirusowe i zapory sieciowe. Po instalacji nowego silnika bazy danych zabezpieczenia mogą potraktować jego usługę jako nowy komponent i zablokować komunikację. W takiej sytuacji trzeba sprawdzić reguły zapory oraz status usługi, zachowując zasady bezpieczeństwa i nie wyłączając ochrony bez wyraźnej potrzeby.

Dokumentacja i plan powrotu

Każda migracja powinna zostać opisana. W dokumentacji warto zapisać wersję programu przed i po aktualizacji, lokalizację bazy, sposób wykonania kopii, ustawienia serwera oraz listę zaktualizowanych stanowisk. Taki opis ułatwia późniejszą diagnostykę i pozwala szybciej odtworzyć środowisko po awarii komputera.

Po zakończeniu prac trzeba również ustalić plan powrotu do poprzedniego środowiska. Nie zawsze oznacza to natychmiastowe przełączenie firmy z powrotem na starą wersję. Najważniejsze jest zachowanie kopii i starego komputera w stanie umożliwiającym analizę problemu. Powrót musi uwzględniać także dokumenty utworzone po migracji, dlatego decyzję o jego wykonaniu należy podejmować świadomie.

Po zakończeniu migracji zalecamy zachowanie starej wersji bazy i programu przez pewien czas (np. miesiąc) jako dodatkowe zabezpieczenie, na wypadek gdyby w nowej wersji ujawniły się problemy niewidoczne od razu po wdrożeniu.

Zgłoszenie naprawy: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Sprzęt odbieramy spod wskazanego adresu w Grodzisku Mazowieckim i okolicy.

Zobacz też

• Konfiguracja WAPRO Fakir do księgowości
• Optymalizacja komputera pod WAPRO ERP
• Konfiguracja dostępu zdalnego do WAPRO
• Wapro — wszystkie artykuły