W projekcie zmiany platformy najwięcej uwagi zwykle dostaje wygląd nowego sklepu i lista funkcjonalności. Tymczasem to, czy migracja się uda, rozstrzyga się w zupełnie innym miejscu: przy przenoszeniu danych. Klient, który po starcie nie może się zalogować, nie widzi swoich faktur albo dostaje status zamówienia, którego nie rozumie, nie oceni nowego szablonu. Oceni to, że coś przestało działać.
Ten artykuł jest o warstwie danych. Nie o wyborze platformy ani o tym, jak zaplanować cały projekt, bo to osobne tematy. O tym, co konkretnie da się przenieść, czego nie da się przenieść nigdy, gdzie dane rozjeżdżają się po cichu i jak sprawdzić, czy przeniosły się poprawnie, zanim dowiedzą się o tym klienci.
Co realnie się przenosi
Zacznijmy od inwentarza, bo w briefach pojawia się zwykle skrót „przenosimy wszystko”, który nie jest planem.
Standardowy zakres migracji obejmuje kartotekę produktów wraz z kategoriami, opisami i zdjęciami, bazę klientów z adresami i przypisaniem do grup, historię zamówień razem ze statusami i kwotami, treści statyczne z systemu zarządzania stroną oraz dane potrzebne do zachowania widoczności w wyszukiwarce, czyli tytuły, opisy meta i adresy podstron.
To, co warto ustalić osobno i wcześnie, to obszary graniczne. Opinie o produktach bywają trzymane w zewnętrznej usłudze, więc pytanie brzmi, czy migrujemy je razem z platformą, czy zostają u dostawcy. Kody rabatowe i programy lojalnościowe mają zwykle logikę specyficzną dla starego systemu, której nie da się odwzorować jeden do jednego. Załączniki do zamówień, czyli faktury i dokumenty dostawy, bywają generowane w locie, a nie przechowywane. Punkty lojalnościowe, salda kont i limity kredytowe w modelu hurtowym to osobna kategoria, bo są danymi finansowymi i muszą się zgadzać co do złotówki.
Czego nie da się przenieść: hasła klientów
To najczęstsze zaskoczenie w projektach migracyjnych i warto zrozumieć, dlaczego tak jest.
Hasła nie są nigdzie zapisane w postaci czytelnej. Systemy przechowują ich skróty, wyliczone algorytmem właściwym dla danej platformy, i nie da się z takiego skrótu odtworzyć oryginalnego hasła. Przeniesienie samych skrótów do innego systemu nie zadziała, bo nowa platforma wylicza je inaczej i nie rozpozna starych.
Rozwiązanie jest jedno: przy pierwszym logowaniu po migracji klient ustawia nowe hasło. Ta operacja jest prosta technicznie, natomiast jej powodzenie zależy w całości od komunikacji. Klient, który wchodzi do sklepu i słyszy, że jego hasło jest nieprawidłowe, zakłada włamanie albo błąd, a nie planową zmianę.
Praktyka, która się sprawdza: wiadomość wysłana przed przepięciem, wyraźny komunikat na stronie logowania po starcie oraz krótkie wyjaśnienie w samym mailu resetującym. Warto też przygotować obsługę klienta na falę zgłoszeń w pierwszych dniach, bo część osób i tak napisze zamiast kliknąć.
Mapowanie struktur, czyli miejsce, w którym dane rozjeżdżają się po cichu
Dwie platformy prawie nigdy nie przechowują tych samych informacji w ten sam sposób. Migracja polega w dużej mierze na rozstrzygnięciu tych różnic, a każde nierozstrzygnięte rozjeżdża dane bez żadnego komunikatu o błędzie.
Adresy
Jeden system trzyma adres w dwóch polach, drugi w pięciu. Numer domu bywa osobnym polem albo częścią ulicy. Nazwa firmy i numer identyfikacji podatkowej bywają przypisane do klienta albo do konkretnego adresu. Przy migracji trzeba zdecydować, jak rozbić albo scalić te pola, i przetestować rezultat na adresach nietypowych, bo to one ujawniają błąd: mieszkania z literą, adresy zagraniczne, długie nazwy firm.
Statusy zamówień
Stary sklep miał ich zwykle kilkanaście, część dodanych przez lata pod konkretne procesy. Nowy ma własny zestaw. Mapowanie jeden do jednego rzadko istnieje, więc trzeba przygotować tabelę przypisań i podjąć decyzję o statusach, które nie mają odpowiednika. Uwaga na skutek uboczny, o którym łatwo zapomnieć: w PrestaShop zmiana statusu potrafi uruchomić wysyłkę wiadomości do klienta. Import historycznych zamówień z aktywnymi powiadomieniami oznacza, że klienci dostaną maile o zamówieniach sprzed dwóch lat.
Podatki, waluty i jednostki
Kwoty w historii zamówień muszą pozostać takie, jakie były w momencie zakupu, łącznie ze stawką podatku obowiązującą wtedy, a nie dziś. Jeśli sklep sprzedaje w kilku walutach, trzeba przenieść także kurs zastosowany przy danym zamówieniu. Osobna pułapka to zaokrąglenia: jeżeli stary system liczył od kwoty brutto, a nowy liczy od netto, sumy zamówień potrafią różnić się o grosze. Przy tysiącach zamówień te grosze widać w raportach.
Warianty produktów
W jednym systemie warianty są kombinacjami jednego produktu, w drugim osobnymi towarami z własnymi kodami. To rozstrzygnięcie wpływa na wszystko, co się do produktu odwołuje: pozycje w zamówieniach, stany magazynowe, powiązania z systemem magazynowym. Najwięcej pracy oszczędza zadbanie o to, żeby każda kombinacja miała unikalny kod EAN albo referencję, bo wtedy staje się samodzielnie identyfikowalna.
Kodowanie znaków i formaty
Ta kategoria wygląda banalnie i regularnie psuje migracje, bo błąd nie zatrzymuje importu, tylko cicho przechodzi dalej.
Polskie znaki diakrytyczne zapisane w innym kodowaniu zamieniają się w krzaki. Zwykle widać to od razu w nazwach produktów, ale już nie w polu z nazwiskiem klienta czy w komentarzu do zamówienia sprzed trzech lat. Formaty dat różnią się kolejnością dnia i miesiąca, więc piąty marca potrafi stać się trzecim maja. Separator dziesiętny bywa przecinkiem albo kropką, a przy imporcie z pliku różnica między jednym a drugim zmienia kwotę o dwa rzędy wielkości.
Sposób postępowania jest prosty i skuteczny: ustalić kodowanie i formaty na samym początku, przetestować import na próbce zawierającej celowo trudne przypadki, a po pełnym imporcie przeszukać bazę pod kątem typowych artefaktów. Jeśli w danych pojawiają się sekwencje znaków charakterystyczne dla błędnej konwersji, znajdziesz je zapytaniem w kilka minut.
Duplikaty i integralność
Migracja jest jedynym momentem, w którym opłaca się posprzątać dane, bo i tak każdy rekord przechodzi przez ręce. Jednocześnie jest momentem, w którym najłatwiej stworzyć duplikaty.
Klienci dublują się najczęściej przez adres e-mail zapisany różną wielkością liter albo przez konta zakładane wielokrotnie przy zakupach bez rejestracji. Trzeba z góry zdecydować, co jest kluczem tożsamości klienta, i czy scalać konta, czy zostawić je osobno. Scalanie wygląda atrakcyjnie, ale trzeba wtedy rozstrzygnąć, do którego konta trafia historia zamówień.
Osobna sprawa to integralność powiązań. Zamówienie musi wskazywać na istniejącego klienta, pozycja zamówienia na istniejący produkt, a produkt na istniejącą kategorię. Jeśli w starym sklepie część produktów została usunięta, a zamówienia historyczne nadal się do nich odwołują, po imporcie zostaną pozycje bez produktu. Trzeba zawczasu zdecydować, czy takie produkty odtwarzamy jako nieaktywne, czy zapisujemy ich nazwę bezpośrednio w pozycji zamówienia.
Warto też przenieść identyfikatory ze starego systemu i zapisać je w nowym. Kosztuje to jedno dodatkowe pole, a ratuje w każdej późniejszej sytuacji, w której trzeba porównać rekord z archiwum, wyjaśnić reklamację albo odtworzyć powiązanie z systemem księgowym.
Historia zamówień, czyli co właściwie znaczy „przenieść zamówienie”
Zamówienie nie jest jednym rekordem. To zamówienie, jego pozycje, adresy dostawy i rozliczeniowy, wybrana metoda płatności i dostawy, statusy wraz z datami zmian, dokumenty oraz często komentarze wewnętrzne.
Decyzja, którą trzeba podjąć świadomie, brzmi: przenosimy historię w pełnym zakresie czy tylko w takim, jaki jest potrzebny. Pełne przeniesienie daje klientowi ciągłość, a obsłudze komplet informacji, ale znacząco wydłuża projekt i powiększa bazę. Wariant oszczędny to przeniesienie ostatnich kilkunastu miesięcy w pełni, a starszych zamówień w formie uproszczonej, wystarczającej do rozliczeń i reklamacji.
Niezależnie od wyboru: zamówienia historyczne importuje się z wyłączonymi powiadomieniami i bez uruchamiania logiki magazynowej. Import, który zdejmuje stany magazynowe za zamówienia sprzed dwóch lat, zeruje dostępność całego asortymentu.
Jak sprawdzić, czy dane przeniosły się poprawnie
Testowanie migracji przez klikanie po sklepie nie działa, bo sprawdzasz wtedy kilkanaście rekordów z kilkudziesięciu tysięcy. Potrzebna jest weryfikacja liczbowa i porównawcza.
Minimalny zakres kontroli, który wykonujemy przed każdym przepięciem:
- Zgodność liczebności – liczba klientów, zamówień, produktów, kategorii i pozycji zamówień po obu stronach. Różnica musi mieć wyjaśnienie, na przykład świadomie pominięte konta testowe.
- Zgodność kwot – suma wartości wszystkich zamówień w starym i nowym systemie. To jedno zapytanie, które wykrywa całą klasę błędów w podatkach, walutach i zaokrągleniach.
- Rekordy skrajne – najstarsze i najnowsze zamówienie, zamówienie o największej liczbie pozycji, klient z największą liczbą adresów, produkt z największą liczbą wariantów. Błędy ujawniają się na krańcach, nie na średniej.
- Poprawność znaków – wyszukanie w bazie typowych artefaktów błędnej konwersji kodowania.
- Sieroty w powiązaniach – pozycje zamówień bez produktu, zamówienia bez klienta, produkty bez kategorii.
- Ścieżka zakupowa na danych produkcyjnych – pełne zamówienie testowe na kopii, z płatnością i dokumentem, żeby sprawdzić, czy przeniesione konfiguracje faktycznie działają, a nie tylko istnieją.
Całość robimy na kopii sklepu, bez ruszania działającej produkcji. To jest też moment, w którym warto zaangażować osobę z zespołu klienta znającą dane, bo tylko ona rozpozna, że czegoś brakuje albo że jakaś wartość wygląda podejrzanie.
Przepięcie i pierwsze dni po starcie
Między testami a startem mija zwykle kilka dni, a w tym czasie w starym sklepie powstają nowe zamówienia i nowe konta. Dlatego przepięcie nie jest pojedynczym importem, tylko sekwencją: pełny import wcześniej, przerwa techniczna w ustalonym oknie, dogranie przyrostu z ostatniego okresu, weryfikacja liczb, przełączenie ruchu.
Samo okno serwisowe trwa zwykle kilkadziesiąt minut i planuje się je na godziny o najniższej sprzedaży. Znacznie ważniejsze od jego długości jest to, żeby w tym czasie żadna ze stron nie przyjmowała zamówień, bo równoległa sprzedaż w dwóch systemach oznacza rozjazd, którego nie da się później czysto pogodzić.
Po starcie przez pierwsze dni pilnujemy trzech rzeczy: czy zamówienia poprawnie przechodzą do systemów zewnętrznych, czy klienci przechodzą przez reset hasła bez pomocy obsługi oraz czy w logach nie pojawiają się błędy przy odwołaniach do przeniesionych danych. Warto mieć też przygotowany scenariusz wycofania zmiany na wypadek, gdyby coś istotnego okazało się niesprawne.
Pełny przebieg projektu, od analizy po monitoring, opisujemy na stronie migracji na PrestaShop. Kwestie zachowania widoczności w wyszukiwarce, czyli przekierowań i adresacji, to osobny obszar, którym zajmujemy się równolegle z danymi.
