Migracja danych: co analityk musi ustalić, zanim zespół ruszy

Nowy system był gotowy na wrzesień. Ruszył w lutym. Nie dlatego, że programiści się spóźnili - kod stał gotowy od miesięcy. Zespół utknął na danych ze starego systemu, w którym pole "status klienta" przez czternaście lat oznaczało siedem różnych rzeczy, zależnie od tego, kto je wypełniał.

Migracja danych to moment, w którym wychodzi cała historia firmy: przejęcia, zmiany procesu, obejścia wymyślone przez ludzi, którzy dawno odeszli. I to zwykle analityk jest osobą, która ma to rozplątać, zanim ktokolwiek napisze pierwszy skrypt.

Poniżej to, co trzeba ustalić na starcie, i pytania, które oszczędzają miesiące.

Migracja to decyzja biznesowa, nie techniczna

Najczęstszy błąd brzmi: "przeniesiemy wszystko, potem się zobaczy". To nie jest plan, tylko odłożenie decyzji na moment, w którym będzie najdroższa.

Przeniesienie wszystkiego oznacza przeniesienie także śmieci: duplikatów, rekordów testowych z 2015 roku, klientów, którzy nie żyją, zamówień w statusach, których nowy system nie rozumie. Każdy taki rekord będzie potem mylił użytkowników i zaniżał zaufanie do nowego narzędzia.

Decyzja "co migrujemy" należy do biznesu. Twoja rola to pokazać konsekwencje każdego wariantu w liczbach i w ryzyku, żeby biznes wybierał świadomie.

Sześć pytań, od których zaczynasz

1. Po co nam te dane w nowym systemie? Nie "czy je mamy", tylko "kto i w jakim procesie ich użyje". Dane, których nikt nie użyje, nie muszą jechać - wystarczy archiwum do wglądu.

2. Jak głęboko w historię wchodzimy? Rok, trzy lata, wszystko? To pytanie z konkretną ceną. Zwykle da się ustalić granicę: dane operacyjne migrujemy za dwa lata, starsze zostają w archiwum tylko do odczytu.

3. Co jest prawdą, gdy dwa systemy mówią co innego? Klient ma inny adres w CRM i inny w systemie fakturowym. Który wygrywa? Bez tej zasady zespół będzie wracał z tym pytaniem przy każdej tabeli.

4. Co robimy z rekordem, którego nie da się przenieść? Odrzucamy cicho, wstrzymujemy migrację, czy ładujemy z flagą "do poprawy"? Ustal to zanim skrypt napotka pierwszy taki rekord, bo wtedy decyzja zapadnie po godzinach i bez świadków.

5. Kto potwierdzi, że dane po migracji są poprawne? Potrzebujesz nazwiska, nie działu. Osoba, która zna te dane na tyle, żeby zobaczyć, że coś jest nie tak.

6. Co się dzieje z danymi, które powstaną w trakcie migracji? Stary system rzadko zamyka się na pstryknięcie. Ustal, czy jest okno zamrożenia, czy potrzebna jest dogrywka zmian.

Profilowanie: zanim zaczniesz mapować, zobacz, co naprawdę masz

Mapowanie pól bez obejrzenia danych to zgadywanie. Zanim narysujesz pierwszą strzałkę między starym a nowym polem, poproś o profilowanie - albo zrób je sam, jeśli masz dostęp.

Interesuje Cię kilka rzeczy dla każdego pola:

• Ile jest pustych wartości. Pole obowiązkowe w nowym systemie, które w starym jest puste w 40 procentach rekordów, to nie jest szczegół techniczny - to decyzja, co wpisać.
• Ile jest różnych wartości. Pole "status" z 43 unikalnymi wartościami przy 5 statusach w dokumentacji oznacza, że przez lata ludzie wpisywali, co chcieli.
• Jak wyglądają wartości skrajne. Data urodzenia z roku 1900, kwota ujemna, numer telefonu z 3 cyframi. To zwykle dane techniczne albo błędy, ale każdy taki przypadek potrzebuje reguły.
• Czy klucze są naprawdę unikalne. "Numer klienta" bywa powtórzony, bo ktoś kiedyś ręcznie dopisał rekord.

Profilowanie zajmuje zwykle kilka dni i oszczędza kilka tygodni. To jedna z niewielu rzeczy w projekcie, gdzie ten stosunek jest tak korzystny.

Mapowanie: dokument, który realnie ktoś przeczyta

Mapowanie pól to Twój główny artefakt w migracji. Zrób go tak, żeby programista mógł z niego pracować bez dopytywania.

Dla każdego pola docelowego opisz: skąd pochodzi, jak się przekształca, co się dzieje przy braku danych i kto potwierdził tę regułę.

Osobno dołącz słowniki przekształceń dla pól, gdzie stare wartości mapują się na nowe. To zwykle najbardziej sporna część i najczęściej zmieniana - trzymaj ją w jednym miejscu, nie rozsianą po treści dokumentu.

Reguły jakości: co przepuszczamy, co zatrzymujemy

Ustal trzy poziomy i trzymaj się ich konsekwentnie:

Blokujące - rekord nie może wejść do nowego systemu. Brak identyfikatora, brak wymaganego powiązania. Taki rekord ląduje w kolejce wyjątków z opisem powodu.

