Migracja sklepu internetowego bez kopiowania starych problemów. Jak uporządkować dane, procesy i SEO? 

Migracja sklepu internetowego bywa przedstawiana jak techniczna przeprowadzka: eksportujemy produkty, importujemy je do nowego systemu, podpinamy domenę i uruchamiamy sprzedaż. W praktyce taki projekt dotyczy znacznie większej części firmy. Obejmuje dane, zasady handlowe, pracę magazynu, obsługę klienta, księgowość, marketing, integracje oraz czynności wykonywane każdego dnia przez pracowników. 

Dopiero podczas analizy poprzedzającej migrację okazuje się, że poza katalogiem trzeba uwzględnić punkty programu lojalnościowego, aktywne kupony, indywidualne rabaty, środki z kart podarunkowych, limity kupieckie, zestawy produktowe i procesy stworzone specjalnie dla danego biznesu. Część z nich da się odwzorować w nowym systemie. Inne wymagają przebudowy, a niektórych nie warto przenosić w dotychczasowej formie. 

Sama struktura katalogu również może wymagać ponownego przemyślenia. Produkty zapisane jako osobne pozycje mogą w rzeczywistości stanowić warianty jednego produktu, rozdzielone wcześniej z powodu różnych opisów, zdjęć albo ograniczeń starej platformy. Zdarza się też sytuacja odwrotna: produkt posiadający wiele wariantów powinien zostać rozbity na niezależne pozycje, ponieważ poszczególne wersje mają inne zastosowania, oddzielne treści, odmienne dokumenty albo są inaczej zarządzane w ERP. 

Migracja często prowadzi więc do porządkowania danych oraz projektowania od nowa procesów sprzedażowych, logistycznych i obsługowych. Stwarza okazję, aby ustalić, skąd naprawdę pochodzą ceny, kto odpowiada za dane produktowe, jak powinny działać rabaty i które czynności wykonywane dotychczas ręcznie można uprościć albo zautomatyzować. 

W czasie takich prac wychodzą na jaw również procesy, których ktoś wcześniej mógł dokładnie nie opisać. Pracownicy przez lata wypracowują własne sposoby obsługi wyjątków, poprawiania zamówień, zmiany statusów albo obchodzenia ograniczeń platformy. Dopiero przy przenoszeniu sklepu okazuje się, że te pozornie drobne działania wpływają na sprzedaż, logistykę, księgowość lub doświadczenie klientów. 

Dlatego dobrze przeprowadzona migracja zaczyna się dużo wcześniej niż samo kopiowanie danych. Trzeba ustalić, co należy przenieść, co uporządkować, co przebudować oraz które procesy zaprojektować od nowa. Równolegle trzeba zabezpieczyć adresy URL, widoczność organiczną, kampanie Google Ads, dane klientów, integracje i zamówienia składane w czasie przełączenia. 

W tym artykule pokazujemy, jak zaplanować przeniesienie sklepu internetowego, aby nie tylko ograniczyć ryzyko błędów, lecz także wykorzystać zmianę technologii do usprawnienia działania całego e-commerce. 

Migracja sklepu internetowego nie powinna odtwarzać starego systemu jeden do jednego 

Migracja nie polega na zbudowaniu identycznego sklepu w nowszej technologii. Jeżeli bez analizy przeniesiemy wszystkie dotychczasowe rozwiązania, razem z danymi możemy skopiować dawne ograniczenia, ręczne czynności oraz procesy, które powstały jako tymczasowe obejścia problemów technicznych. 

Nie oznacza to jednak, że każdą funkcję trzeba zastąpić czymś nowym. Część mechanizmów działa poprawnie, odpowiada potrzebom klientów i nadal będzie potrzebna po migracji. Zmienić może się natomiast sposób ich realizacji. 

Program lojalnościowy może nadal naliczać punkty, ale dane nie muszą już być przechowywane wyłącznie w module sklepu. Ceny indywidualne mogą pozostać elementem sprzedaży B2B, lecz ich źródłem może zostać ERP. Zestawy produktowe nadal mogą być widoczne w ofercie, ale w nowym środowisku mogą inaczej wpływać na stany magazynowe, dokumenty sprzedaży i sposób przekazywania zamówienia do magazynu. 

Dlatego pierwszym pytaniem nie powinno być: „Jak odtworzyć tę funkcję?”. Najpierw trzeba ustalić: 

• jaki cel realizuje, 

• kto z niej korzysta, 

• jakie dane są do niej potrzebne, 

• gdzie obecnie powstają opóźnienia, 

• które czynności wykonywane są ręcznie, 

• czy funkcja powinna pozostać w sklepie, 

• czy część odpowiedzialności powinien przejąć ERP, PIM, CRM albo inny system. 

Migracja pozwala zidentyfikować wąskie gardła 

Wąskim gardłem jest etap, który spowalnia cały proces, wymaga ciągłej pracy ręcznej albo uzależnia obsługę sprzedaży od jednej osoby. 

Może nim być na przykład: 

• ręczne zatwierdzanie każdego klienta B2B, 

• codzienne przepisywanie cen z ERP, 

• poprawianie kodów produktów przed wysłaniem zamówienia, 

• ręczne łączenie płatności z zamówieniami, 

• generowanie dokumentów w kilku systemach, 

• oczekiwanie na eksport wykonywany raz dziennie, 

• poprawianie stanów po sprzedaży na platformach marketplace, 

• brak informacji o błędzie integracji, 

• procesy niepotrzebnie obciążające bazę danych lub zasoby serwera, 

• ręczne rozdzielanie zamówień pomiędzy magazyny. 

Takie działania często są traktowane jako normalny sposób pracy, ponieważ zespół korzysta z nich od lat. Dopiero podczas analizy migracyjnej widać, ile czasu zabierają oraz jak wpływają na tempo realizacji zamówień, liczbę pomyłek i możliwość dalszego zwiększania skali sprzedaży. 

Wąskiego gardła nie zawsze trzeba usuwać poprzez pełną automatyzację. Czasem wystarczy zmienić kolejność działań, przenieść odpowiedzialność do właściwego systemu albo przygotować panel służący do obsługi wyjątków. 

Funkcja może pozostać, ale działać inaczej 

Przeniesienie sklepu internetowego nie musi oznaczać rezygnacji z dobrze działających rozwiązań. Trzeba jednak oddzielić potrzebę biznesową od sposobu, w jaki była dotychczas realizowana. 

Dla klienta funkcja może wyglądać podobnie, ale w tle działać według innych zasad. To właśnie ta zmiana często decyduje o tym, czy nowy sklep rzeczywiście usprawnia pracę firmy. 

Co zachować, co przebudować, a z czego zrezygnować? 

Każdy element obecnego sklepu warto przypisać do jednej z czterech grup: 

1. Przenosimy bez większych zmian – rozwiązanie działa poprawnie i nadal odpowiada potrzebom firmy. 

2. Przenosimy, ale realizujemy inaczej – funkcja pozostaje, lecz zmienia się system odpowiedzialny, przepływ danych albo sposób obsługi. 

3. Projektujemy od nowa – cel biznesowy pozostaje, ale obecny proces tworzy opóźnienia, błędy lub ograniczenia. 

4. Nie przenosimy – element nie jest już używany, dubluje inne rozwiązanie albo generuje więcej pracy niż wartości. 

Takiej ocenie powinny podlegać nie tylko moduły widoczne dla klientów. Trzeba przeanalizować również: 

• statusy zamówień, 

• automatyczne wiadomości, 

• sposoby naliczania dostawy, 

• reguły rabatowe, 

• grupy klientów, 

• integracje, 

• eksporty, 

• raporty, 

• zadania cykliczne, 

• ręczne korekty danych, 

• pliki przesyłane pomiędzy działami, 

• czynności wykonywane poza sklepem. 

Jeżeli dany proces wymaga kilku ręcznych kroków tylko dlatego, że stary system nie pozwalał zrobić tego inaczej, nie ma powodu, aby utrwalać taki sposób pracy na następne lata. 

Odtwarzamy cel funkcji, a nie jej dawną formę 

Za pozornie prostym wymaganiem może stać inna potrzeba niż ta, którą widać na pierwszy rzut oka. 

Firma może na przykład chcieć odtworzyć funkcję pozwalającą pracownikowi ręcznie blokować zamówienia. Po analizie okazuje się jednak, że blokada jest potrzebna wyłącznie wtedy, gdy klient B2B przekroczy limit kupiecki. Zamiast kopiować ręczną funkcję, można połączyć sklep z ERP i automatycznie oznaczać zamówienia wymagające decyzji opiekuna. 

Jeżeli pracownik codziennie aktualizuje plik ze stanami, potrzebą nie jest zachowanie importu pliku. Potrzebą jest prezentowanie klientom aktualnej dostępności. 

Jeżeli handlowiec tworzy ofertę w Excelu, celem nie jest odtworzenie arkusza w panelu sklepu. Celem może być szybkie przygotowanie dokumentu zawierającego ceny klienta, narzut, logo i termin obowiązywania. 

Takie podejście pozwala zachować sens funkcji bez kopiowania ograniczeń wcześniejszego środowiska. 

Przeniesienie sklepu internetowego: od audytu obecnych procesów do zakresu nowego systemu 

Przed rozpoczęciem prac warto przeprowadzić analizę przedwdrożeniową sklepu internetowego i dokładnie sprawdzić, jak obecnie działają funkcje oraz procesy związane ze sprzedażą. Nie chodzi wyłącznie o przygotowanie listy modułów czy integracji. Każdy element powinien zostać oceniony pod kątem tego, czy spełnia swoją rolę, gdzie powoduje problemy i jak powinien działać po migracji. 

Audyt powinien połączyć perspektywę biznesową, techniczną, operacyjną, SEO, Google Ads i doświadczenia użytkownika. Efektem nie jest jedynie lista rzeczy do przeniesienia. Powinna powstać mapa pokazująca: 

• co działa prawidłowo i należy to zachować, 

• co powinno zostać zrealizowane inaczej, 

• co powoduje błędy lub opóźnienia, 

• co można oprzeć na standardzie platformy, 

• gdzie potrzebny jest moduł lub integracja, 

• które procesy wymagają dedykowanego kodu, 

• z których funkcji można zrezygnować, 

• jakie usprawnienia warto uwzględnić w projekcie. 

Najpierw sprawdzamy, jak sklep rzeczywiście działa 

Punktem wyjścia jest opisanie obecnego sposobu obsługi sprzedaży. Trzeba prześledzić nie tylko standardową ścieżkę zamówienia, ale również sytuacje nietypowe, ręczne poprawki i działania realizowane poza sklepem. 

Analiza może obejmować między innymi: 

• sposób tworzenia i aktualizowania produktów, 

• zarządzanie wariantami i zestawami, 

