Odpowiedź.

Historia pytania:

Migracja danych to krytyczny etap dużych projektów IT, szczególnie gdy następuje przejście z przestarzałych systemów informacyjnych (legacy) na nowe rozwiązania. Błędy w formalizacji wymagań mogą prowadzić do utraty ważnych informacji lub długich przestojów podczas uruchamiania nowego systemu (najczęściej w przypadku wdrożeń dużej skali). W historii były smutne przypadki upadków banków właśnie z powodu niepowodzeń w migracji!

Problem:

Niejasność formatów źródeł i docelowych, różnice w strukturze danych, niespójności w słownikach, błędy w mapowaniu oraz przeciwstawne oczekiwania zespołu biznesowego i technicznego integratora — to główne przyczyny problematycznych migracji. Wymyślona lub niewystarczająco szczegółowa dokumentacja prowadzi do niemożności śledzenia, które dane są krytyczne, które można agregować, a które nie mogą być przenoszone w ogóle.

Rozwiązanie:

Analityk systemowy przeprowadza audyt danych po stronie źródła wraz z właścicielami procesów biznesowych; przygotowuje szczegółową mapę danych (data mapping), określa, które atrybuty muszą być migracje, a które nie. Dokumentuje założenia dotyczące jakości danych (czystość, kompletność), określa zasady transformacji (np. zmiana formatu dat, walut, kodowań). Dla krytycznych pól wdrażana jest testowa migracja próbna i scenariusze weryfikacji (reconciliation). Na każdym etapie równolegle przygotowywane są instrukcje dotyczące rollbacku oraz kryteria sukcesu migracji.

Kluczowe cechy:

Dokładny audyt i przetwarzanie niespójności formatów między systemem źródłowym a docelowym
Wydzielenie krytycznych pól i ich priorytetyzacja
Dokumentowanie scenariuszy rollbacku i weryfikacji dokładności danych (data reconciliation)

Pytania z pułapką.

Czy wystarczy porównać formaty danych między systemami dla udanej migracji?

Nie. Nawet przy zgodności formatów mogą występować różnice w sensie biznesowym danych, ważności słowników, semantyce wartości. Potrzebny jest audyt biznesowy i techniczny każdego pola.

Czy można ograniczyć się do migracji tylko "najbardziej pożądanych" danych?

Nie. "Rzadkie" dane mogą być krytyczne biznesowo dla poszczególnych procesów użytkowników (np. dla starych umów, ubezpieczeń). Wszystko powinno być zapisane w wymaganiach.

Czy należy przewidzieć możliwość rollbacku migracji?

Obowiązkowo — nawet przy 100% testach mogą wystąpić krytyczne błędy po go-live, rollbacki są niezbędną częścią dokumentacji.

Typowe błędy i antywzorce

Niewystarczająca szczegółowość mapy danych i atrybutów biznesowych
Brak kryteriów sukcesu migracji i scenariuszy rollbacku
Ignorowanie próbnej migracji na danych testowych
Ignorowanie incydentów na styku integracyjnym (przeoczenie nieoczywistych zależności)

Przykład z życia

Negatywny przypadek: Podczas migracji dziedziczonego systemu bankowego analityk zaakceptował przeniesienie tylko głównych tabel, nie wyjaśniając sensu biznesowego starych, nieużywanych słowników. W rezultacie, po uruchomieniu, klienci napotkali problemy z historią transakcji z poprzednich lat.

Zalety:

Szybkie uruchomienie nowego systemu

Wady:

Utrata danych
Ryzyka reputacyjne banku

Pozytywny przypadek:

Analityk wspólnie z biznesem i IT przeprowadził audyt wszystkich zbiorów, sporządził oddzielne wymagania na przeniesienie "rzadkich" danych, ustalił scenariusze walidacji i rollbacku. Migracja przebiegła pomyślnie, nie pojawiły się żadne krytyczne reklamacje.