Migracja sklepu internetowego - co się psuje przy przenoszeniu danych

Oferty migracji mówią o przeniesieniu danych sklepu tak, jakby to była jedna rzecz. W praktyce każdy rodzaj danych ma inny stopień trudności, a część nie przenosi się wcale.

Dwie pozycje z tej tabeli zaskakują najczęściej i obie omawiamy niżej: hasła klientów i numeracja dokumentów.

Zasada, od której warto zacząć planowanie: przenosisz stan, nie historię działania. Zamówienie sprzed roku pojawi się w nowym sklepie jako rekord, ale nie odtworzy się jego ścieżka statusów, powiadomienia ani powiązania z płatnością w bramce.

To pytanie pada zwykle za późno, bo nikt nie zakłada, że może być problemem. Haseł klientów w praktyce nie da się przenieść między platformami.

Powód jest techniczny i akurat działa na korzyść bezpieczeństwa: hasła nie są przechowywane jako hasła, tylko jako wynik funkcji skrótu. Różne platformy używają różnych algorytmów i parametrów, więc skrót z jednego systemu jest bezużyteczny w drugim.

Konsekwencja jest operacyjna, nie techniczna. Każdy klient przy pierwszym logowaniu musi ustawić hasło od nowa. Jeśli tego nie zaplanujesz, dowiesz się o tym z wiadomości od klientów w dniu uruchomienia.

Co z tym zrobić:

1. Przygotuj komunikat wcześniej, wyślij go przed migracją, nie po.
2. Zadbaj, żeby procedura odzyskiwania hasła działała bezbłędnie od pierwszej minuty - to będzie najczęściej używana funkcja w pierwszym tygodniu.
3. Sprawdź, czy e-maile wychodzą i nie lądują w spamie. Nowy sklep to często nowy serwer pocztowy, a reputacja domeny buduje się od zera.

Dane z naszych wdrożeń pokazują, że przy zaniedbanym komunikacie liczba logowań w pierwszym miesiącu po migracji potrafi spaść o 20% wobec stanu sprzed zmiany - klienci nie tyle odchodzą, co kupują jako goście i tracisz historię konta.

Druga pozycja, która wygląda niepozornie i potrafi zablokować uruchomienie.

Numeracja faktur i zamówień musi być ciągła i niepowtarzalna. Nowy sklep domyślnie zacznie od jedynki, co przy działającym biznesie oznacza duplikaty numerów z dokumentami wystawionymi w starym systemie.

Trzy decyzje do podjęcia przed startem:

Od którego numeru startuje nowy system. Najprościej ustawić kontynuację, czyli numer wyższy niż ostatni wystawiony. Ustal to z księgowością, nie samodzielnie.

Gdzie zostają stare dokumenty. Zwykle w poprzednim systemie albo w archiwum. Trzeba zapewnić do nich dostęp przez okres wymagany przepisami, nawet jeśli sklep już nie działa.

Co z korektami do starych dokumentów. Klient może zwrócić towar kupiony przed migracją. Ustal, w którym systemie powstanie korekta, zanim pojawi się pierwszy taki przypadek.

Jeśli wystawiasz faktury przez KSeF, dochodzi jeszcze jedna warstwa - opisaliśmy ją w tekście o integracji sklepu z KSeF.

Produkt prosty przenosi się sam. Produkt z wariantami to osobny projekt, bo każda platforma modeluje warianty inaczej.

Typowe rozjazdy:

• Wariant jako osobny produkt kontra wariant jako opcja. Jedna platforma trzyma rozmiary jako oddzielne indeksy, druga jako warianty jednego produktu. Migracja w jedną stronę scala, w drugą rozbija.
• Atrybuty opisowe kontra decyzyjne. Kolor służący do filtrowania i kolor w opisie to w niektórych systemach to samo pole, w innych dwa różne.
• Zdjęcia przypisane do wariantu. Nie każda platforma to obsługuje. Przy migracji do prostszej struktury zdjęcia wariantów potrafią zniknąć bez ostrzeżenia.
• Stany magazynowe per wariant. Jeśli struktura się zmienia, stany trzeba przemapować, nie przepisać.