• ustalanie cen oraz promocji, 

• naliczanie rabatów, 

• obsługę programu lojalnościowego, 

• rejestrację i logowanie klientów, 

• składanie zamówień, 

• obsługę płatności, 

• przekazywanie zamówień do ERP, 

• aktualizację stanów magazynowych, 

• zmianę statusów, 

• generowanie faktur, 

• organizację dostaw, 

• obsługę zwrotów i reklamacji, 

• komunikację z klientem, 

• raportowanie sprzedaży, 

• konfiguratory produktów, 

• obsługę wielu magazynów, 

• zatwierdzanie zamówień B2B. 

Warto przejść przez kilka prawdziwych zamówień i sprawdzić, co dzieje się z nimi na każdym etapie. Proces opisany w dokumentacji może znacząco różnić się od tego, jak pracownicy wykonują swoje zadania w praktyce. 

W wielu firmach część procesu znajduje się poza sklepem. Może być zapisana w: 

• arkuszach z indywidualnymi rabatami, 

• wiadomościach e-mail, 

• plikach z zamiennikami produktów, 

• ręcznych listach klientów z odroczoną płatnością, 

• dokumentach dotyczących kompletowania zestawów, 

• raportach tworzonych przez konkretnych pracowników, 

• notatkach opisujących wyjątki logistyczne. 

Takie elementy trzeba uwzględnić w analizie, nawet jeśli formalnie nie należą do obecnej platformy. 

Każdą funkcję oceniamy oddzielnie 

Po zebraniu informacji funkcje i procesy można podzielić na cztery grupy. 

Działa prawidłowo i zachowujemy założenia 

Jeżeli funkcja spełnia swoją rolę, jest zrozumiała i nie utrudnia pracy, jej sens powinien pozostać. 

Nie zawsze oznacza to przeniesienie jej w identycznej formie. Lista ulubionych może wyglądać podobnie dla klienta, ale działać na podstawie innego rozszerzenia. Punkty lojalnościowe mogą być naliczane według zbliżonych zasad, choć zmieni się miejsce ich przechowywania. 

Zachowujemy rezultat, lecz dostosowujemy techniczne wykonanie do nowej platformy. 

Działa, ale będzie realizowane inaczej 

Część funkcji jest potrzebna, jednak obecny sposób działania nie pasuje do nowej architektury albo wymaga zbyt wielu operacji ręcznych. 

Przykładowo: 

• ceny B2B są dziś ustawiane w sklepie, a po migracji będą pobierane z ERP, 

• faktury są wysyłane ręcznie, a w nowym systemie pojawią się na koncie klienta, 

• stany są importowane z pliku, a po migracji będą synchronizowane automatycznie, 

• zestawy mają własny stan, a docelowo dostępność będzie wynikała ze stanów składników, 

• limit kupiecki jest sprawdzany przez handlowca, a później będzie weryfikowany przez integrację. 

W takiej sytuacji funkcja pozostaje, lecz zmienia się odpowiedzialny system, przepływ danych albo sposób jej obsługi. 

Działa nieprawidłowo i wymaga przeprojektowania 

Jeżeli obecny proces powoduje błędy, opóźnienia lub problemy użytkowników, nie powinien zostać przeniesiony bez zmian. 

Dotyczy to między innymi: 

• nieaktualnych stanów, 

• sprzedaży ponad stan, 

• błędnie naliczanych rabatów, 

• dużej liczby ręcznych korekt, 

• dublowania zamówień, 

• nieczytelnych statusów, 

• niespójnych cen, 

• braku informacji o błędach integracji, 

• ręcznego rozdzielania zamówień, 

• problemów z produktami złożonymi. 

W tym przypadku audyt powinien wskazać przyczynę problemu i opisać nowy proces, który eliminuje dotychczasowe ograniczenie. 

Funkcja nie jest już potrzebna 

W sklepie mogą pozostawać rozszerzenia, statusy, raporty i integracje, których nikt już nie używa. 

Każdy taki element: 

• zwiększa zakres migracji, 

• wymaga dodatkowych testów, 

• może utrudniać aktualizacje, 

• zwiększa koszt utrzymania, 

• tworzy kolejne zależności. 

Audyt powinien więc wskazać także funkcje przeznaczone do usunięcia. 

Najpierw korzystamy ze standardu nowego systemu 

Po ocenie funkcji trzeba sprawdzić, w jaki sposób można je zrealizować w nowej platformie. 

Pierwszym krokiem powinno być wykorzystanie standardowych możliwości systemu. Jeśli wdrożenie PrestaShop lub inna platforma obsługuje dany proces poprawnie, nie ma potrzeby budowania go od początku. 

Standard może obejmować między innymi: 

• produkty i warianty, 

• grupy klientów, 

• rabaty, 

• statusy zamówień, 

• płatności, 

• dostawy, 

• wielojęzyczność, 

• zarządzanie treściami, 

• role pracowników, 

• podstawowe raportowanie. 

Korzystanie z funkcji dostępnych w standardzie ułatwia późniejsze aktualizacje, testy i rozwój sklepu. 

Nie oznacza to jednak, że firma musi całkowicie zmieniać swoje procesy tylko po to, aby dopasować się do platformy. Trzeba znaleźć rozsądny punkt pomiędzy możliwościami systemu a rzeczywistymi potrzebami biznesowymi. 

Kiedy potrzebny jest moduł, integracja lub kod dedykowany? 

Jeżeli proces stanowi ważną część działalności i nie można go poprawnie zrealizować w standardzie, potrzebne jest rozszerzenie sklepu. 

Może zostać przygotowane poprzez: 

• konfigurację istniejącego modułu, 

• wdrożenie dodatkowego modułu, 

• modyfikację gotowego rozwiązania, 

• stworzenie dedykowanego modułu, 

• integrację z ERP, PIM, CRM lub Base, 

• przygotowanie kodu dedykowanego. 

Decyzja powinna wynikać z potrzeb procesu, a nie z chęci identycznego odtworzenia jego dawnej formy. 

W przypadku platformy PrestaShop B2B firma może potrzebować między innymi obsługi indywidualnych limitów kupieckich, cenników, subkont i zatwierdzania zamówień. Jeśli standard sklepu tego nie obsługuje, można pobierać limit z ERP i na jego podstawie decydować, czy zamówienie zostanie przyjęte, oznaczone do zatwierdzenia albo czasowo zablokowane. 

Podobnie można rozwiązać: 

• indywidualne cenniki, 

• wiele osób w ramach jednego konta B2B, 

• zatwierdzanie zamówień przez przełożonego, 

• szybkie zamówienia po SKU, 

• generowanie ofert PDF, 

• niestandardowe zestawy, 

• podział zamówień pomiędzy magazyny, 

• specjalne sposoby naliczania dostawy. 

System powinien wspierać działanie firmy, ale zakres zmian musi być uzasadniony rzeczywistym procesem. 

Audyt danych pokazuje ich liczbę i jakość 

Policzenie produktów, klientów i zamówień jest potrzebne, ale nie wystarcza do przygotowania migracji. 

Trzeba sprawdzić, czy dane są kompletne, spójne i zapisane według jednolitych zasad. 

Audyt danych może objąć: 

• kategorie i podkategorie, 

• produkty proste, 

• produkty z wariantami, 

• zestawy, 

• atrybuty i cechy, 

• producentów, 

• dostawców, 

• ceny, 

• stawki podatkowe, 

• stany, 

• zdjęcia, 

• pliki, 

• konta klientów, 

• adresy, 

• zamówienia, 

• statusy, 

• rabaty, 

• bony, 

• punkty, 

• opinie, 

• vouchery, 

• treści poradnikowe. 

Szczególnej analizy wymagają adresy klientów, ponieważ poszczególne platformy mogą wymagać innych pól. Brakujące informacje trzeba uzupełnić, pominąć albo przenieść do przygotowanych pól dodatkowych. 

W każdym obszarze trzeba zwrócić uwagę na: 

• duplikaty, 

• puste pola, 

• niejednolite nazwy, 

• nieprawidłowe kodowanie, 

• produkty bez identyfikatorów, 

• różne sposoby zapisu tych samych wartości, 

• brakujące relacje, 

• nieaktualne rekordy, 

• dane zapisane w dodatkowych modułach. 

Nie wystarczy ustalić, że sklep posiada 20 000 produktów. Trzeba również sprawdzić, ile z nich ma warianty, które posiadają własne SKU, gdzie przechowywane są zdjęcia, czy występują zestawy i czy część produktów nie została rozbita na osobne pozycje wyłącznie z powodu ograniczeń starego systemu. 

Audyt integracji określa odpowiedzialność poszczególnych systemów 

Sama informacja o tym, że została wykonana integracja ERP z PrestaShop, nie opisuje jeszcze kierunków przepływu danych, częstotliwości synchronizacji ani sposobu obsługi błędów. 

Dla każdego połączenia trzeba ustalić: 

• jakie dane są przesyłane, 

• w którym kierunku, 

• jak często, 

• który system jest źródłem, 

• co rozpoczyna synchronizację, 

• co dzieje się w przypadku błędu, 

• gdzie zapisywane są logi, 

• kto otrzymuje powiadomienie, 

• czy operację można ponowić, 

• jak wykrywane są duplikaty. 

Ważnym elementem jest ustalenie systemu nadrzędnego dla każdej grupy danych. 

Przykładowo: 

• ERP odpowiada za ceny, 

• PIM za opisy i parametry, 

• magazyn za dostępność, 

• sklep za koszyk, 

• CRM za przypisanie opiekuna, 

• system lojalnościowy za saldo punktów. 

Jeżeli dwa systemy mogą edytować tę samą informację, audyt powinien wskazać, która wartość ma pierwszeństwo. 

Audyt techniczny pokazuje, co działa w tle 

Część funkcji może być niewidoczna zarówno dla klienta, jak i administratora sklepu. 

Audyt powinien wskazać także używaną wersję PrestaShop, zgodność środowiska, modułów i dedykowanego kodu z planowaną wersją docelową. 

• wersja platformy, 

• wersja PHP, 

• baza danych, 

• moduły, 

• nadpisania, 

• dedykowany kod, 

• zadania cykliczne, 

• kolejki, 

• cache, 

• CDN, 

• serwer pocztowy, 

• kopie zapasowe, 

• certyfikaty, 

• konfiguracja domen, 

• środowiska testowe, 

• monitoring, 

• mechanizmy bezpieczeństwa. 

Trzeba ustalić, które elementy są aktywnie używane, które pozostały po wcześniejszych wdrożeniach, a które działają tylko dlatego, że pracownicy ręcznie uruchamiają określone zadania. 

Wydajność przed i po migracji 

Przed rozpoczęciem prac warto zapisać punkt odniesienia obejmujący: 

