Poradnik
Migracja danych i systemów — checklista
Migracja rzadko polega tylko na skopiowaniu danych. W firmowym środowisku trzeba uwzględnić użytkowników, uprawnienia, aplikacje, integracje, domeny, DNS, pocztę, backup i moment przełączenia. Im więcej zależności zostanie odkrytych wcześniej, tym mniejsze ryzyko przestoju.
1. Ustal zakres migracji
Przed rozpoczęciem prac trzeba jasno określić, co jest przenoszone: poczta, pliki, serwer, system księgowy, baza danych, domena, urządzenia użytkowników, aplikacje czy integracje z dostawcami. Brak zakresu powoduje, że problemy wychodzą dopiero w dniu zmiany.
2. Sprawdź właścicieli i dostępy
- kto ma dostęp administratora,
- gdzie są hasła i klucze odzyskiwania,
- kto zarządza domeną i DNS,
- kto może zmienić rekordy poczty,
- czy są aktywne konta byłych pracowników lub dostawców.
3. Zrób backup przed zmianą
Backup powinien być wykonany przed migracją i możliwy do odtworzenia. Sam komunikat „zadanie backupu zakończone powodzeniem” nie wystarcza. Trzeba wiedzieć, co dokładnie jest zabezpieczone, gdzie znajduje się kopia i jak wygląda powrót do poprzedniego stanu.
4. Zaplanuj okno serwisowe i komunikację
Użytkownicy powinni wiedzieć, kiedy usługa może być niedostępna, co mają zrobić po przełączeniu i gdzie zgłaszać problemy. Przy migracji poczty warto przygotować instrukcję dla telefonów, Outlooka, aplikacji mobilnych i dostępów przez przeglądarkę.
5. Przygotuj plan wycofania
Każda poważna migracja powinna mieć punkt decyzyjny: kontynuujemy, naprawiamy albo wycofujemy zmianę. Plan wycofania nie jest pesymizmem — to sposób na ograniczenie strat, gdy pojawi się zależność, której nie dało się wcześniej przewidzieć.
Dlaczego migracji nie warto robić „przy okazji”?
Migracja często wydaje się prostym przeniesieniem plików lub aplikacji, ale w praktyce dotyka uprawnień, skrótów użytkowników, mapowanych dysków, DNS, poczty, certyfikatów, integracji i backupu. Jeżeli te elementy nie zostaną sprawdzone wcześniej, problem może ujawnić się dopiero po przełączeniu, kiedy użytkownicy zaczynają pracę i oczekują normalnej dostępności systemów.
Dlatego lepiej potraktować migrację jako projekt techniczny, nawet jeżeli skala jest niewielka. Wystarczy prosty plan: co przenosimy, kiedy wykonujemy kopię, kto testuje efekt, jak długo utrzymujemy stare środowisko i kiedy uznajemy zmianę za zakończoną. Taki porządek zmniejsza ryzyko przestoju oraz ułatwia komunikację z osobami korzystającymi z systemów.