Określcie źródło prawdy i zakres historii, zmapujcie pola i powiązania, zdefiniujcie reguły czyszczenia i utwórzcie powtarzalny import. Przećwiczcie migrację na bezpiecznej kopii, uzgodnijcie liczby i znaczenie danych, przetestujcie procesy użytkowników i dopiero wtedy przeprowadźcie kontrolowane przełączenie z przygotowaną ścieżką powrotu.
Nowa aplikacja internetowa może działać poprawnie, a mimo to zawieść przy wdrożeniu, jeśli trafią do niej niekompletne, zduplikowane lub błędnie powiązane dane. Migracja to nie jest proste kopiowanie tabel. Stary system często zawiera ukryte reguły, historyczne wyjątki i wartości, których znaczenie zna tylko część zespołu.
Bezpieczna procedura zaczyna się od inwentaryzacji źródeł i decyzji, które dane mają sens w nowym rozwiązaniu. Następnie odbywa się mapowanie, czyszczenie, powtarzalny import i merytoryczna kontrola z udziałem przedstawicieli użytkowników. Przełączenie produkcyjne wymaga właściciela, harmonogramu, sposobu przechwytywania zmian oraz jasnych warunków kontynuacji lub wycofania.
Inwentaryzacja źródeł i znaczenia danych
Należy spisać bazy danych, arkusze, pliki, załączniki, słowniki i systemy zewnętrzne, które tworzą obecny proces. Dla każdego źródła warto oznaczyć właściciela, jakość, wrażliwość, format i sposób aktualizacji. Ten sam klient może mieć różne dane w CRM, księgowości i współdzielonym pliku. Bez decyzji o źródle nadrzędnym konflikt przeniesie się do nowej aplikacji.
O zakresie nie decyduje wyłącznie dostępność historii. Ustal, których starych rekordów użytkownicy potrzebują do podejmowania decyzji, które muszą pozostać dostępne z innego powodu, a które można bezpiecznie zarchiwizować. Przenoszenie wszystkiego zwiększa czas, ryzyko i liczbę niejasności. Przy wycofywaniu danych udokumentuj powód i sposób przyszłego odnalezienia informacji przez uprawnione osoby.
Zmapuj pola, tożsamości i relacje
Tabela mapowania powinna zawierać pole źródłowe, pole docelowe, typ danych, obowiązkowość, regułę transformacji i oczekiwane wyjątki. Nie należy zapominać o strefach czasowych, walutach, kodowaniach, separatorach dziesiętnych i znaczeniu pustej wartości. Ta sama nazwa pola nie musi oznaczać tej samej informacji, a różna nazwa może kryć identyczne pojęcie.
Stabilne tożsamości są ważniejsze niż kolejność wierszy. Należy stworzyć sposób powiązania użytkowników, organizacji, zamówień i załączników także po zmianie wewnętrznych identyfikatorów. Relacje należy importować w ustalonej kolejności lub tymczasowo przechowywać w warstwie mapowania. Duplikaty należy rozwiązywać według przejrzystych zasad i nie łączyć rekordów wyłącznie na podstawie podobnej nazwy.
- źródło i cel każdego pola
- transformacja i walidacja wartości
- reguła dla brakującej lub nieprawidłowej danej
- mapowanie starego i nowego identyfikatora
Oczyszczaj dane bez utraty informacji o ich pochodzeniu
Czyszczenie danych może ujednolicić format, usunąć oczywiście nieprawidłową wartość lub oznaczyć kandydatów do scalenia. Każda reguła wymaga jednak wyjaśnienia i możliwości odtworzenia pochodzenia danych. Automatyczna korekta nie powinna zgadywać informacji, której nie da się wiarygodnie wywnioskować. Niejasne przypadki wyodrębnij na listę do decyzji przez merytorycznego właściciela.
Kopie robocze należy chronić tak samo jak dane produkcyjne. Trzeba ograniczyć dostęp, korzystać z wyznaczonego magazynu danych i po teście bezpiecznie je usunąć. Jeśli prace deweloperskie nie wymagają rzeczywistych danych osobowych, warto przygotować zanonimizowany lub syntetyczny zestaw zachowujący istotne przypadki brzegowe. Transformacje należy wersjonować, aby wynik dało się powtórzyć i wyjaśnić.
Przećwicz import i merytoryczną kontrolę
Proces importu powinien być powtarzalny i odporny na częściowe niepowodzenie. Należy rejestrować wersję danych wejściowych, transformacje, początek, koniec, błędy oraz liczby wynikowe według typu rekordu. Przebieg próbny ujawni wydajność, kolejność zależności oraz różnice między udokumentowanym a rzeczywistym formatem. Poprawki należy wprowadzać w regule, a nie ręcznie w pojedynczym wyniku.
Same liczby techniczne nie wystarczą. Użytkownicy powinni przejść typowe i ryzykowne scenariusze: znaleźć klienta, otworzyć starszą sprawę, sprawdzić załącznik, kontynuować rozpoczęte zadanie i zweryfikować uprawnienia. Próbki wybierzcie z różnych okresów i wyjątków. Każde odchylenie sklasyfikujcie jako błąd źródła, transformacji, modelu docelowego lub oczekiwań.
Przygotuj przełączenie, uzgodnienie i powrót
Przed terminem przejścia na produkcję należy zdecydować, kiedy stary system przestanie być modyfikowany lub w jaki sposób zostaną przeniesione zmiany od ostatniego eksportu. Proszę określić kolejność kroków, osoby odpowiedzialne, kanał komunikacji i kryteria sukcesu. Użytkownicy muszą wiedzieć, co będzie tymczasowo niedostępne i gdzie zgłaszać problemy. Dostępy do nowego systemu warto zweryfikować jeszcze przed samym oknem wdrożeniowym.
Po imporcie proszę porównać liczby rekordów, sumy tam, gdzie mają one merytoryczny sens, relacje oraz próbki kontrolne. Wynik powinni pisemnie zaakceptować właściciele danych, a nie tylko zespół techniczny. Wycofanie musi uwzględniać również zmiany wprowadzone po uruchomieniu nowej aplikacji; proste ponowne włączenie starego systemu mogłoby doprowadzić do ich utraty. Eksporty źródłowe i protokoły należy przechowywać w kontrolowany sposób zgodnie z planem.
Najczęstsze pytania
Czy trzeba migrować całą historię ze starego systemu?
Nie zawsze. Zakres należy określić na podstawie rzeczywistego użycia, obowiązków, jakości i możliwości bezpiecznej archiwizacji. Ważne jest, aby uprawniona osoba potrafiła odnaleźć starsze dane, gdy ich potrzebuje.
Czy wystarczy porównać liczbę wierszy przed importem i po nim?
Nie. Liczba nie ujawni nieprawidłowych wartości, zerwanych powiązań, duplikatów ani błędnych uprawnień. Warto łączyć kontrole techniczne z merytorycznymi próbkami i przejściem rzeczywistych procesów użytkowników.
Kto powinien zatwierdzić migrację danych?
Zespół techniczny potwierdza przebieg importu, ale znaczenie i użyteczność danych powinni zatwierdzić ich właściciele i przedstawiciele użytkowników. W przypadku danych wrażliwych należy zaangażować także odpowiedzialne role ds. bezpieczeństwa i prawne.