• czas ładowania kart produktów, 

• czas działania wyszukiwarki, 

• czas przeliczania koszyka, 

• czas przekazywania zamówienia do ERP, 

• czas pełnej synchronizacji stanów, 

• liczbę błędów aplikacji. 

Bez danych z obecnego sklepu trudno później ocenić, czy nowe środowisko rzeczywiście działa szybciej. 

Wiadomości transakcyjne i konfiguracja domeny 

Do sprawdzenia pozostają także: 

• serwer wysyłkowy, 

• potwierdzenia zamówień, 

• wiadomości dotyczące płatności, 

• reset hasła, 

• wiadomości dotyczące zwrotów, 

• rekordy domeny, 

• adresy nadawców, 

• dostarczalność wiadomości po przełączeniu. 

Dostęp do danych i plików migracyjnych 

Trzeba ustalić: 

• kto może pobierać eksporty, 

• gdzie będą przechowywane, 

• jak długo będą dostępne, 

• kto ma dostęp do środowisk testowych, 

• kiedy pliki robocze zostaną usunięte, 

• jak zostaną zabezpieczone kopie starego sklepu. 

Audyt kończy się mapą funkcjonalną nowego sklepu 

Efektem audytu powinien być dokument opisujący każdy obszar obecnego sklepu oraz sposób jego realizacji po migracji. 

Taki dokument pozwala ustalić: 

• pełny zakres migracji, 

• zadania niezbędne do uruchomienia, 

• prace możliwe do wykonania w kolejnych etapach, 

• elementy korzystające ze standardu, 

• wymagane moduły, 

• integracje, 

• prace dedykowane, 

• zakres testów, 

• odpowiedzialność poszczególnych systemów. 

Audyt przestaje być raportem opisującym stary sklep. Staje się podstawą do zaprojektowania nowego e-commerce, przygotowania wyceny, harmonogramu i scenariuszy testowych. 

Porządkowanie katalogu produktów przed migracją 

Jednym z rezultatów audytu powinna być decyzja dotycząca docelowej struktury katalogu. W wieloletnich sklepach produkty, warianty, zestawy i atrybuty często były dodawane według różnych zasad, dlatego nie zawsze należy przenosić je w niezmienionej formie. 

Migracja pozwala uporządkować katalog, ale wymaga wcześniejszego ustalenia spójnych i możliwych do powtórzenia reguł. Po uruchomieniu nowego sklepu dalsze zarządzanie rozbudowanym katalogiem może usprawnić także masowa edycja produktów PrestaShop, szczególnie przy zmianach cen, stanów, opisów i przypisań. 

Produkt prosty czy produkt z wariantami? 

Jednym z częstszych problemów jest nieprawidłowe rozróżnienie produktów prostych i produktów z wariantami. 

Kilka osobnych pozycji może w rzeczywistości przedstawiać jeden produkt dostępny w różnych: 

• kolorach, 

• rozmiarach, 

• pojemnościach, 

• długościach, 

• mocach, 

• wersjach materiałowych. 

Rozdzielenie ich mogło wynikać z ograniczeń starego systemu, innych opisów albo potrzeb kampanii reklamowych. 

Z drugiej strony nie każdy podobny produkt powinien zostać wariantem. Rozbicie na niezależne strony może mieć sens, gdy poszczególne wersje: 

• odpowiadają na inne potrzeby, 

• mają rozbudowane i odmienne opisy, 

• posiadają osobne zastosowania, 

• są wyszukiwane przy użyciu różnych fraz, 

• wymagają innej prezentacji technicznej, 

• mają różne instrukcje lub dokumenty, 

• są inaczej zarządzane w ERP. 

Decyzja powinna uwzględniać doświadczenie klienta, SEO, sposób zarządzania stanami oraz strukturę danych w systemach zewnętrznych. 

Zestawy nie zawsze oznaczają to samo 

W starym sklepie pod nazwą „zestaw” mogą kryć się różne mechanizmy. 

Może to być: 

• gotowy produkt posiadający własny stan, 

• pakiet kilku produktów magazynowych, 

• zestaw tworzony dynamicznie przez klienta, 

• komplet z obowiązkowymi elementami, 

• produkt główny z dodatkami, 

• produkt z grawerem, 

• opakowanie zbiorcze, 

• konfigurator, 

• promocja polegająca na wspólnym zakupie kilku pozycji. 

Każdy z tych przypadków inaczej wpływa na stany, ceny, zamówienia i integrację z ERP. 

Przed migracją należy ustalić: 

• co klient faktycznie kupuje, 

• co trafia na dokument sprzedaży, 

• jak rozchodzą się stany, 

• czy elementy można kupić osobno, 

• jak liczony jest rabat, 

• co dzieje się przy zwrocie, 

• jak zestaw jest przesyłany do magazynu. 

Bez tej analizy zestaw może wyglądać poprawnie w sklepie, ale zostać błędnie zrealizowany po złożeniu zamówienia. 

Atrybuty, cechy i filtry 

W wielu katalogach te same informacje zapisane są na kilka sposobów. Kolor może występować jako: 

• wariant, 

• cecha, 

• fragment nazwy, 

• osobna kategoria, 

• tag, 

• tekst w opisie. 

Migracja powinna doprowadzić do ustalenia, gdzie dana informacja ma być przechowywana i do czego będzie używana. 

Trzeba rozróżnić dane wpływające na zakup od danych wyłącznie opisowych. Rozmiar wskazywany przez klienta może być wariantem, podczas gdy materiał produktu pozostaje cechą wykorzystywaną w filtrach. 

Nieuporządkowane wartości powodują później problemy takie jak: 

• kilka filtrów o podobnym znaczeniu, 

• wartości „czarny”, „czarne” i „black”, 

• puste warianty, 

• brak możliwości przygotowania poprawnego feedu, 

• problemy z integracją PIM, 

• nieczytelna nawigacja. 

Kategorie powinny odpowiadać sposobowi szukania produktów 

Struktura kategorii nie powinna być prostą kopią działów w ERP albo wewnętrznego podziału firmy. 

Klient może szukać produktów według: 

• zastosowania, 

• branży, 

• rodzaju, 

• pomieszczenia, 

• problemu, 

• parametrów, 

• producenta, 

• poziomu zaawansowania. 

Wewnętrzna klasyfikacja magazynowa może być niezrozumiała dla osoby kupującej. Migracja jest dobrym momentem, aby oddzielić strukturę operacyjną od nawigacji sklepu. 

Identyfikatory produktów 

Trzeba ustalić, które identyfikatory są trwałe i wykorzystywane poza sklepem. 

Mogą to być: 

• SKU, 

• EAN, 

• indeks ERP, 

• kod producenta, 

• identyfikator PIM, 

• identyfikator wariantu, 

• dawny numer produktu w sklepie. 

Nowa platforma może nadać własne numery wewnętrzne. Nie powinny one automatycznie zastępować identyfikatorów używanych przez ERP, magazyn, platformy marketplace, system reklamacyjny, Merchant Center lub Google Analytics 4. 

Warto przygotować tabelę mapowania starych i nowych numerów. Ułatwia ona obsługę starszych zamówień i pozwala zachować ciągłość danych w systemach zewnętrznych. 

Dane nie powinny być czyszczone bez reguł 

Porządkowanie nie oznacza usuwania wszystkiego, co wydaje się niepotrzebne. 

Każda zmiana powinna wynikać z opisanej zasady: 

• usuwamy produkty nieaktywne od określonego czasu, 

• łączymy wskazane kategorie, 

• ujednolicamy nazwy wartości, 

• zachowujemy nieaktywne produkty z ruchem organicznym, 

• przenosimy dokumenty do nowej biblioteki, 

• nie importujemy pustych atrybutów, 

• zachowujemy dane potrzebne do historycznych zamówień. 

Dzięki temu proces można powtórzyć przy końcowej synchronizacji, zamiast poprawiać dane ręcznie po każdym imporcie. 

Klienci, rabaty i program lojalnościowy podczas migracji 

Przeniesienie kont klientów nie kończy się na imporcie imienia, nazwiska, adresu e-mail i historii zamówień. W wielu sklepach do konta przypisane są również punkty lojalnościowe, indywidualne rabaty, bony, karty podarunkowe, środki wynikające ze zwrotów oraz specjalne warunki handlowe. 

Przed migracją trzeba zdecydować, które z tych mechanizmów pozostają w nowym sklepie, które zmienią zasady działania, a które zostaną zakończone jeszcze przed uruchomieniem nowej platformy. 

Nie każdy stary program lojalnościowy musi być przenoszony. Czasem firma chce go uprościć, zastąpić innym rozwiązaniem albo całkowicie z niego zrezygnować. Taka decyzja musi jednak zapaść odpowiednio wcześnie, ponieważ wpływa na komunikację z klientami, harmonogram uruchomienia i zakres danych do migracji. 

Bilans korzyści klientów przed migracją 

Przed podjęciem decyzji firma powinna znać rzeczywistą skalę zobowiązań wobec klientów. 

Należy sprawdzić: 

• liczbę klientów z aktywnym saldem, 

• łączną liczbę punktów, 

• wartość punktów po przeliczeniu na rabaty, 

• liczbę aktywnych bonów, 

• wartość kart podarunkowych, 

• środki wynikające ze zwrotów, 

• terminy ważności korzyści, 

• punkty związane z zamówieniami pozostającymi w realizacji. 

Dopiero na podstawie takiego bilansu można zdecydować, czy punkty migrujemy, przeliczamy, zamieniamy na kody czy pozwalamy wykorzystać przed uruchomieniem nowego sklepu. 

Czy program lojalnościowy w ogóle przenosimy? 

Pierwszym pytaniem nie powinno być: „Jak zaimportować punkty?”. Najpierw trzeba ustalić, czy program ma dalej działać oraz czy jego dotychczasowe zasady nadal odpowiadają firmie i klientom. 

Warto sprawdzić: 

• ilu klientów posiada aktywne punkty, 

• ilu klientów rzeczywiście korzysta z programu, 

• kiedy ostatnio naliczano lub wykorzystywano punkty, 

• czy punkty mają termin ważności, 

• czy program wpływa na powtarzalność zakupów, 

• ile pracy wymaga jego obsługa, 

• czy mechanizm jest zrozumiały dla klientów, 

• czy punkty są naliczane również za aktywności inne niż zakupy, 

• czy dotychczasowy system przechowuje pełną historię operacji. 

Na tej podstawie można przyjąć jeden z kilku scenariuszy: 

1. Program pozostaje bez większych zmian – przenosimy salda i odtwarzamy dotychczasowe zasady. 

2. Program pozostaje, ale zmienia zasady – przenosimy korzyści klientów, lecz inaczej naliczamy lub wykorzystujemy punkty. 

