Wymiana systemu niemal zawsze oznacza konieczność przeniesienia danych. Kontakty klientów, historia zamówień, dane produktów, faktury, dokumenty – to wszystko musi trafić do nowego systemu w nienaruszonym stanie i we właściwym formacie.

Problem w tym, że dwa systemy rzadko przechowują dane w identyczny sposób. Struktury baz danych są różne, formaty dat i liczb mogą się różnić, a relacje między danymi – w nowym systemie mogą działać zupełnie inaczej. Migracja to nie kopiuj-wklej.

Dlaczego migracje danych się nie udają?

Najczęstsze przyczyny problemów podczas migracji danych:

  • Brak pełnego audytu danych źródłowych – nie wiadomo, ile danych jest, jakiej jakości, czy są duplikaty, puste pola, nieprawidłowe formaty
  • Niedoszacowanie różnic między systemami – każdy system ma swoją logikę. Pole „adres" w jednym systemie to trzy pola w innym
  • Brak testów migracji przed uruchomieniem produkcyjnym – migracja jest testowana raz, na żywo
  • Brak planu rollback – jeśli coś pójdzie nie tak, nie ma jak cofnąć zmian
  • Zaangażowanie zbyt małej liczby osób znających dane – tylko osoby, które pracują z danymi na co dzień, wiedzą co jest ważne i co może pójść nie tak

Faza 1: Audyt danych źródłowych

Zanim zaczniesz planować migrację, musisz wiedzieć, z czym masz do czynienia w systemie źródłowym.

Co sprawdzamy?

  • Ile rekordów jest w każdej tabeli / każdym module?
  • Jak stare są najstarsze dane? Czy są potrzebne w nowym systemie?
  • Czy są duplikaty, puste wymagane pola, nieprawidłowe formaty?
  • Czy dane są aktywne czy archiwalne? (często migrujemy tylko dane aktywne)
  • Jakie są relacje między zbiorami danych? (klient → zamówienia → faktury)
  • Czy są dane, których nie da się przenieść? (specyficzne dla starego systemu)

Wynik audytu to raport z listą problemów do rozwiązania przed migracją. Często okazuje się, że dane wymagają czyszczenia – i to zajmuje tyle samo czasu co sama migracja.

Faza 2: Mapowanie danych

Mapowanie to odpowiedź na pytanie: „co z czym". Dla każdego pola w systemie źródłowym definiujemy, gdzie ma trafić w systemie docelowym.

Przykład: W starym systemie klient ma jedno pole „Adres". W nowym systemie są oddzielne pola: ulica, numer, miasto, kod pocztowy, kraj. Mapowanie musi uwzględniać parsowanie adresu – a to jest trudniejsze niż się wydaje, bo dane adresowe w starym systemie rzadko są spójne.

Mapowanie często odkrywa problemy, których nie widać podczas audytu. Dlatego wykonuje je ktoś, kto zna oba systemy – nie tylko deweloper, ale też osoba znająca logikę biznesową.

Faza 3: Czyszczenie danych

Przed migracją warto wyczyścić dane źródłowe. Typowe zadania:

  • Usunięcie duplikatów klientów, produktów, kontrahentów
  • Ujednolicenie formatów dat, numerów telefonu, kodów pocztowych
  • Uzupełnienie brakujących obowiązkowych pól
  • Weryfikacja i poprawienie nieprawidłowych relacji między danymi
  • Archiwizacja starych, nieaktywnych rekordów (często nie migrujemy ich wcale)

To żmudna praca, ale zainwestowanie czasu tutaj jest zawsze tańsze niż naprawianie brudnych danych w nowym systemie po uruchomieniu produkcyjnym.

Faza 4: Budowa skryptu migracyjnego i testy

Skrypt migracyjny to program, który transformuje i przenosi dane z systemu A do systemu B. Klucz: nie uruchamiamy go raz na produkcji. Uruchamiamy wiele razy w środowisku testowym.

Ile razy testujemy?

Minimum 3 razy:

  1. Pierwsza migracja testowa – weryfikacja skryptu, identyfikacja błędów i problemów z mapowaniem
  2. Druga migracja testowa – po poprawkach, z weryfikacją przez użytkowników, którzy znają dane
  3. Migracja dress rehearsal – pełna symulacja migracji produkcyjnej, z pomiarem czasu i testowaniem procedury rollback

Planujesz zmianę systemu i potrzebujesz pomocy przy migracji danych? Zajmujemy się tym – od audytu, przez mapowanie, po uruchomienie produkcyjne.

Dowiedz się więcej →

Faza 5: Weryfikacja po migracji

Po migracji produkcyjnej trzeba zweryfikować, że dane dotarły poprawnie. To nie jest moment na wiarę w skrypt – to moment na sprawdzenie faktów.

Co weryfikujemy?

  • Liczba rekordów: czy przeniosły się wszystkie? (porównanie count przed i po)
  • Próbka danych: 20-50 losowych rekordów porównywanych ręcznie
  • Kluczowe dane: 10 najważniejszych klientów, ostatnie 100 zamówień
  • Relacje: czy zamówienia są przypisane do właściwych klientów?
  • Dane specjalne: historyczne, archiwalne, specyficzne dla branży

Plan rollback – obowiązkowo

Przed każdą migracją produkcyjną musisz mieć odpowiedź na pytanie: „co robimy, jeśli coś pójdzie nie tak?"

Plan rollback powinien obejmować:

  • Pełny backup systemu i bazy danych przed migracją
  • Procedurę przywrócenia starego systemu (ile to zajmie? kto to robi?)
  • Komunikację do użytkowników w przypadku problemów
  • Kryteria decyzji: kiedy decydujemy o rollback?

Migracja danych – podsumowanie kluczowych zasad

  • Najpierw audyt – nigdy nie zaczynaj migracji bez znajomości danych źródłowych
  • Testuj wiele razy przed migracją produkcyjną
  • Zaangażuj osoby znające dane biznesowe – nie tylko deweloperów
  • Wyczyść dane przed migracją, nie po niej
  • Zawsze miej plan rollback
  • Weryfikuj wyniki – liczba rekordów i próbka danych po migracji

Migracja danych, zrobiona metodycznie, jest przewidywalnym i bezpiecznym procesem. Zrobiona bez przygotowania – to ruletka.