Ostrzegawcze - rekord wchodzi, ale z flagą. Brakujący telefon, adres bez kodu pocztowego. Ktoś to potem uzupełni w normalnej pracy.

Kosmetyczne - poprawiamy automatycznie i idziemy dalej. Wielkie litery w nazwisku, spacje na końcu tekstu.

Jedna rzecz jest tu ważniejsza od reszty: kolejka wyjątków musi mieć właściciela i termin. Kolejka, do której nikt nie zagląda, zamienia się w cichą utratę danych.

Próba przed próbą: migracja testowa

Nie ma dobrej migracji bez co najmniej dwóch przebiegów testowych na realnych danych - nie na próbce, którą ktoś ładnie przygotował.

Pierwszy przebieg pokazuje skalę problemu: ile rekordów odpada, gdzie są niespodzianki, ile to trwa. Drugi weryfikuje, czy poprawki zadziałały.

Z każdego przebiegu potrzebujesz raportu, który biznes zrozumie: ile rekordów weszło, ile odpadło i dlaczego, co wymaga decyzji. Nie log techniczny, tylko tabela z liczbami i wnioskiem.

Zwróć uwagę na czas. Jeśli przebieg trwa dziewięć godzin, a okno wdrożeniowe to weekend, właśnie znalazłeś ryzyko, o którym trzeba powiedzieć głośno i wcześnie.

Odbiór: jak sprawdzić, że się udało

Zgodność liczby rekordów to za mało. Zestaw kontrolny, który działa:

• Liczby kontrolne w najważniejszych przekrojach. Suma sald, liczba aktywnych umów, wartość otwartych zamówień - stary system kontra nowy, różnica wyjaśniona co do złotówki.
• Ścieżka losowej próbki. Weź kilkanaście rekordów, prześledź je ręcznie od starego systemu do nowego. To wyłapuje błędy, których liczby zbiorcze nie pokażą.
• Przypadki brzegowe z listy. Klient z dwoma adresami, umowa zawieszona, zamówienie częściowo zrealizowane. Przygotuj tę listę wcześniej, razem z biznesem.
• Test procesu, nie tylko danych. Czy na zmigrowanych danych da się przejść pełną ścieżkę: znaleźć klienta, wystawić dokument, zamknąć sprawę.

Trzy rzeczy, które psują migracje najczęściej

Traktowanie migracji jako zadania na koniec projektu. Dane trzeba profilować, gdy powstają wymagania, bo ich stan wpływa na to, co w ogóle da się zbudować.

Brak decydenta po stronie biznesu. Migracja generuje dziesiątki drobnych decyzji tygodniowo. Bez osoby, która je podejmuje, zespół albo stoi, albo zgaduje.

Migracja bez planu wycofania. Co zrobicie, jeśli w poniedziałek rano okaże się, że dane są złe? Odpowiedź "wrócimy do starego systemu" musi mieć konkretną procedurę i osobę, która ją zna.

Od czego zacząć jutro

Jeśli wchodzisz w projekt z migracją, zrób trzy rzeczy w tej kolejności. Poproś o dostęp do danych produkcyjnych albo ich kopii i zobacz je na własne oczy. Ustal z biznesem zakres i granicę historii, na piśmie. Znajdź osobę, która potwierdzi poprawność - i upewnij się, że ma na to czas w kalendarzu.

Reszta to już rzemiosło: mapowanie, reguły, przebiegi, odbiór. Ale te trzy rzeczy decydują, czy migracja będzie zadaniem, czy kryzysem.

Najczęstsze pytania

Kto decyduje, które dane podlegają migracji?

Decyzja należy do biznesu, bo dotyczy kosztu i ryzyka, a nie technologii. Analityk dostarcza podstawę do wyboru: ile rekordów obejmuje każdy wariant, ile trwa jego przebieg i czego w nowym systemie zabraknie. Jeśli po stronie biznesu nikt nie jest wskazany z imienia i nazwiska, drobne rozstrzygnięcia zapadają w tle, a potem nikt się do nich nie przyznaje.

Ile historii przenosić do nowego systemu?

Nie ma jednej dobrej liczby, jest za to sposób ustalenia granicy: sprawdź, jak daleko wstecz ktoś realnie sięga w codziennej pracy i w sprawozdaniach. Częste rozwiązanie to migracja danych operacyjnych za ostatnie dwa lata i pozostawienie starszych w archiwum tylko do odczytu. Granicę zapisz, bo nieustalona wraca jako spór w połowie projektu.

Czy analityk musi znać SQL, żeby poprowadzić migrację?

Nie musi pisać skryptów ładujących dane, ale musi umieć samodzielnie je obejrzeć: policzyć puste wartości, sprawdzić, ile różnych wartości ma pole, i zweryfikować, czy klucz naprawdę jest unikalny. Bez tego mapowanie pól jest zgadywaniem, a analityk zamienia się w pośrednika, który przekazuje pytania zamiast je rozstrzygać.

Po czym poznać, że migracja się udała?

Odbiór ma dwie warstwy. Liczbową: uzgodnienie sum kontrolnych między systemami, przy czym każda różnica ma mieć wyjaśnienie, a nie tylko akceptowalny rząd wielkości. I procesową: przejście pełnej ścieżki pracy na zmigrowanych danych przez osobę, która wykonuje ją na co dzień, bo dopiero ona zauważy, że dane są formalnie poprawne i praktycznie bezużyteczne.