3. Program zostaje zastąpiony innym mechanizmem – punkty mogą zostać zamienione na bony, rabaty albo saldo startowe. 

4. Program zostaje zakończony – klienci otrzymują czas na wykorzystanie zgromadzonych korzyści. 

5. Przenosimy tylko część danych – na przykład aktualne saldo bez pełnej historii operacji. 

Każdy scenariusz wpływa na zakres techniczny i sposób komunikacji z klientami. 

Co zrobić, jeżeli program lojalnościowy nie będzie migrowany? 

Jeśli firma nie zamierza przenosić programu, nie należy po prostu wyzerować punktów w dniu uruchomienia nowego sklepu. 

Trzeba ustalić: 

• dzień zakończenia naliczania nowych punktów, 

• termin wykorzystania zgromadzonego salda, 

• możliwość zamiany punktów na kod rabatowy, 

• sposób obsługi punktów niewykorzystanych w terminie, 

• zasady dotyczące punktów za zamówienia będące w realizacji, 

• sposób informowania klientów, 

• proces obsługi reklamacji zgłoszonych po zamknięciu programu. 

Harmonogram powinien obejmować: 

1. ustalenie dnia zakończenia naliczania punktów, 

2. poinformowanie klientów o planowanych zmianach, 

3. wyznaczenie terminu wykorzystania salda, 

4. wysłanie przypomnień, 

5. zamknięcie programu i rozliczenie pozostałych korzyści. 

Terminy powinny wynikać z regulaminu programu, wartości zgromadzonych punktów, komunikacji i ustaleń prawnych. 

Warto również przygotować osobną stronę z zasadami zakończenia programu i odpowiedziami na pytania klientów. 

Co przenosimy, jeżeli program ma działać dalej? 

Jeżeli program pozostaje, trzeba ustalić zakres danych potrzebnych do zachowania ciągłości. 

Do migracji mogą trafić: 

• aktualne saldo punktów, 

• punkty oczekujące na zatwierdzenie, 

• punkty z terminem ważności, 

• historia naliczania, 

• historia wykorzystania, 

• anulowane operacje, 

• poziom uczestnika, 

• przypisane nagrody, 

• kupony utworzone za punkty, 

• informacje o ręcznych korektach. 

Samo saldo często nie wystarcza. Klient może zapytać, dlaczego posiada określoną liczbę punktów, kiedy część z nich wygaśnie albo dlaczego punkty zostały odjęte po zwrocie zamówienia. 

Jeżeli pełna historia nie może zostać przeniesiona do nowego sklepu, powinna zostać zachowana w zabezpieczonym archiwum dostępnym dla obsługi. 

Jak przeliczyć punkty po zmianie zasad? 

Nowa platforma może korzystać z innych zasad naliczania punktów. Przykładowo w starym sklepie klient otrzymywał jeden punkt za każde wydane 10 zł, a w nowym systemie jeden punkt odpowiada określonej wartości rabatu. 

W takim przypadku trzeba ustalić: 

• czy stare punkty zachowują dotychczasową wartość, 

• czy zostaną przeliczone według nowego kursu, 

• jak zaokrąglamy wynik, 

• czy istnieje minimalna wartość salda, 

• czy dotychczasowe terminy ważności pozostają, 

• czy klient otrzyma informację o przeliczeniu, 

• jak obsłużymy różnice i reklamacje. 

Reguła powinna być jednoznaczna i możliwa do zastosowania automatycznie. 

Po przeliczeniu należy przygotować raport porównujący: 

• stare saldo, 

• nowe saldo, 

• zastosowany współczynnik, 

• różnicę wynikającą z zaokrąglenia, 

• status migracji konta. 

Takiego procesu nie powinno się wykonywać ręcznie dla tysięcy klientów. 

Punkty muszą uwzględniać zamówienia w trakcie realizacji 

W dniu migracji część zamówień może być: 

• opłacona, ale jeszcze niewysłana, 

• wysłana, ale nieodebrana, 

• w trakcie zwrotu, 

• anulowana po naliczeniu punktów, 

• objęta reklamacją, 

• złożona tuż przed końcową synchronizacją. 

Trzeba ustalić, w którym momencie punkty stają się aktywne. Mogą być naliczane: 

• po złożeniu zamówienia, 

• po zaksięgowaniu płatności, 

• po wysyłce, 

• po upływie terminu na zwrot, 

• po ręcznym zatwierdzeniu. 

Od tej zasady zależy, które punkty należy przenieść jako aktywne, które jako oczekujące, a które pominąć. 

Podobnej analizy wymaga zwracanie punktów po anulowaniu lub zwrocie. Jeśli mechanizm nie zostanie odtworzony, klient może zachować korzyść z zakupu, który został cofnięty. 

Jak testować migrację programu lojalnościowego? 

Testy powinny obejmować różne typy kont, a nie tylko użytkownika z prostym saldem. 

Warto sprawdzić: 

• klienta bez punktów, 

• klienta z aktywnymi punktami, 

• klienta z punktami wygasającymi wkrótce, 

• klienta z punktami oczekującymi, 

• klienta, który wykorzystał część salda, 

• klienta z anulowanym zamówieniem, 

• klienta po zwrocie, 

• klienta posiadającego kupon utworzony z punktów, 

• konto z ręczną korektą salda, 

• konto posiadające kilka wersji walutowych lub językowych. 

Po imporcie należy porównać: 

• saldo, 

• historię, 

• daty ważności, 

• status punktów, 

• wartość możliwego rabatu, 

• działanie po kolejnym zakupie, 

• zachowanie po zwrocie. 

Trzeba także przeprowadzić próbę końcowej synchronizacji. Punktów może przybyć między pierwszym importem a dniem uruchomienia sklepu. 

Co zrobić z aktywnymi kuponami rabatowymi? 

Kupony powinny zostać przeanalizowane oddzielnie od punktów, ponieważ każdy kod może posiadać własne warunki. 

Trzeba ustalić: 

• czy kod jest nadal aktywny, 

• do kiedy obowiązuje, 

• kto może go użyć, 

• ile razy można go wykorzystać, 

• czy jest przypisany do konta, 

• jakich produktów dotyczy, 

• czy łączy się z innymi promocjami, 

• czy posiada minimalną wartość koszyka, 

• czy działa w konkretnym kraju lub walucie, 

• czy obejmuje koszty dostawy. 

Możliwe są trzy scenariusze: 

1. Przenosimy aktywne kody wraz z ich warunkami. 

2. Pozwalamy wykorzystać je wyłącznie w starym sklepie przed migracją. 

3. Zastępujemy je nowymi kodami o odpowiadającej wartości. 

Nie wystarczy przenieść samego ciągu znaków. Kod „KUPON100ZL” bez przypisanych ograniczeń może po migracji udzielać rabatu na cały asortyment, mimo że wcześniej dotyczył jednej kategorii. 

Indywidualne rabaty klientów 

Rabat przypisany do klienta może być zapisany jako: 

• procent od całego koszyka, 

• rabat dla określonej kategorii, 

• cena indywidualna produktu, 

• osobny cennik, 

• reguła zależna od ilości, 

• rabat przypisany do grupy, 

• rabat określony czasowo, 

• warunek handlowy pobierany z ERP. 

Przed migracją trzeba ustalić, gdzie znajduje się rzeczywiste źródło tej informacji. 

Jeżeli rabaty mają pochodzić z ERP, nie ma sensu importować ich do sklepu jako ręcznych reguł, które później zostaną nadpisane. W takim przypadku trzeba przenieść przypisanie klienta do właściwego identyfikatora lub grupy i uruchomić pobieranie warunków z systemu nadrzędnego. 

Bony, karty podarunkowe i środki ze zwrotów 

Osobną grupę stanowią środki mające określoną wartość pieniężną. 

Mogą to być: 

• karty podarunkowe, 

• bony, 

• środki przyznane po zwrocie, 

• saldo reklamacyjne, 

• niewykorzystana część wcześniejszego kodu, 

• kredyt na koncie klienta. 

Przy każdym takim elemencie trzeba ustalić: 

• aktualną wartość, 

• termin ważności, 

• właściciela, 

• zakres wykorzystania, 

• możliwość częściowego użycia, 

• historię wcześniejszych transakcji, 

• sposób rozliczenia księgowego. 

Jeśli nie można przenieść mechanizmu wprost, firma może utworzyć odpowiedni kod lub saldo w nowym systemie. Każda zamiana powinna zostać odnotowana, aby obsługa mogła odtworzyć historię korzyści klienta. 

Konta klientów i zachowanie haseł 

Niezależnie od rabatów i programu lojalnościowego trzeba ustalić zakres migracji samych kont. 

Może on obejmować: 

• dane podstawowe, 

• adresy, 

• dane firmowe, 

• zgody, 

• grupy klientów, 

• historię zamówień, 

• subkonta i ich strukturę, 

• przypisane rabaty, 

• opiekuna, 

• punkty i bony. 

Możliwość zachowania haseł zależy od sposobu ich zabezpieczenia w obu platformach. Jeżeli mechanizmy są niezgodne, klienci będą musieli ustawić nowe hasło. 

Proces powinien zostać przygotowany przed uruchomieniem. Trzeba sprawdzić wiadomości, linki resetujące, obsługę wygasłych linków i zachowanie kont, które nie mają już dostępu do dawnego adresu e-mail. 

Konta B2B wymagają dodatkowego mapowania 

W sprzedaży firmowej konto może być powiązane z większą liczbą informacji niż standardowy klient detaliczny. 

Należą do nich: 

• grupa cenowa, 

• indywidualny cennik, 

• limit kupiecki, 

• wykorzystana część limitu, 

• termin płatności, 

• opiekun, 

• oddziały, 

• pracownicy firmy, 

• role i uprawnienia, 

• minimalne ilości, 

• jednostki zbiorcze, 

• dostęp do wybranej części katalogu. 

Przed migracją trzeba określić, które dane są przechowywane w sklepie, a które pochodzą z ERP lub CRM. 

Niektórych informacji nie trzeba importować do bazy sklepu, jeżeli mogą być pobierane na bieżąco z systemu odpowiedzialnego za ich aktualność. 

Decyzje dotyczące korzyści klientów muszą zapaść przed go-live 

Program lojalnościowy, punkty, kupony i bony nie powinny być zostawiane na końcowy etap projektu. 

Najpóźniej przed rozpoczęciem importów testowych powinno być wiadomo: 

• które korzyści przechodzą do nowego sklepu, 

• które wygasają, 

• jak będą przeliczane, 

• do kiedy można je wykorzystać, 

• co stanie się z aktywnymi zamówieniami, 

• jak poinformujemy klientów, 

• gdzie zachowamy historię. 

Efektem powinien być osobny plan migracji korzyści klientów, a nie tylko dodatkowa kolumna w pliku z kontami. 

