Data migration checklist dla projektów software

Data migration checklist warto przygotować długo przed eksportem CSV. Ryzykiem nie jest samo przeniesienie rekordów z jednego miejsca do drugiego. Ryzykiem jest zbyt późne odkrycie, że dwa systemy inaczej rozumieją klientów, faktury, statusy, uprawnienia albo daty.

Widziałem migracje, które wykładały się na nudnych rzeczach: jedno pole znaczyło co innego w sprzedaży i finansach, dane testowe były czystsze niż produkcja, stare rekordy miały ręczne poprawki bez dokumentacji, a rollback oznaczał odtworzenie backupu z piątku wieczorem.

Ten przewodnik jest dla projektów software, w których dane muszą przejść między systemami: wymiana ERP, porządek w CRM, przebudowa SaaS, modernizacja legacy, handover od vendora, replika raportowa albo nowe narzędzie wewnętrzne. Użyj go, zanim pierwszy skrypt importu dotknie produkcji.

Data migration checklist przed ustaleniem zakresu

Zacznij od spisania, co migruje, co nie migruje i kto ma prawo zdecydować. Zakres migracji robi się chaotyczny, gdy każdy zespół zakłada, że jego edge case jest oczywiście uwzględniony.

Zapisz wcześnie:

Dobre pytanie nie brzmi: "czy możemy przenieść wszystko?". Brzmi: "którym danym musimy ufać pierwszego dnia?". To trzyma projekt z dala od archeologii.

Jeśli migracja jest częścią wymiany starego software, przeczytaj najpierw naszą legacy system integration strategy. Czasem bezpieczniej jest przez jakiś czas integrować się wokół starego systemu, zamiast robić nerwowy cutover.

Ustal ownership danych przed mapowaniem pól

Mapowanie pól wygląda technicznie, ale pierwszy problem to ownership. CRM może mieć email do faktur. Finanse mogą mieć prawną nazwę firmy. Support może mieć aktualny status konta. System docelowy potrzebuje jednej reguły dla każdego konfliktu.

Przygotuj prostą tabelę ownership:

Na przykład nazwa klienta może pochodzić z finansów, a nie z CRM, bo faktury używają nazwy prawnej. Nazwa wyświetlana dla sprzedaży też może migrować, ale nie powinna nadpisywać danych rozliczeniowych.

Tu wiele zespołów oszczędza tygodnie. Nie dyskutują w tygodniu importu, bo reguła biznesowa już istnieje.

Czyść dane według reguł, nie według przeczucia

Nie proś developera, żeby "wyczyścił dane", jeśli nie ma reguł. To zmienia pracę inżynierską w zgadywanie.

Pisz reguły czyszczenia tak, jakby miała je wykonać zmęczona osoba o 18:00:

Trzymaj plik odrzuceń dla rekordów, które nie przechodzą walidacji. Czysta porażka jest lepsza niż cichy, błędny import.

Rób dry run migracji na kopii produkcji

Dry run na dziesięciu ręcznie wybranych rekordach prawie niczego nie dowodzi. Użyj świeżej kopii produkcji, zamaskuj dane osobowe tam, gdzie trzeba, i uruchom tę samą ścieżkę importu, którą planujesz na go-live.

Porządny dry run powinien dać:

Zrób co najmniej dwa dry runy. Pierwszy znajduje brzydkie dane. Drugi sprawdza, czy poprawki działają. Przy złożonych migracjach ERP albo finansów trzy lub cztery próby są normalne.

Waliduj dane językiem biznesu

Walidacja techniczna mówi, że import się zakończył. Walidacja biznesowa mówi, że z danych da się korzystać.

Poproś ownerów, żeby sprawdzili scenariusze, które faktycznie ich obchodzą:

Daj reviewerom checklistę, a nie sam dostęp do bazy. Ludzie omijają problemy, gdy walidacja brzmi: "rozejrzyjcie się i dajcie znać, czy wygląda dobrze".

Przy przejęciu produktu albo handoverze od vendora połącz to z software due diligence checklist. Problemy z danymi często tłumaczą, dlaczego produkt wyglądał na łatwiejszy do przejęcia, niż był naprawdę.

Zaplanuj cutover, freeze i rollback przed go-live

Plan cutover powinien powstać przed finałowym weekendem migracji. Jeśli plan istnieje tylko w czyjejś głowie, to nie jest plan.

Ustal:

Rollback nie jest porażką. To mechanizm bezpieczeństwa. Porażką jest udawanie, że rollback istnieje, gdy nikt go nie przetestował.

Zostaw audit trail po migracji

Przez co najmniej pierwszy miesiąc trzymaj stare ID, znaczniki czasu ze źródeł, ID paczek importu, pliki odrzuceń i logi transformacji. Gdy ktoś zapyta, dlaczego saldo klienta się zmieniło, potrzebujesz odpowiedzi szybszej niż "zapytamy developera".

Dobry pakiet handover zawiera:

Tu pomaga też software requirements document. Reguły migracji powinny leżeć w tej samej ścieżce decyzyjnej co zakres produktu, integracje i acceptance criteria.

FAQ: data migration checklist

Co powinna zawierać data migration checklist?

Data migration checklist powinna obejmować systemy źródłowe i docelowe, ownership danych, mapowanie pól, reguły czyszczenia, walidację, dry runy, uzgodnienia, timing cutoveru, rollback, audit trail i support po migracji.

Jak walidować dane po migracji?

Waliduj dane przez liczbę rekordów, raport odrzuceń, uzgodnienie kwot i statusów, próbki rekordów biznesowych, kontrolę uprawnień, porównanie raportów i sign-off od zespołów, które są ownerami danych.

Ile dry runów migracji potrzeba?

Większość projektów software potrzebuje co najmniej dwóch dry runów. Pierwszy pokazuje problemy jakości danych. Drugi sprawdza, czy reguły czyszczenia, mapowanie, walidacja i czas importu wystarczą na go-live.

Kto odpowiada za data migration w projekcie software?

Odpowiedzialność jest wspólna. Engineering buduje ścieżkę migracji, ale ownerzy biznesowi definiują źródła prawdy, zatwierdzają wyjątki, walidują rekordy i decydują, co można zarchiwizować zamiast przenosić.

Jakie jest największe ryzyko migracji danych?

Największym ryzykiem zwykle nie jest skrypt importu. Jest nim niejasny ownership: pola bez źródła prawdy, konflikty między systemami, słaba walidacja i brak przetestowanego rollbacku, gdy dane produkcyjne nie pasują do założeń.

Potrzebujesz pomocy przy planowaniu migracji?

Syntanea pomaga europejskim zespołom migrować dane przy przebudowie software, integracjach systemów, handoverach od vendorów i modernizacji legacy. Mapujemy ownership, spisujemy reguły migracji, budujemy ścieżkę importu i testujemy ją, zanim dane produkcyjne będą zagrożone.

Jeśli migracja blokuje start produktu albo wymianę systemu, porozmawiaj z Syntanea. Możemy zrobić skupione discovery, znaleźć ryzykowne dane i zmienić migrację w plan, który ownerzy biznesowi naprawdę sprawdzą.

Powiązane artykuły