Migracja danych do nowej aplikacji: jak sprawdzić gotowość przed przełączeniem

Nowa aplikacja może być szybka, wygodna i poprawnie przetestowana, a mimo to pierwszego dnia pracy zatrzymać zespół. Wystarczy, że w historii zamówienia zabraknie numeru klienta albo dokumenty trafią do niewłaściwych spraw. Migracja danych nie kończy się na komunikacie „import zakończony”. Kończy się wtedy, gdy ludzie potrafią znaleźć potrzebne informacje, rozumieją ich stan i mogą bezpiecznie kontynuować rozpoczętą pracę.

Plan migracji powinien łączyć technikę z decyzjami biznesowymi. Kto rozstrzygnie, które konto klienta jest aktualne? Co zrobić z otwartą reklamacją, gdy zmienia się słownik statusów? Czy przed przełączeniem należy wstrzymać wpisy w starym programie? Te pytania wpływają na harmonogram równie mocno jak szybkość kopiowania rekordów.

Zacznij od danych używanych w prawdziwej pracy

Zapisz systemy, z których korzysta proces: główną aplikację, arkusze, osobne foldery dokumentów i integracje. Potem wybierz kilka typowych spraw oraz przypadki otwarte. Prześledź, gdzie znajdują się dane potrzebne do ich zakończenia. Numer sprawy może być w jednym systemie, korespondencja w drugim, a uzgodniona cena w pliku dostępnym tylko jednej osobie.

Taki przegląd pozwala ustalić nie tylko listę tabel, ale też związki między informacjami. Przeniesienie samych klientów bez kontaktów, załączników lub historii zgód może zostawić pracownika z nowym ekranem i starym problemem. Warto od początku wskazać właścicieli danych: osoby, które potrafią wyjaśnić ich znaczenie i podjąć decyzję, gdy dwa źródła się różnią.

Jeżeli systemów jest kilka, potrzebne jest uzgodnienie, który z nich rozstrzyga o danym polu. Osobno opisujemy wybór źródła danych w integracji. Przy migracji decyzja ma też wymiar czasowy: dane mogą wyglądać inaczej w dniu próby i w chwili właściwego przełączenia.

Szczególną uwagę poświęć integracjom, które uzupełniają dane w tle. W chwili przenoszenia zamówienia zewnętrzny system może nadal aktualizować jego płatność lub status dostawy. Sama kopia wykonana rano będzie wtedy poprawna dla porannego stanu, ale niekoniecznie dla momentu startu. Potrzebna jest decyzja, jak zebrać późniejsze zmiany i jak rozpoznać, że wszystkie potrzebne aktualizacje dotarły.

Ustal, co przenieść, a co zostawić dostępne inaczej

Nie każde pole musi trafić do nowej aplikacji. Stary system może zawierać dane nieużywane, duplikaty, pola testowe lub historię, której zespół potrzebuje wyłącznie do odczytu. Decyzja o pozostawieniu części danych poza nową aplikacją wymaga jednak uzgodnienia dostępu, właściciela, okresu przechowywania i sposobu odnalezienia informacji po przełączeniu. Nie oznacza automatycznej zgody na usunięcie starych zapisów.

Z drugiej strony usunięcie pozornie nieużywanego pola może przerwać proces. Przykładowo pole komentarza może zawierać uzgodnienia, których nikt nie umieścił w osobnej kolumnie. Zanim uznasz je za zbędne, pokaż próbkę osobom pracującym ze sprawami. Ustal również, czy historia zmian ma być widoczna w nowym interfejsie, czy wystarczy uzgodniony dostęp do archiwum. Odpowiedź może się różnić dla różnych rodzajów danych.

Ważne jest ustalenie zakresu danych osobowych i zasad ich przekazania wykonawcy. Do pierwszych prób mogą wystarczyć dane zastępcze o podobnej strukturze. Jeżeli potrzebna jest rzeczywista próbka, jej zakres, dostęp i sposób zabezpieczenia trzeba wcześniej uzgodnić. Nie wysyłaj haseł ani kopii całej bazy tylko dlatego, że ktoś poprosił o przykład rekordu.

Oddziel też decyzję o przeniesieniu od decyzji o udostępnieniu. Historia może być potrzebna do rozliczenia lub wyjaśnienia reklamacji, lecz nie każda osoba korzystająca z nowej aplikacji musi ją widzieć. Role w systemie docelowym należy uzgodnić przed importem i sprawdzić na rzeczywistych scenariuszach dostępu. Stare, nieaktualne uprawnienia nie powinny być automatycznie traktowane jako wzorzec dla nowego rozwiązania.