Projektowanie nowych procesów biznesowych podczas migracji 

Migracja daje możliwość przeprojektowania sposobu obsługi sprzedaży. Nie oznacza to, że każda czynność musi zostać zautomatyzowana. Celem jest usunięcie zbędnych etapów i jasne opisanie sytuacji, w których nadal potrzebna jest decyzja człowieka. 

Najwięcej korzyści przynosi analiza procesów przebiegających pomiędzy kilkoma działami i systemami. 

Cykl życia zamówienia 

Wiele sklepów posiada kilkanaście lub kilkadziesiąt statusów zamówień. Część została dodana na potrzeby integracji, część magazynu, a część komunikacji z klientem. 

Przed ich odtworzeniem trzeba ustalić: 

• które statusy opisują rzeczywisty etap realizacji, 

• które są wyłącznie techniczne, 

• które powinien widzieć klient, 

• które uruchamiają wiadomości, 

• które blokują edycję, 

• które są nadawane przez ERP, 

• które wynikają z płatności, 

• które oznaczają wyjątek wymagający reakcji. 

Dwa statusy o podobnej nazwie mogą pełnić zupełnie inne funkcje. Z kolei jeden status może być przeciążony i oznaczać kilka sytuacji. 

Docelowy schemat powinien być zrozumiały dla klienta i pracowników, a jednocześnie wystarczająco dokładny dla integracji. 

Proces obsługi błędów 

Integracja nie powinna być oceniana wyłącznie na podstawie prawidłowego przesyłania danych. Równie ważne jest zachowanie systemu po błędzie. 

Trzeba ustalić: 

• co się stanie, gdy ERP nie rozpozna produktu, 

• gdzie trafi informacja o błędzie, 

• czy pozostałe zamówienia będą nadal przesyłane, 

• czy operacja zostanie automatycznie ponowiona, 

• czy pracownik może uruchomić ją ręcznie, 

• gdzie zostanie zapisana przyczyna, 

• jak uniknąć utworzenia duplikatu. 

Proces bez obsługi wyjątków działa tylko do pierwszego nietypowego przypadku. 

Źródło prawdy dla danych 

Dla każdej grupy informacji powinien istnieć system, który rozstrzyga jej aktualną wartość. 

Przykładowo: 

• ERP odpowiada za ceny, 

• PIM odpowiada za opisy i parametry, 

• magazyn odpowiada za dostępność, 

• sklep odpowiada za koszyki, 

• CRM odpowiada za przypisanie opiekuna, 

• system lojalnościowy odpowiada za punkty. 

Jeżeli cena może być edytowana równocześnie w sklepie i ERP, trzeba ustalić, która zmiana ma pierwszeństwo. W przeciwnym razie poprawki będą znikać po kolejnej synchronizacji. 

Rabaty i promocje 

Reguły cenowe często narastają przez lata. Zanim zostaną przeniesione, trzeba sprawdzić: 

• które są nadal aktywne, 

• czy się ze sobą łączą, 

• w jakiej kolejności są naliczane, 

• czy obejmują warianty, 

• co dzieje się po zwrocie, 

• czy rabat wpływa na darmową dostawę, 

• czy klient B2B może użyć kodu publicznego, 

• czy ceny promocyjne trafiają poprawnie do platform marketplace. 

Migracja może być dobrym momentem na uproszczenie zasad. Klient powinien rozumieć cenę, a obsługa powinna móc wyjaśnić sposób jej obliczenia. 

Zwroty i reklamacje 

Proces po zakupie bywa pomijany podczas projektowania nowego sklepu. Tymczasem klient może chcieć: 

• zgłosić zwrot, 

• wskazać produkty z zamówienia, 

• podać przyczynę, 

• pobrać etykietę, 

• śledzić status, 

• otrzymać korektę, 

• odzyskać punkty lub kod. 

Trzeba ustalić, gdzie rejestrowane są takie zgłoszenia i jak łączą się z ERP, magazynem, płatnością oraz programem lojalnościowym. 

Komunikacja z klientem 

Każda automatyczna wiadomość powinna wynikać z konkretnego zdarzenia. 

Warto przeanalizować: 

• potwierdzenie rejestracji, 

• ustawienie hasła, 

• przyjęcie zamówienia, 

• potwierdzenie płatności, 

• brak płatności, 

• zmianę statusu, 

• wysyłkę, 

• opóźnienie, 

• anulowanie, 

• zwrot, 

• reklamację, 

• przyznanie punktów, 

• wygaśnięcie bonu. 

Nie wszystkie komunikaty muszą wychodzić ze sklepu. Część może być wysyłana z systemu marketingowego, ERP albo narzędzia logistycznego. Ważne, aby klient nie otrzymywał kilku sprzecznych wiadomości dotyczących tego samego zdarzenia. 

Migracja danych jako proces: eksport, transformacja i import 

Dane ze starego sklepu rzadko pasują bezpośrednio do struktury nowego systemu. Trzeba je pobrać, przekształcić według ustalonych reguł, zaimportować i porównać ze źródłem. 

Dokumentacja techniczna PrestaShop opisuje taki proces jako ETL: extract, transform, load, czyli pobranie, przekształcenie i załadowanie danych. Struktura baz może zmieniać się pomiędzy wersjami i platformami, dlatego migracja nie jest zwykłym skopiowaniem tabel. 

Eksport danych źródłowych 

Eksport powinien być możliwy do powtórzenia. Pierwsza wersja służy do analizy i testów, ale przed uruchomieniem trzeba pobrać aktualne dane ponownie. 

Dla każdego eksportu warto zapisać: 

• źródło, 

• datę i godzinę, 

• zakres rekordów, 

• kodowanie, 

• separator, 

• liczbę pozycji, 

• sposób traktowania pustych wartości, 

• filtry zastosowane podczas pobierania. 

Bez takiego raportu trudno ocenić, dlaczego pierwszy plik zawierał 30 000 produktów, a kolejny 27 500. 

Transformacja danych 

Transformacja może obejmować: 

• zmianę nazw pól, 

• ujednolicenie wartości, 

• połączenie kategorii, 

• rozdzielenie produktów, 

• utworzenie wariantów, 

• mapowanie identyfikatorów, 

• poprawienie kodowania, 

• usunięcie duplikatów, 

• przeliczenie stawek, 

• zmianę formatów dat, 

• uporządkowanie treści HTML. 

Reguły powinny być zapisane w skrypcie lub dokładnej dokumentacji. Ręczne poprawki w pliku utrudniają powtórzenie procesu podczas końcowego importu. 

Kolejność importu 

Dane posiadają wzajemne zależności. Nie można poprawnie przypisać produktu do kategorii, która jeszcze nie istnieje, ani zamówienia do klienta, który nie został utworzony. 

Przykładowa kolejność może obejmować: 

1. słowniki i ustawienia, 

2. producentów, 

3. kategorie, 

4. cechy i atrybuty, 

5. produkty, 

6. warianty, 

7. zdjęcia i dokumenty, 

8. klientów, 

9. adresy, 

10. warunki B2B, 

11. zamówienia, 

12. płatności, 

13. dokumenty, 

14. rabaty, 

15. punkty, 

16. opinie i treści. 

Import próbny 

Pierwszy import powinien odbywać się na środowisku testowym. 

Warto rozpocząć od niewielkiej, ale zróżnicowanej próbki: 

• produktu prostego, 

• produktu z wariantami, 

• zestawu, 

• produktu z promocją, 

• produktu niedostępnego, 

• produktu z dokumentami, 

• klienta detalicznego, 

• klienta B2B, 

• zamówienia ze zwrotem, 

• zamówienia z rabatem. 

Po ręcznym sprawdzeniu próbki można przejść do pełnego zbioru. 

Walidacja danych 

Zgodność liczby rekordów jest potrzebna, ale nie wystarcza. 

Trzeba sprawdzić również: 

• relacje produktów z kategoriami, 

• warianty, 

• przypisanie zdjęć, 

• wartości cen, 

• stawki VAT, 

• sumy zamówień, 

• rabaty, 

• powiązanie zamówień z klientami, 

• dokumenty, 

• historię punktów, 

• aktywne bony. 

Każda różnica powinna mieć przyczynę. Nie każda oznacza błąd, ale żadna nie powinna pozostać niewyjaśniona. 

Migracja pełna i końcowa synchronizacja 

Budowa nowego sklepu może trwać kilka miesięcy. W tym czasie stary system nadal przyjmuje zamówienia, rejestruje klientów i aktualizuje dane. 

Najczęściej potrzebne są więc dwa etapy: 

• pełna migracja wykonana wcześniej na potrzeby testów, 

• końcowa synchronizacja obejmująca nowe i zmienione rekordy. 

Trzeba z góry ustalić, jak rozpoznawane są różnice oraz co dzieje się z rekordem zmienionym równocześnie w obu środowiskach. 

Migracja sklepu internetowego bez utraty widoczności SEO i ciągłości kampanii Google Ads 

Zmiana platformy wpływa nie tylko na pozycje sklepu w bezpłatnych wynikach wyszukiwania. Może również przerwać działanie kampanii Google Ads, feedów produktowych, remarketingu dynamicznego, analityki e-commerce oraz pomiaru sprzedaży. 

Nowy sklep może działać prawidłowo z perspektywy klienta, a jednocześnie przesyłać do Google inne identyfikatory produktów, prowadzić reklamy na nieaktualne adresy albo rejestrować zakup bez wartości zamówienia. 

Dlatego SEO, Merchant Center, Google Ads, Google Analytics 4 i Google Tag Manager powinny zostać uwzględnione w jednym planie migracyjnym. 

SEO i Google Ads wymagają wspólnego planu z dwiema ścieżkami działań 

Oba obszary powinny być prowadzone w ramach jednego planu, ale wymagają oddzielnych checklist, testów i osób odpowiedzialnych. 

W SEO najważniejsze są między innymi: 

• adresy URL, 

• przekierowania, 

• treści, 

• linkowanie wewnętrzne, 

• adresy kanoniczne, 

• indeksowalność, 

• mapy witryny, 

• dane strukturalne. 

W Google Ads i Merchant Center trzeba dodatkowo zabezpieczyć: 

• identyfikatory produktów, 

• identyfikatory grup wariantów, 

• linki w feedzie, 

• remarketing dynamiczny, 

• zdarzenia e-commerce, 

• pomiar konwersji, 

• wartości zamówień, 

• identyfikatory transakcji, 

• listy odbiorców, 

• tagi, 

• parametry śledzenia, 

• zgody użytkowników. 

Przygotowanie wyłącznie przekierowań 301 nie wystarczy. Reklama może prawidłowo przekierować użytkownika na nową kartę produktu, ale Google Ads może przestać łączyć jego wcześniejsze zachowanie z produktem znajdującym się w Merchant Center. 

