Migracja udaje się wtedy, gdy większość pracy wykonano przed dniem przełączenia. Projekty, w których dzień zero jest początkiem prawdziwej roboty, kończą się źle.
Poniższa kolejność nie jest sztywnym harmonogramem, tylko układem zależności. Każdy etap korzysta z ustaleń poprzedniego, więc pomijanie kroków zwykle kończy się powrotem do nich w gorszym momencie.
1. Inwentaryzacja danych
Co mamy, ile tego jest, w jakim stanie, gdzie jeszcze poza głównym systemem. Wynikiem jest komplet liczb i lista źródeł, do których wraca się przy kontroli po przeniesieniu — opisuje to tekst o inwentaryzacji danych przed migracją.
2. Rozstrzygnięcia zakresowe
Ile historii przenosimy, czego nie przenosimy, co trafia do archiwum. Decyzje biznesowe, nie techniczne. Podejmuje je właściciel albo kierownik, bo to one wyznaczają koszt i długość całego projektu.
3. Czyszczenie
Duplikaty, braki, normalizacja. Wykonane w starym systemie, przed przenoszeniem. Warunkiem rozpoczęcia jest porządek w polach, po których systemy dopasowują rekordy; reszta może poczekać.
4. Mapowanie struktur
Pola, słowniki, typy dokumentów, wartości bez odpowiednika. Spisane i uzasadnione. Ten arkusz służy potem jako lista kontrolna przy próbie i jako jedyne wytłumaczenie decyzji po zakończeniu projektu.
5. Migracja próbna
Na pełnych danych, z kontrolami liczbowymi i weryfikacją przez użytkowników. Powtarzalna. To także moment pomiaru czasu, który wyznaczy długość okna serwisowego — szerzej w tekście o migracji próbnej i weryfikacji wyniku.
6. Przygotowanie otoczenia
Integracje, wydruki, uprawnienia, przekierowania adresów. Wszystko gotowe przed dniem zero. Ten etap bywa najbardziej niedoszacowany, bo dotyczy rzeczy, których nie widać w bazie danych.
7. Przełączenie
Z harmonogramem godzinowym, kryteriami decyzji i planem wycofania. Przebieg samego dnia opisuje tekst o przełączeniu na nowy system.
8. Stabilizacja
Kontrole, wsparcie przy pierwszym zamknięciu okresu, obserwacja zgłoszeń. Projekt kończy się dopiero tutaj, a nie w dniu uruchomienia.
Kto za co odpowiada
Podział jest stały: strona techniczna odpowiada za przeniesienie i kontrole, firma za decyzje zakresowe i potwierdzenie poprawności danych. Brak wskazanej osoby po stronie firmy zatrzymuje projekt szybciej niż jakakolwiek trudność techniczna. Rozliczenie bywa godzinowe albo ryczałtem za projekt, zależnie od zakresu; przy prostszych przypadkach i gotowych narzędziach całość zamyka się w kilka dni.
Najczęstsza przyczyna niepowodzenia
Nie problemy techniczne, lecz brak rozstrzygnięć: nie ustalono zakresu, nie zdecydowano o historii, nie sprawdzono, kto potwierdza poprawność. Te decyzje muszą zapaść na początku.
Drugą częstą przyczyną jest traktowanie dnia przełączenia jako końca projektu. Po nim zostaje jeszcze okres stabilizacji, pierwsze zamknięcie okresu i domykanie spraw, które ujawniają się dopiero przy pełnym obciążeniu. Zaplanowanie na ten czas wsparcia jest tańsze niż gaszenie problemów w biegu, gdy zespół pracuje już na nowym systemie i nie ma dokąd wrócić.