Dane z naszych wdrożeń pokazują, że przy katalogu powyżej 5 tys. indeksów samo uzgodnienie struktury wariantów zajmuje więcej czasu niż techniczne przeniesienie wszystkich pozostałych danych razem wziętych.

Praktyczna rada: zacznij od migracji próbnej na stu produktach z najtrudniejszej kategorii, nie na tysiącu prostych. Prosty katalog przejdzie zawsze i niczego nie sprawdzi.

Sklep to nie tylko baza danych. To także zestaw połączeń z bramkami płatności, kurierami, marketplace'ami i księgowością - i żadne z nich nie przenosi się razem z danymi.

Każde połączenie działa na poświadczeniach powiązanych z konkretną instalacją. Nowy sklep oznacza nowe klucze, nową autoryzację i często nowe adresy zwrotne, na które dostawca wysyła powiadomienia.

Lista do przejścia, po jednej pozycji:

Szczególnie uważaj na adresy powiadomień. Bramka płatności, która nadal wysyła potwierdzenia na stary adres, oznacza zamówienia opłacone, ale nieoznaczone jako opłacone. To jeden z tych błędów, które ujawniają się dopiero przy pierwszej realnej transakcji.

Mapowanie ofert marketplace na nowe indeksy to osobna pułapka, opisana szerzej przy diagnostyce zamówień z Allegro - po migracji wszystkie powiązania trzeba zbudować od nowa.

Migracja to nie jedno przeniesienie, tylko dwa: próbne i właściwe. Pominięcie pierwszego jest najczęstszą przyczyną chaotycznego uruchomienia.

Sensowna kolejność:

1. Migracja próbna na kopii, z pełnym katalogiem. Cel: znaleźć rozjazdy struktury, nie sprawdzić, czy się da.
2. Uzgodnienie mapowań - warianty, kategorie, statusy, metody dostawy i płatności.
3. Odtworzenie integracji na środowisku testowym, z testem pełnej ścieżki zamówienia.
4. Przekierowania przygotowane wcześniej, nie w dniu startu. Stronę SEO migracji opisaliśmy w osobnym poradniku.
5. Zamrożenie zmian w starym sklepie: żadnych nowych produktów ani zmian cen w oknie przenoszenia.
6. Migracja właściwa danych przyrostowych - zamówienia i klienci z okresu między próbą a startem.
7. Przełączenie i obserwacja.

Okno zamrożenia jest tym elementem, o którym najłatwiej zapomnieć. Jeśli w trakcie migracji ktoś doda dwadzieścia produktów w starym panelu, po przełączeniu ich nie będzie.

Migracja nie kończy się w momencie przełączenia. Pierwszy tydzień to okres, w którym wychodzą rzeczy niewidoczne w testach, bo wymagają realnego ruchu.

Co obserwować codziennie:

• Ścieżka zakupowa od początku do końca, łącznie z płatnością i potwierdzeniem. Nie raz, tylko codziennie.
• Wiadomości transakcyjne - czy wychodzą i czy nie trafiają do spamu z nowego serwera.
• Zamówienia opłacone, ale nieoznaczone - typowy objaw niepodpiętego powiadomienia z bramki.
• Błędy 404 w narzędziach dla webmasterów, bo część adresów zawsze wymyka się mapowaniu.
• Zgłoszenia o hasłach - ich liczba powie Ci, czy komunikat zadziałał.

Dane z naszych wdrożeń pokazują, że samo przeniesienie danych to zwykle poniżej 30% budżetu takiego projektu. Reszta to uzgodnienia, testy i pierwszy tydzień po starcie.

Migracje sklepów robimy w ramach wdrożeń e-commerce. Jeśli planujesz zmianę platformy, napisz przez formularz kontaktowy i podaj obecną platformę, docelową, wielkość katalogu i listę integracji - to wystarczy, żeby powiedzieć, czy to projekt na dwa tygodnie, czy na dwa miesiące.