Mapa starych i nowych adresów URL 

Mapa powinna obejmować: 

• produkty, 

• warianty, 

• kategorie, 

• producentów, 

• poradniki, 

• strony kampanii, 

• filtry generujące ruch, 

• wersje językowe, 

• pliki, 

• strony wykorzystywane w reklamach. 

Każdy wartościowy stary adres powinien prowadzić bezpośrednio do najbardziej zbliżonej strony w nowym sklepie. 

Google zaleca stosowanie stałych przekierowań serwerowych, takich jak 301 lub 308, oraz unikanie łańcuchów prowadzących przez kilka kolejnych adresów. 

Nie należy kierować wszystkich usuniętych produktów na stronę główną. Jeżeli nie istnieje bezpośredni odpowiednik, właściwym miejscem może być następca produktu albo odpowiednia kategoria. 

Przekierowanie powinno odpowiadać temu, czego użytkownik szukał. 

Przekierowanie nie zastępuje aktualizacji linków reklamowych 

Przekierowania zabezpieczają wejścia ze starych adresów, ale reklamy powinny prowadzić bezpośrednio do nowych stron. 

Po migracji trzeba przejrzeć: 

• końcowe adresy URL reklam w sieci wyszukiwania, 

• linki do podstron, 

• strony przypisane do grup reklam, 

• adresy w feedzie produktowym, 

• atrybut ads_redirect, 

• szablony śledzenia, 

• końcowe sufiksy adresów, 

• reguły ValueTrack, 

• adresy używane w kampaniach remarketingowych. 

Pozostawienie starych adresów może wydłużać czas otwierania strony, utrudniać diagnostykę i powodować problemy z parametrami analitycznymi. 

Jak zachować spójność identyfikatorów produktów w Merchant Center, Google Ads i GA4? 

Jednym z najważniejszych obszarów jest zachowanie stabilnych identyfikatorów produktów przekazywanych do systemów Google. 

Należy odróżnić: 

• ID rekordu w bazie starego sklepu, 

• ID rekordu w bazie nowego sklepu, 

• SKU, 

• EAN lub GTIN, 

• indeks ERP, 

• identyfikator produktu w Merchant Center, 

• item_id wysyłany do GA4, 

• identyfikator przekazywany do remarketingu dynamicznego. 

Nowa platforma może nadać produktom inne wewnętrzne numery. Nie musi to powodować problemu, jeżeli Google nadal otrzymuje tę samą stabilną wartość. 

Najbezpieczniej oprzeć identyfikację przekazywaną do Google na wartości niezależnej od platformy, na przykład SKU lub indeksie ERP. 

Jeżeli dotychczas Merchant Center korzystało bezpośrednio z numerów bazy starego sklepu, trzeba przygotować mapę powiązań i zadbać, aby nowy feed nadal wysyłał wcześniejsze identyfikatory. 

Czasem struktura katalogu zmienia się na tyle, że zachowanie wszystkich wartości nie jest możliwe. Może to nastąpić, gdy: 

• kilka produktów prostych zostaje połączonych w jeden produkt wariantowy, 

• jeden produkt wariantowy zostaje rozdzielony, 

• zmienia się sposób tworzenia zestawów, 

• usuwane są duplikaty, 

• katalog zostaje połączony z PIM lub ERP. 

Nie każda zmiana identyfikatora jest błędem. Musi jednak być świadomą decyzją, a nie przypadkowym skutkiem importu. 

Warianty i item_group_id 

W feedzie produktowym każdy wariant powinien posiadać własny identyfikator id. Warianty jednego produktu mogą być połączone wspólną wartością item_group_id. 

Jeżeli przed migracją każda wersja koloru lub rozmiaru była osobnym produktem, a po migracji powstanie jeden produkt wariantowy, trzeba ustalić: 

• które wcześniejsze ID pozostają identyfikatorami wariantów, 

• jaka będzie wspólna wartość item_group_id, 

• czy każda wersja prowadzi do właściwie ustawionego wariantu, 

• czy cena i dostępność odpowiadają danym z feedu. 

Strona docelowa powinna prezentować wariant odpowiadający temu, co użytkownik zobaczył w reklamie. 

Feed produktowy musi prowadzić do nowych stron 

Po migracji trzeba zaktualizować feed produktowy, aby Merchant Center i pozostałe kanały otrzymywały aktualne adresy, zdjęcia, ceny oraz informacje o dostępności. 

• link, 

• mobile_link, jeżeli jest używany, 

• ads_redirect, 

• canonical_link, 

• linki do zdjęć. 

W feedzie powinny znaleźć się aktualne strony docelowe, ponieważ: 

• ograniczamy liczbę przekierowań, 

• skracamy czas otwierania strony, 

• zmniejszamy ryzyko utraty parametrów, 

• ułatwiamy Google sprawdzanie ceny i dostępności, 

• unikamy kierowania do ogólnych stron kategorii. 

Po uruchomieniu trzeba sprawdzić próbkę linków dla produktów prostych, wariantów, produktów promocyjnych, niedostępnych, wersji językowych i różnych walut. 

Cena, dostępność i dane strukturalne muszą być zgodne z feedem 

Zmiana platformy może wpłynąć na sposób obliczania cen, promocji, podatków i stanów magazynowych. 

Po migracji należy porównać dane przesyłane do Merchant Center z tym, co klient widzi na stronie: 

• cenę regularną, 

• cenę promocyjną, 

• walutę, 

• dostępność, 

• stan wariantu, 

• nazwę, 

• zdjęcie, 

• informacje o dostawie. 

Szczególną uwagę trzeba zwrócić na warianty. Reklama czerwonego produktu w rozmiarze M nie powinna prowadzić do karty, na której domyślnie wskazano kolor czarny i inną cenę. 

Remarketing, GA4 i pomiar zakupu 

Remarketing dynamiczny wykorzystuje identyfikator przesyłany ze strony, aby znaleźć odpowiadający mu produkt w feedzie. 

Po migracji należy sprawdzić, czy zdarzenia takie jak: 

• wyświetlenie produktu, 

• dodanie do koszyka, 

• rozpoczęcie zakupu, 

• zakup, 

wysyłają identyfikatory zgodne z Merchant Center. 

GA4 rejestruje produkty w tablicy items. Parametr item_id powinien pozostać spójny z przyjętym standardem identyfikacji. 

Jeżeli przed migracją produkt był raportowany jako SKU-123, a po migracji jako 98761, w raportach pojawią się dwie oddzielne pozycje. Technicznie pomiar może działać, ale ciągłość danych zostanie przerwana. 

Warto więc przyjąć jeden standard: 

SKU lub indeks ERP – Merchant Center id – GA4 item_id – Google Ads item id. 

Nowa platforma może również inaczej generować stronę potwierdzenia zamówienia i wywoływać zdarzenie zakupu. 

Przed uruchomieniem trzeba sprawdzić, czy do Google Ads i GA4 przesyłane są: 

• nazwa zdarzenia, 

• wartość zamówienia, 

• waluta, 

• identyfikator transakcji, 

• produkty, 

• ilości, 

• ceny, 

• kupony. 

transaction_id powinien być unikalny dla każdego zamówienia. Nie można wysyłać pustej wartości, tej samej wartości dla wszystkich zakupów ani innego numeru przy każdym ponownym otwarciu strony podziękowania. 

Google Tag Manager, warstwa danych i zgody 

Przeniesienie sklepu na nową platformę często zmienia: 

• strukturę HTML, 

• nazwy klas, 

• adresy stron, 

• sposób ładowania koszyka, 

• stronę podziękowania, 

• sposób przekazywania danych do dataLayer. 

Jeżeli tagi były uruchamiane na podstawie elementów starego szablonu, mogą przestać działać po zmianie wyglądu sklepu. 

Należy sprawdzić: 

• Google tag, 

• kontener Google Tag Manager, 

• identyfikatory GA4, 

• identyfikatory i etykiety konwersji Google Ads, 

• zdarzenia e-commerce, 

• remarketing, 

• konwersje rozszerzone, 

• zdarzenia formularzy, 

• działanie tagów po przejściu do operatora płatności. 

Lepszym rozwiązaniem jest oparcie pomiaru na uporządkowanej warstwie danych niż na odczytywaniu cen i nazw bezpośrednio z kodu strony. 

Nowy sklep może również otrzymać inny moduł zgód. Trzeba zweryfikować: 

• domyślne stany zgód, 

• aktualizację zgody po działaniu użytkownika, 

• blokowanie tagów, 

• działanie Google Consent Mode, 

• przekazywanie zgód do Google Ads i GA4, 

• zachowanie ustawień pomiędzy podstronami, 

• wersje językowe banera. 

Kampanie nie powinny być przebudowywane bez potrzeby 

Migracja sklepu nie oznacza automatycznie konieczności tworzenia wszystkich kampanii od początku. 

Sama migracja nie wymaga zmiany całej strategii reklamowej. Warto natomiast ponownie ocenić podział asortymentu i stosowane strategie Google Ads dla e-commerce, jeśli zmieniła się struktura katalogu lub oferta sklepu. 

Jeżeli zachowane zostaną: 

• konto Google Ads, 

• konto Merchant Center, 

• dotychczasowe kampanie, 

• identyfikatory produktów, 

• cele konwersji, 

• wartości konwersji, 

• struktura feedu, 

• parametry śledzenia, 

można ograniczyć zakres zmian i zachować ciągłość danych. 

Nowe kampanie mogą być potrzebne, jeśli zmienia się strategia reklamowa, kraje sprzedaży, asortyment albo podział produktów. Nie powinny jednak powstawać wyłącznie dlatego, że sklep działa na innej platformie. 

Z migracji powinna powstać mapa SEO i Google Ads 

Efektem analizy powinien być dokument łączący stare i nowe elementy. 

Taka mapa pozwala sprawdzić, czy zmiana platformy nie przerwała zależności pomiędzy katalogiem, reklamą, analityką i sprzedażą. 

Jak przeprowadzić przeniesienie sklepu internetowego bez utraty zamówień i nowych danych? 

Największe ryzyko w dniu uruchomienia dotyczy danych powstających pomiędzy ostatnim eksportem a przełączeniem domeny. 

Jeżeli stary sklep nadal przyjmuje zamówienia, baza użyta do budowy nowej wersji szybko staje się nieaktualna. 

Okno przełączenia 

Okno przełączenia to czas przeznaczony na: 

• ograniczenie zmian w starym sklepie, 

• końcowy eksport, 

• import różnic, 

• zmianę konfiguracji domeny, 

• uruchomienie integracji, 

• testy produkcyjne, 

• wznowienie sprzedaży. 

