- +48 12 333-73-90
- biuro@intocloud.pl
- Panel klienta
Jak przenieść Subiekta GT lub nexo do chmury? Kompletny poradnik migracji
Przeniesienie Subiekta GT lub Subiekta nexo do chmury polega na przeniesieniu programu, bazy danych SQL, użytkowników, ustawień oraz środowiska pracy z lokalnego komputera albo serwera na zdalny serwer, do którego firma łączy się przez internet. Dobrze wykonana migracja pozwala pracować z programu z biura, domu, laptopa, oddziału firmy albo z komputera księgowej, bez utrzymywania własnego serwera lokalnego.
Najważniejsze jest to, że migracja nie powinna polegać wyłącznie na „skopiowaniu programu”. W praktyce trzeba zadbać o bazę SQL, kopię zapasową, licencje, użytkowników, drukarki fiskalne, urządzenia zewnętrzne, bezpieczeństwo połączeń oraz czas przestoju. Dopiero wtedy Subiekt w chmurze działa stabilnie i nie kończy się chaosem pierwszego dnia po wdrożeniu.
Migracja InsERT do chmury oznacza przygotowanie środowiska serwerowego, instalację odpowiednich składników, przeniesienie bazy danych i skonfigurowanie dostępu dla użytkowników. W przypadku Subiekta GT lub nexo najważniejszym elementem jest baza SQL, bo to w niej znajdują się dane firmy: kontrahenci, dokumenty, magazyny, faktury, towary, ustawienia programu i historia pracy.
W typowym scenariuszu firma korzystała wcześniej z programu na jednym komputerze, na lokalnym serwerze albo w sieci biurowej. Po migracji program działa na serwerze w chmurze, a użytkownicy łączą się z nim zdalnie. Dzięki temu nie trzeba przenosić bazy między komputerami, wysyłać kopii księgowej ani martwić się, że program działa tylko na jednym stanowisku.
Pierwszy krok to sprawdzenie aktualnego stanu bazy danych. Przed migracją trzeba wiedzieć, z jakiej wersji programu korzysta firma, gdzie znajduje się baza SQL, jak duży jest plik bazy, czy baza nie ma błędów oraz czy wykonywane były regularne kopie zapasowe.
Najbezpieczniej rozpocząć od wykonania aktualnej archiwizacji z poziomu programu InsERT oraz dodatkowej kopii całego środowiska, jeżeli program działa na lokalnym serwerze. Sama kopia wykonana „na szybko” nie wystarcza, jeżeli nikt nie sprawdzi, czy można ją później odtworzyć. Dlatego przy migracji warto wykonać test odtworzenia albo przynajmniej zweryfikować, czy kopia nie jest uszkodzona i czy obejmuje właściwą bazę.
W firmach, które mają kilka podmiotów lub kilka baz, trzeba ustalić, które bazy mają zostać przeniesione. Zdarza się, że na starym komputerze znajdują się stare, nieużywane bazy testowe, archiwalne albo próbne. Migracja jest dobrym momentem, żeby uporządkować środowisko i nie przenosić niepotrzebnego bałaganu.
Przed przeniesieniem Subiekta do chmury trzeba sprawdzić licencje, aktualną wersję programu oraz uprawnienia użytkowników. Dotyczy to zarówno Subiekta GT, jak i nexo. Ważne jest, aby środowisko w chmurze było zgodne z używaną wersją programu oraz wymaganiami bazy SQL.
Jeżeli firma korzysta z dodatkowych modułów, rozszerzeń, Sfery, synchronizacji, integracji sklepu internetowego, drukarek fiskalnych albo programów księgowych, trzeba uwzględnić je w planie migracji. Sam Subiekt może uruchomić się poprawnie, ale problem pojawi się dopiero wtedy, gdy pracownik spróbuje wydrukować paragon, wysłać dokument do księgowości albo połączyć program z dodatkiem używanym od lat.
Czas migracji zależy od wielkości bazy, liczby stanowisk, używanych urządzeń oraz tego, jak uporządkowane jest obecne środowisko. Mała firma z jedną bazą i kilkoma użytkownikami może przejść migrację stosunkowo szybko. Większe środowisko, z wieloma bazami, drukarkami, integracjami i oddziałami, wymaga dokładniejszego planu.
Najlepszą praktyką jest wykonanie migracji poza godzinami największej pracy firmy. Przestój zwykle dotyczy momentu wykonania finalnej kopii bazy i przeniesienia jej na serwer w chmurze. W tym czasie użytkownicy nie powinni wystawiać nowych dokumentów na starym środowisku, bo mogłoby to doprowadzić do rozjazdu danych.
Dobrze przeprowadzona migracja ma jasny punkt odcięcia: do konkretnej godziny firma pracuje na starym środowisku, później następuje finalna kopia, a następnie praca odbywa się już w chmurze.
Jednym z częstszych źródeł problemów przy migracji są urządzenia zewnętrzne. Subiekt może działać w chmurze, ale drukarka fiskalna, kasa, czytnik kodów, drukarka etykiet albo inne urządzenie nadal fizycznie znajduje się w firmie. Trzeba więc zaplanować, jak program działający na serwerze zdalnym będzie komunikował się ze sprzętem lokalnym.
W części przypadków wystarczy odpowiednia konfiguracja pulpitu zdalnego i przekierowania urządzeń. W innych potrzebny będzie Serwer Urządzeń Zewnętrznych InsERT, właściwa konfiguracja portów, sterowników, certyfikatów albo lokalnego stanowiska pośredniczącego. Właśnie dlatego przed migracją warto zrobić listę wszystkich urządzeń używanych z Subiektem, a nie ograniczać się tylko do komputerów.
Migracja do chmury powinna poprawiać bezpieczeństwo, a nie tworzyć nowe ryzyka. Dlatego trzeba zadbać o mocne hasła, ograniczenie dostępu tylko dla uprawnionych użytkowników, aktualizacje systemu, kopie zapasowe, ochronę przed utratą danych i kontrolę dostępu do serwera.
W praktyce ważne są też proste rzeczy: kto ma konto administracyjne, kto może odtwarzać kopie, kto może dodawać nowych użytkowników, czy pracownik po odejściu z firmy traci dostęp do środowiska oraz czy połączenie z serwerem jest odpowiednio zabezpieczone.
Przed migracją warto przygotować krótką checklistę. Powinna obejmować:
Po migracji trzeba sprawdzić logowanie użytkowników, widoczność baz, wystawianie dokumentów, wydruki, działanie drukarki fiskalnej, dostęp do plików, szybkość programu, kopie zapasowe i możliwość pracy z różnych lokalizacji.
Koszt migracji zależy od zakresu prac. Inaczej wygląda przeniesienie jednej bazy dla jednego użytkownika, a inaczej wdrożenie dla kilku stanowisk, biura rachunkowego albo firmy z wieloma urządzeniami fiskalnymi. W kosztach trzeba uwzględnić przygotowanie serwera, instalację systemu, konfigurację SQL Servera, przeniesienie danych, konfigurację użytkowników, urządzeń, backupu i testów.
Najczęstsze problemy wynikają z braku aktualnej kopii, nieznanej lokalizacji bazy SQL, starych wersji programu, nieopisanych integracji, zapomnianych urządzeń zewnętrznych i braku osoby, która po stronie firmy potwierdzi, że wszystko działa poprawnie.
Dobrze zaplanowana migracja Subiekta GT lub nexo do chmury nie jest ryzykowną rewolucją. To raczej uporządkowany proces, w którym najpierw zabezpiecza się dane, później przenosi środowisko, a na końcu sprawdza codzienną pracę użytkowników. Dzięki temu firma może korzystać z programu zdalnie, bez wiązania całego działania z jednym komputerem albo lokalnym serwerem.