Mapa pól musi uwzględnić znaczenie, nie tylko nazwę

Mapowanie opisuje, skąd dana informacja pochodzi i dokąd trafi. W najprostszej wersji tabela zawiera pole źródłowe, pole docelowe, regułę przekształcenia, właściciela decyzji i sposób sprawdzenia. Przykładowo jeden system może zapisywać imię i nazwisko w jednym polu, a drugi w dwóch. Automatyczny podział nie zawsze da poprawny wynik, dlatego niejednoznaczne przypadki powinny mieć ustaloną ścieżkę sprawdzenia.

Trudniejsze bywają słowniki. Status „zamknięte” może oznaczać zakończenie obsługi w jednym dziale, a dopiero przekazanie do rozliczenia w drugim. Jeśli oba znaczenia zostaną przeniesione do jednego statusu bez dodatkowej informacji, raport po migracji pokaże pozorną zgodność, ale pracownicy stracą kontekst. Nazwy kolumn mogą się zgadzać, podczas gdy znaczenie pracy po drodze się zmieni.

Warto również zapisać jednostki i formaty: walutę, strefę czasową, precyzję kwot oraz sposób oznaczenia braku wartości. Pusta komórka, zero i informacja „nie dotyczy” nie muszą oznaczać tego samego. Podobne decyzje pojawiają się przy uzgadnianiu wskaźników dashboardu. Jeżeli definicja zmienia się podczas migracji, raport przed i po przełączeniu trzeba porównywać z uwzględnieniem tej zmiany. Przed próbą importu ustal, jak odseparować zapisy od rzeczywistej pracy. W tekście o środowisku testowym integracji omawiamy dane zastępcze i granice symulacji.

Próbny import to próba całej procedury

Pierwszy import sprawdza, czy mechanizm potrafi odczytać i zapisać dane. Kolejne powinny pokazać także, ile trwa przygotowanie pliku, kto rozwiązuje błędy, czy dokumenty otwierają się we właściwych sprawach i jak zespół weryfikuje wynik. Zapisuj odrzucone rekordy razem z powodem odrzucenia, bez umieszczania nadmiarowych danych w logach. Błąd musi dać się przypisać do sprawy i naprawić, a nie jedynie policzyć.

Próbę należy przeprowadzić na danych i przy obciążeniu możliwie zbliżonych do warunków planowanego przełączenia, z zachowaniem ustalonych zasad dostępu. Mała próbka świetnie wykrywa błędny format, ale może nie pokazać czasu potrzebnego na załączniki albo ograniczeń systemu źródłowego. AWS w swojej dokumentacji migracyjnej zaleca przećwiczenie okna przełączenia oraz przygotowanie planu na wypadek przekroczenia dostępnego czasu.

Nie poprawiaj wyników ręcznie bez zapisu, co zostało zmienione i dlaczego. Właściwa migracja musi dać się powtórzyć w kontrolowany sposób. Jeśli w próbnej partii trzeba ręcznie dopasować nietypową kategorię, zapisz regułę lub przygotuj listę wyjątków do zatwierdzenia. Inaczej kolejny import może odtworzyć dokładnie ten sam problem, tylko w większej skali.

Przy większej liczbie źródeł wyznacz kolejność importu. Kontakty mogą potrzebować istniejących kont klientów, a zamówienia przypisanych produktów i prawidłowych walut. Przerwanie jednego etapu nie powinno zostawić następnego w stanie pozornej gotowości. Dla każdego kroku określ warunek rozpoczęcia, wynik oraz procedurę ponowienia. To ułatwia zarówno ćwiczenie całego procesu, jak i późniejsze rozliczenie ewentualnych braków.

Porównaj wyniki na kilku poziomach

Liczba rekordów to dobry początek, ale słaby jedyny test. Sto klientów w starym systemie i sto w nowym nie dowodzi, że są to te same osoby i firmy. Porównaj identyfikatory, powiązania, wybrane pola oraz liczbę pozycji w sprawach. Sprawdź także sumy kontrolne właściwe dla danego procesu, na przykład liczbę otwartych zleceń w uzgodnionych statusach. Wybierz przykłady, które pracownicy rzeczywiście potrafią ocenić.

Przejdź kilka kompletnych scenariuszy: odnajdź klienta, otwórz aktywne zamówienie, sprawdź historię i wykonaj następny dozwolony krok. Dla dokumentów sprawdź nie tylko obecność pliku, ale i to, czy właściwa osoba ma do niego dostęp. Wynik testu zapisz razem z wersją danych i użytymi regułami. Bez informacji o tym, którą próbę oceniono, późniejsze zapewnienie „było sprawdzane” jest trudne do wykorzystania.