Termin powinien wynikać z danych o ruchu i zamówieniach. Dla sklepu B2B spokojniejszy może być weekend, a dla sklepu konsumenckiego środek nocy w dzień roboczy. 

Zamrożenie danych czy synchronizacja różnicowa? 

Najprostsze podejście zakłada chwilowe wyłączenie możliwości składania zamówień. 

Po aktywacji przerwy technicznej wykonywany jest: 

1. eksport końcowy, 

2. import nowych danych, 

3. kontrola zgodności, 

4. zmiana domeny, 

5. test zamówienia, 

6. wznowienie sprzedaży. 

Rozwiązanie ogranicza ryzyko rozbieżności, ale powoduje przerwę. 

W większych sklepach można przenieść jedynie dane utworzone lub zmienione po wcześniejszym imporcie. 

Mogą to być: 

• nowe zamówienia, 

• nowi klienci, 

• zmienione adresy, 

• ceny, 

• stany, 

• produkty, 

• rabaty, 

• zwroty. 

Synchronizacja różnicowa wymaga reguł rozstrzygających konflikty. Trzeba wiedzieć, co zrobić, gdy ten sam rekord został zmieniony w obu środowiskach. 

Runbook uruchomienia 

Dzień startu powinien być rozpisany krok po kroku. 

Każdy etap powinien mieć osobę odpowiedzialną i jednoznaczny warunek zakończenia. 

Kiedy podejmujemy decyzję o uruchomieniu sklepu? 

Przed rozpoczęciem prac trzeba ustalić kryteria go-live, czyli warunki pozwalające uruchomić nowy sklep. 

Mogą obejmować: 

• działa logowanie i reset hasła, 

• można przejść cały proces zakupowy, 

• płatność otrzymuje prawidłowy status, 

• zamówienie trafia do ERP, 

• ceny i stany są zgodne, 

• wiadomości transakcyjne dochodzą, 

• feed produktowy jest dostępny, 

• zdarzenie zakupu trafia do GA4 i Google Ads, 

• nie występują błędy blokujące realizację zamówień. 

Jeżeli jeden z procesów krytycznych nie działa, osoba decyzyjna powinna uruchomić plan powrotu albo świadomie zaakceptować start z określonym ograniczeniem. 

Plan powrotu 

Trzeba wcześniej ustalić, co wydarzy się, gdy w określonym czasie nie uda się usunąć poważnego błędu. 

Plan powinien opisywać: 

• kto podejmuje decyzję o powrocie, 

• po jakim czasie, 

• jak ponownie uruchomić stary sklep, 

• co zrobić z zamówieniami złożonymi w nowym, 

• jak odwrócić zmianę DNS, 

• jakie logi i dane zachować, 

• jak przygotować kolejne podejście. 

Plan awaryjny nie oznacza braku zaufania do projektu. Pozwala uniknąć improwizacji podczas problemu. 

Testy migracji powinny sprawdzać procesy, a nie tylko podstrony 

Sklep może poprawnie wyświetlać stronę główną, kategorie i produkty, a mimo to nie być gotowy do sprzedaży. Testy muszą przejść przez rzeczywiste procesy oraz ich wyjątki. 

Nie wystarczy sprawdzić, czy można otworzyć kartę produktu. Trzeba potwierdzić, że informacje są poprawne, koszyk działa, płatność otrzymuje właściwy status, zamówienie trafia do systemów zewnętrznych, a klient otrzymuje odpowiednią wiadomość. 

Testy katalogu 

Należy sprawdzić: 

• przypisanie produktów do kategorii, 

• warianty, 

• ceny, 

• promocje, 

• stawki VAT, 

• dostępność, 

• zdjęcia, 

• dokumenty, 

• filtry, 

• wyszukiwarkę, 

• produkty powiązane, 

• zestawy, 

• widoczność dla grup klientów. 

Testy powinny obejmować produkty reprezentujące różne przypadki, a nie kilka losowych pozycji. 

Testy zakupowe 

Warto przygotować scenariusze obejmujące: 

• zakup bez konta, 

• zakup po zalogowaniu, 

• rejestrację, 

• reset hasła, 

• kod rabatowy, 

• punkty lojalnościowe, 

• kartę podarunkową, 

• darmową dostawę, 

• przesyłkę zagraniczną, 

• pobranie, 

• płatność online, 

• płatność nieudaną, 

• ponowienie płatności, 

• zamówienie B2B, 

• limit kupiecki, 

• różne stawki VAT, 

• produkt bez stanu. 

Każdy przypadek powinien zostać sprawdzony od koszyka aż do systemu magazynowego i dokumentu sprzedaży. 

Testy integracji 

Nie wystarczy potwierdzić, że zamówienie dotarło do ERP. 

Trzeba sprawdzić: 

• zgodność produktów, 

• kwoty, 

• rabaty, 

• dostawę, 

• płatność, 

• adres, 

• dane firmy, 

• status, 

• numer przesyłki, 

• fakturę, 

• ponowienie po błędzie. 

Powinny istnieć również scenariusze negatywne, na przykład: 

• brak połączenia, 

• nierozpoznany produkt, 

• niepoprawny kod dostawy, 

• przekroczony limit, 

• brak stanu, 

• podwójne przesłanie zamówienia. 

Testy SEO i Google Ads 

Przed uruchomieniem trzeba porównać stary i nowy sklep oraz sprawdzić: 

• statusy HTTP, 

• tytuły, 

• nagłówki H1, 

• adresy kanoniczne, 

• oznaczenia hreflang, 

• indeksowalność, 

• dane strukturalne, 

• mapy XML, 

• linkowanie, 

• paginację, 

• filtry, 

• przekierowania, 

• obrazy, 

• pliki. 

W Google Ads i Merchant Center należy zweryfikować: 

• końcowe adresy URL, 

• linki do podstron, 

• szablony śledzenia, 

• identyfikatory produktów, 

• grupowanie wariantów, 

• ceny, 

• dostępność, 

• zdjęcia, 

• zgodność feedu ze stroną, 

• dynamiczny remarketing. 

Osobny test powinien sprawdzić, czy środowisko robocze nie zostało zaindeksowane. 

Testy analityki i zgód 

Należy zweryfikować rejestrowanie zdarzeń: 

• view_item, 

• add_to_cart, 

• view_cart, 

• begin_checkout, 

• add_shipping_info, 

• add_payment_info, 

• purchase. 

Dla zakupu trzeba porównać: 

• numer transakcji, 

• kwotę, 

• walutę, 

• produkty, 

• identyfikatory, 

• ilości, 

• kupony, 

• źródło ruchu. 

Trzeba również sprawdzić działanie mechanizmu zgód i zachowanie skryptów po odmowie oraz po zaakceptowaniu poszczególnych kategorii. 

Testy z udziałem pracowników 

Osoby, które na co dzień obsługują sklep, mogą zauważyć problemy niewidoczne dla zespołu wdrożeniowego. 

Warto zaprosić do testów: 

• obsługę klienta, 

• magazyn, 

• księgowość, 

• marketing, 

• handlowców, 

• osoby zarządzające katalogiem. 

Każda grupa powinna wykonać swoje codzienne zadania w nowym środowisku. 

Pierwsze 72 godziny po migracji sklepu internetowego 

Uruchomienie nie kończy procesu. Pierwsze godziny pokazują błędy, których nie udało się odtworzyć podczas testów. 

Monitoring powinien obejmować nie tylko dostępność strony, lecz także sprzedaż, integracje, SEO, Google Ads i procesy uruchamiane z opóźnieniem. 

Pierwsze cztery godziny 

Bezpośrednio po starcie trzeba sprawdzić: 

• działanie domeny, 

• certyfikat SSL, 

• przekierowania wersji domeny, 

• logowanie, 

• rejestrację, 

• reset hasła, 

• zakup mobilny, 

• płatność, 

• wiadomości transakcyjne, 

• przekazywanie zamówień do ERP, 

• stany, 

• etykiety, 

• analitykę, 

• logi aplikacji, 

• dostępność feedu, 

• rejestrowanie konwersji. 

Warto wykonać kilka prawdziwych płatności niewielkiej wartości, a następnie sprawdzić ich zwrot. 

Pierwsza doba 

Po kilku godzinach można analizować: 

• liczbę zamówień, 

• odrzucone płatności, 

• porzucone koszyki, 

• błędy formularzy, 

• nieprzesłane zamówienia, 

• błędne ceny, 

• produkty bez zdjęć, 

• zgłoszenia klientów, 

• błędy 404, 

• problemy z kuponami, 

• odrzucenia produktów w Merchant Center, 

• błędy stron docelowych, 

• liczbę zarejestrowanych konwersji. 

Dane należy porównywać z podobnym dniem tygodnia i uwzględnić sezonowość. 

Druga i trzecia doba 

W tym czasie ujawniają się procesy wykonywane cyklicznie: 

• nocne aktualizacje cen, 

• pełna synchronizacja stanów, 

• eksport faktur, 

• generowanie feedów, 

• automatyczne zmiany statusów, 

• przypomnienia, 

• raporty, 

• naliczanie punktów, 

• wygaszanie promocji, 

• eksporty do systemów reklamowych. 

Zadanie działające raz dziennie mogło nie zostać sprawdzone podczas krótkich testów przed uruchomieniem. 

Kolejne tygodnie 

Monitoring powinien objąć: 

• liczbę zaindeksowanych stron, 

• kliknięcia organiczne, 

• wyświetlenia, 

• błędy 404, 

• adresy wykluczone, 

• widoczność kategorii, 

• widoczność produktów, 

• aktywność robotów, 

• działanie mapy XML, 

• liczbę aktywnych produktów w Merchant Center, 

• liczbę kliknięć z reklam, 

• liczbę sesji po kliknięciu, 

• wartość konwersji, 

• współczynnik konwersji, 

• działanie remarketingu. 

Jeżeli liczba kliknięć Google Ads pozostaje podobna, ale liczba sesji spada, problem może dotyczyć adresów lub pomiaru. Jeżeli sesje są rejestrowane, ale znikają konwersje, trzeba sprawdzić zdarzenie zakupu. Jeżeli kampanie produktowe tracą zasięg, analizę warto rozpocząć od feedu i zgodności identyfikatorów. 

Nie należy oceniać efektu SEO na podstawie jednego lub dwóch dni. Ponowne przetworzenie większej liczby adresów wymaga czasu. 

Ile kosztuje migracja sklepu internetowego? 

Koszt migracji zależy bardziej od liczby zależności i procesów niż od samej liczby produktów. Sklep z dużym, ale prostym katalogiem może być łatwiejszy do przeniesienia niż mniejszy sklep z rozbudowaną platformą B2B, programem lojalnościowym i kilkunastoma integracjami. 

Migracja jest zazwyczaj jednym z elementów większego projektu, dlatego przy określaniu budżetu warto uwzględnić również pełny koszt wdrożenia PrestaShop, obejmujący projekt, development, integracje, testy i uruchomienie. 

Dlatego rzetelna wycena wymaga wcześniejszego poznania obecnego środowiska. 

Co wpływa na zakres prac? 

Największe znaczenie mają: 

• źródłowa i docelowa platforma, 

• jakość danych, 

• dostęp do bazy, 

• liczba typów produktów, 

• warianty, 

• zestawy, 

• historia zamówień, 

• konta klientów, 

• program lojalnościowy, 

• bony i kupony, 

• funkcje B2B, 

• liczba integracji, 

• niestandardowy kod, 

• wersje językowe, 

• zmiana domeny, 

• zakres SEO i Google Ads, 

• projekt interfejsu, 

• synchronizacja różnicowa, 

• dopuszczalna długość przerwy, 

• wymagany monitoring po starcie. 

Dlaczego liczba produktów nie wystarcza? 

Dwa sklepy posiadające po 20 000 produktów mogą wymagać zupełnie innego zakresu prac. 

W pierwszym przypadku dane mogą być uporządkowane i dostępne w jednym eksporcie. W drugim mogą występować: 

• niejednoznaczne warianty, 

• kilka cenników, 

• zestawy, 

• produkty konfigurowalne, 

• dokumenty, 

• wiele magazynów, 

• dane zapisane w dodatkowych modułach, 

• ręczne relacje z ERP. 

Pytanie o cenę migracji podane wyłącznie na podstawie liczby produktów nie daje więc wystarczających informacji. 

Jak przygotować się do wyceny? 

Warto zebrać: 

• adres sklepu, 

• nazwę i wersję platformy, 

• liczbę produktów i wariantów, 

• liczbę klientów, 

• liczbę zamówień, 

• listę integracji, 

• listę funkcji dodatkowych, 

• wymagania B2B, 

• kraje i języki, 

• informacje o ERP i PIM, 

• dostępne formaty eksportu, 

• termin uruchomienia, 

• dane o ruchu i sprzedaży, 

• informacje o Merchant Center i Google Ads. 

Po analizie można podzielić prace na dane, rozwój, integracje, SEO, Google Ads, testy i uruchomienie. 

Najczęstsze błędy podczas migracji sklepu internetowego 

Problemy po uruchomieniu często wynikają z pominięcia prostych zależności, a nie z jednego niezwykle skomplikowanego błędu. 

Kopiowanie wszystkich starych procesów 

Firma odtwarza każdą ręczną czynność bez sprawdzenia, dlaczego była potrzebna. Nowy sklep działa na nowej technologii, ale nadal wymaga tych samych arkuszy i obejść. 

Analiza wyłącznie panelu sklepu 

Pomijane są czynności wykonywane w ERP, skrzynce pocztowej, arkuszach i systemie magazynowym. Zakres nie obejmuje więc całego procesu sprzedaży. 

Brak końcowej synchronizacji 

Pełny import odbył się kilka tygodni wcześniej, ale nie przeniesiono nowych zamówień, kont i zmian powstałych do dnia uruchomienia. 

Nieprawidłowe mapowanie produktów 

Nowe identyfikatory nie odpowiadają numerom używanym przez ERP. Zamówienia trafiają do integracji, ale produkty nie są rozpoznawane. 

Przypadkowa zmiana identyfikatorów w feedzie 

Produkty otrzymują nowe identyfikatory, przez co Merchant Center, Google Ads i GA4 zaczynają traktować je jako nowe pozycje. 

Utrata punktów lub aktywnych bonów 

Przeniesiono konta klientów, ale pominięto korzyści zapisane w dodatkowych modułach. 

Przekierowanie całego starego sklepu na stronę główną 

Użytkownicy tracą dostęp do poszukiwanych treści, a wyszukiwarka nie otrzymuje informacji o rzeczywistych odpowiednikach stron. 

Pozostawiony noindex 

Sklep działa, lecz blokada przeniesiona ze środowiska testowego uniemożliwia jego indeksowanie. 

Testowanie tylko standardowego zamówienia 

Nie są sprawdzane zwroty, kody rabatowe, błędy płatności, zestawy, zamówienia B2B i integracje po awarii. 

Nieprzetestowane wiadomości transakcyjne 

Zamówienia są zapisywane, ale klient nie otrzymuje potwierdzenia, linku do płatności albo wiadomości potrzebnej do ustawienia nowego hasła. 

Brak logów i powiadomień 

Integracja przestaje przesyłać zamówienia, ale nikt nie otrzymuje informacji. Problem zostaje zauważony dopiero po kontakcie klienta. 

Brak kryteriów dopuszczenia do uruchomienia 

Zespół posiada listę zadań, ale nie ustalił, które błędy bezwzględnie blokują uruchomienie produkcyjne. 

Zbyt szybkie wyłączenie starego sklepu 

Brakuje dostępu do historycznych danych, zamówień, dokumentów i konfiguracji potrzebnych do wyjaśnienia rozbieżności. 

Brak osoby decyzyjnej w dniu startu 

Zespół wykrywa problem, ale nie wiadomo, kto może zaakceptować uruchomienie z ograniczeniem albo zdecydować o powrocie do starego środowiska. 

Najczęstsze pytania o przeniesienie sklepu internetowego 

Poniższe odpowiedzi porządkują kwestie, które najczęściej pojawiają się przed rozpoczęciem migracji. 

Czy podczas migracji warto porządkować katalog? 

Tak, ale według wcześniej ustalonych reguł. Zmiany powinny uwzględniać doświadczenie klientów, SEO, integracje i strukturę ERP. Chaotyczne usuwanie lub łączenie produktów może stworzyć więcej problemów niż korzyści. 

Czy można przenieść program lojalnościowy? 

Najczęściej tak, lecz trzeba sprawdzić, gdzie przechowywane są salda, historia, terminy ważności i poziomy uczestników. Nowy system może inaczej naliczać lub wykorzystywać punkty. 

Co zrobić, jeśli nie chcemy przenosić programu lojalnościowego? 

Trzeba ustalić dzień zakończenia naliczania punktów, termin wykorzystania salda oraz sposób komunikacji z klientami. Program nie powinien zostać wyłączony bez wcześniejszego rozliczenia korzyści przypisanych do kont. 

Czy klienci zachowają hasła? 

Zależy to od sposobu zabezpieczenia haseł w starej i nowej platformie. Gdy mechanizmy są niezgodne, trzeba przygotować proces ustawienia nowego hasła. 

Czy trzeba przenosić wszystkie zamówienia? 

Nie zawsze. Decyzja powinna uwzględniać potrzeby klienta, obsługi, księgowości, reklamacji i raportowania. Starsze dane mogą zostać w zabezpieczonym archiwum, jeśli nie muszą być dostępne w nowym panelu. 

Czy po migracji mogą spaść pozycje w Google? 

Mogą wystąpić czasowe wahania, zwłaszcza po zmianie adresów i struktury. Ryzyko ogranicza prawidłowa mapa URL, przekierowania, zachowanie treści, poprawne adresy kanoniczne i monitoring Google Search Console. 

Czy po migracji trzeba tworzyć kampanie Google Ads od początku? 

Nie. Jeżeli zostaną zachowane konta, kampanie, konwersje, identyfikatory produktów i struktura feedu, zwykle można kontynuować obecne działania. Trzeba jednak zaktualizować strony docelowe i przetestować pomiar. 

Czy identyfikatory produktów muszą pozostać takie same? 

Wewnętrzne numery w bazie nowego sklepu mogą się zmienić. Stabilne powinny pozostać identyfikatory przekazywane do Merchant Center, Google Ads i GA4 albo trzeba przygotować ich jednoznaczne mapowanie. 

Czy sklep musi zostać wyłączony? 

Nie zawsze. Można wykonać wcześniejszy import pełny i końcową synchronizację różnic. Krótka przerwa bywa jednak potrzebna, aby nie dopuścić do powstawania nowych zamówień podczas końcowego transferu. 

Jak długo trwa migracja sklepu internetowego? 

Termin zależy od danych, funkcji, integracji, projektu graficznego, testów i zakresu zmian procesowych. Sam import może być krótki, ale przygotowanie oraz sprawdzenie całego środowiska trwa znacznie dłużej. 

Czy trzeba zachować stary sklep? 

Takie środowisko warto przechowywać przez uzgodniony czas jako zabezpieczone archiwum. Może być potrzebne do sprawdzenia historii zamówień, zgód, dokumentów i wcześniejszej konfiguracji. 

Czy warto łączyć migrację ze zmianą procesów? 

Tak, ponieważ odtwarzanie wszystkich dawnych ograniczeń zmniejsza sens inwestycji. Zmiany procesowe powinny być jednak opisane, przetestowane i uzgodnione z osobami, które będą z nich korzystać. 

Zanim przeniesiesz sklep, zdecyduj, jak ma działać Twój e-commerce 

Migracja sklepu internetowego nie powinna kończyć się stworzeniem szybszej kopii starego systemu. To moment, w którym można uporządkować katalog, wskazać źródła danych, uprościć statusy, przebudować rabaty i usunąć ręczne czynności wynikające z dawnych ograniczeń. 

Najpierw trzeba jednak zrozumieć obecny sposób działania firmy. Dopiero później można zdecydować, co przenieść, co poprawić, a co zaprojektować od początku. 

Dobrze przygotowane przeniesienie sklepu internetowego łączy analizę procesów, migrację danych, rozwój platformy, integracje, SEO, Google Ads, testy i scenariusz uruchomienia. Każdy z tych obszarów powinien mieć opisany zakres, odpowiedzialność oraz sposób kontroli. 

W Webixa rozpoczynamy migrację od analizy obecnego sklepu, danych, procesów, integracji oraz ruchu z SEO i Google Ads. Efektem jest mapa funkcjonalna nowego środowiska, zakres danych do przeniesienia, plan integracji, lista ryzyk, harmonogram testów oraz scenariusz uruchomienia. 

Dzięki temu przed rozpoczęciem developmentu wiadomo, co zostaje zachowane, co będzie działać inaczej i które ograniczenia obecnego sklepu nie powinny trafić do nowej platformy. 

Realizujemy migracje sklepów na PrestaShop, obejmujące środowiska B2C, B2B oraz PrestaShop Multistore, a także integracje z ERP, PIM, CRM, Base i systemami logistycznymi. Prace mogą rozpocząć się od warsztatów, podczas których wspólnie rozpisujemy dane, procesy, integracje oraz wymagania nowego środowiska. 

Efektem nie powinien być wyłącznie nowy sklep. Powinien nim być uporządkowany system sprzedaży, który odpowiada temu, jak firma działa dzisiaj i w jakim kierunku chce się rozwijać.