Z góry uzgodnij dopuszczalne rozbieżności. Niektóre archiwalne pola mogą zostać przeniesione do odrębnego widoku, ale brak aktywnego zlecenia może uniemożliwić uruchomienie. Granice odbioru i odpowiedzialne osoby warto powiązać z kryteriami odbioru aplikacji. Wtedy decyzja o starcie opiera się na konkretnej liście wyników, a nie na tym, kto akurat najgłośniej mówi, że wszystko wygląda dobrze.

Do kontroli wybierz też małe i nietypowe grupy, które łatwo zgubić w ogólnych sumach. Mogą to być sprawy bez przypisanego opiekuna, rekordy połączone z nieaktywnym kontem albo zlecenia z korektą. Liczebność całej tabeli może wyglądać poprawnie, nawet gdy wszystkie takie sprawy trafiły do niewłaściwego statusu. Weryfikację wzbogaca przejście ich przez nowy proces, razem z osobą znającą znaczenie tych wyjątków.

Zaplanuj przełączenie i realny powrót

W harmonogramie uwzględnij ostatni zapis w starym systemie, wykonanie kopii, końcową synchronizację, kontrolę i moment dopuszczenia użytkowników do nowej aplikacji. Ustal, kto komunikuje przerwę, kto podejmuje decyzję o przedłużeniu prac i kto ma prawo rozpocząć procedurę powrotu. Jeżeli nie można wstrzymać całej firmy, być może da się przełączać wybrane procesy etapami. Taki wariant wymaga jednak jasnych zasad współistnienia obu systemów.

Powrót nie zawsze oznacza zwykłe przekierowanie użytkowników do starego ekranu. Jeśli po przełączeniu nowe zamówienia lub korekty zostały zapisane tylko w nowym systemie, stary nie będzie ich znał. AWS zwraca uwagę, że po rozpoczęciu nowych zapisów może być potrzebne przeniesienie zmian z powrotem. Sposób zależy od architektury i musi zostać uzgodniony oraz sprawdzony wcześniej, a nie dopiero podczas awarii.

Pomaga wyznaczenie punktów decyzyjnych: które błędy zatrzymują start, ile czasu pozostaje na poprawki i kiedy wybieramy powrót. Przy każdym punkcie zapisz odpowiedzialną osobę oraz dane potrzebne do decyzji. Jeśli firma akceptuje pracę w ograniczonym zakresie, opisz dokładnie ten zakres i sposób późniejszego uzupełnienia braków. Plan awaryjny bez osoby uprawnionej do jego uruchomienia jest raczej notatką niż planem.

Przygotuj komunikaty dla pracowników przed i po przełączeniu. Powinni wiedzieć, do którego momentu wolno wpisywać zmiany w starym systemie, gdzie zgłosić brak dokumentu i kiedy otrzymają odpowiedź. Krótki okres wzmożonej obsługi po starcie pozwala zebrać rozbieżności w jednym miejscu. Ustal, kto porządkuje zgłoszenia, jak odróżnia pilne problemy od pytań o obsługę i kiedy przekazuje decyzję właścicielowi danych.

Co przygotować przed rozmową o migracji

Zbierz listę źródeł, rodzaje danych, przybliżoną wielkość zbiorów oraz informacje o tym, jak pobiera się dane ze starego systemu. Dodaj przykładową sprawę z powiązanymi dokumentami i opisz okres, w którym firma może ograniczyć zapisy. Wypisz też pytania, na które jeszcze nie znasz odpowiedzi. Nie musisz przed rozmową rozwiązać każdego konfliktu, ale dobrze wiedzieć, kto może go wyjaśnić.

Jeśli zmiana aplikacji jest częścią szerszej przebudowy, pomocny będzie tekst o modernizacji bez wielkiego resetu. Przy pracach z dokumentami i automatyzacją sprawdź również, jak przygotować dane do dalszego wykorzystania. Sam transfer nie naprawi niejasnych definicji ani brakujących powiązań, ale może ujawnić, gdzie trzeba podjąć decyzję.

Opisz planowaną zmianę przez kontakt z Archifutura. W krótkim briefie wskaż, z czego korzystacie dziś, które sprawy muszą być dostępne od pierwszego dnia i czego nie wolno utracić. Możemy wtedy zaplanować zakres integracji i przeniesienia danych, próbny import oraz sposób odbioru. Sekrety dostępowe zostaw do osobno uzgodnionego, bezpiecznego kanału.