Migracja sklepu z Shopera do PrestaShop – realizacja dla Śląskiego Centrum Komputerowego
DelkomTech przeniósł działający sklep Śląskiego Centrum Komputerowego z platformy Shoper na PrestaShop. Śląskie Centrum odpowiadało za sprzedaż i obsługę kupujących, a nasz zespół techniczny przygotował nowe środowisko, przeniósł dane i przeprowadził przełączenie. Oba zespoły działają w Delkom Group. Dla sklepu liczyło się przede wszystkim to, czy po zmianie klient nadal złoży i opłaci zamówienie, a obsługa będzie mogła wrócić do historii jego zakupów.
W piątek wieczorem przełączyliśmy sklep na PrestaShop pod dotychczasową domeną. W niedzielę rano, przed upływem 48 godzin od przełączenia, potwierdziliśmy działanie sprzedaży w zakupie kontrolnym z rzeczywistą płatnością. W kolejnych dniach audyt potwierdził również opłacone zamówienia klientów. Prace nad katalogiem, danymi i przekierowaniami rozpoczęły się wcześniej, dzięki czemu na weekend przypadło uruchomienie i sprawdzenie sprzedaży.
Co sklep zyskał po zmianie
| Obszar | Wynik projektu |
|---|---|
| Sprzedaż | Sklep zaczął działać na PrestaShop pod tą samą domeną. Zakup kontrolny potwierdził płatność, status zamówienia i powiadomienia. |
| Dane sklepu | Przenieśliśmy katalog ze zdjęciami, dane klientów i ponad tysiąc zamówień archiwalnych. Konta można było odzyskać przez ustawienie nowego hasła. |
| Dotychczasowe linki | W próbie przed startem sprawdziliśmy 1 959 przekierowań 301 ze starych adresów do ich odpowiedników w PrestaShop. |
| Ceny i stany | Przed otwarciem sklepu uzgodniliśmy ceny i stany z Subiektem, aby kupujący korzystali z aktualnych danych sprzedażowych. |
Ten projekt pokazuje, jak przygotować zmianę platformy w działającym sklepie, gdy dane trzeba zebrać z kilku eksportów, historia zakupów ma być nadal użyteczna, a nowe zamówienia muszą przejść pełną ścieżkę od koszyka do potwierdzenia płatności.
Jak odzyskaliśmy dane z Shopera
Osobne eksporty zamiast jednego obrazu sklepu
W konfiguracji źródłowej używanej w tym projekcie nie mieliśmy do dyspozycji pełnej kopii bazy sklepu Shoper, którą można byłoby pobrać i odtworzyć u siebie. Korzystaliśmy z osobnych eksportów produktów, klientów i zamówień. Każdy miał własny zestaw pól. W jednym z wcześniejszych eksportów zamówień dostępny był m.in. numer, data, suma i status, a do odtworzenia zakupów potrzebne były jeszcze pozycje i powiązania z klientami. Sięgnęliśmy po kolejny, rozszerzony eksport.
Znaczenie miał nawet filtr daty. Widok zamówień mógł domyślnie obejmować bieżący dzień, więc przed pobraniem trzeba było sprawdzić zakres. Po odebraniu pliku weryfikowaliśmy kolumny i liczbę rekordów. Dzięki temu można było wychwycić sytuację, w której eksport technicznie się zakończył, ale obejmował tylko fragment historii.
Dlaczego pobieraliśmy dane ponownie
Sklep przyjmował zamówienia, gdy przygotowywaliśmy PrestaShop. Między odczytami pojawiały się nowe rekordy, a towar zmieniał cenę lub dostępność. Zachowywaliśmy wyniki kolejnych pobrań i porównywaliśmy je z aktualnym stanem sklepu docelowego. Produkty rozpoznawaliśmy po SKU, klientów po znormalizowanym adresie e-mail, a zamówienia po identyfikatorze źródłowym. Te klucze pozwoliły dopisać nowe rekordy i wyłapać różnice przed aktualizacją istniejących.
Ostatni import zamówień objął końcową partię ze starego sklepu. Po zapisie sprawdziliśmy także wcześniejsze rekordy, żeby potwierdzić, że ponowny przebieg zachował zaimportowaną historię. Przy cenach i stanach końcowym źródłem był Subiekt. To ważne, gdy eksport katalogu i faktyczny stan magazynu pochodzą z różnych momentów.
Katalog produktów i warianty
Przy jednym z porównań pozorny brak ponad stu pozycji okazał się różnicą w sposobie liczenia wariantów usługi dodatkowej. Eksport Shopera ujmował je w osobnych wierszach, a identyfikatory bazowych produktów były już w PrestaShop. Taką różnicę trzeba wyjaśnić przed importem. Gdyby każdy wiersz potraktować jako samodzielny towar, część wariantów pojawiłaby się w sklepie jako osobne produkty.
Klienci i historia zamówień
Jak kupujący odzyskiwali dostęp do kont
Przenieśliśmy dane kont objęte migracją i przygotowaliśmy w PrestaShop ścieżkę odzyskania dostępu. Klient używał dotychczasowego adresu e-mail. Sklep wysyłał link, przez który klient ustawiał nowe hasło. Zespół Śląskiego Centrum miał prostą instrukcję, którą mógł przekazać kupującym przy uruchomieniu sklepu.
W eksporcie mogą występować także zakupy gościnne. Dla historii zamówień trzeba zachować powiązanie z nabywcą, a dostęp do zarejestrowanego konta obsłużyć zgodnie z jego stanem. Zgody marketingowe są osobną informacją. Samo przeniesienie rekordu lub ustawienie nowego hasła nie zastępuje zgody.
Jak zachowaliśmy starsze zakupy
Historia obejmowała również produkty wycofane ze sprzedaży. Przy takim zamówieniu ważne są nazwa towaru, ilość, cena i powiązanie z kupującym. Zachowaliśmy te informacje w archiwum zamówień także wtedy, gdy historyczny SKU nie miał pewnego odpowiednika w bieżącym katalogu. Obsługa może dzięki temu wrócić do dokumentacji zakupu bez odtwarzania wycofanego produktu jako aktywnej oferty.
Import historii nie uruchamiał wysyłki, powiadomień, ponownego wystawienia faktury ani zmiany stanów. Oryginalny status i informację o opłaceniu przenosiliśmy w zakresie dostępnych danych. Pełna historia zmian statusów, faktury i identyfikatory transakcji nie wynikały z użytych plików eksportowych. Rekordy z niepoprawnymi danymi odkładaliśmy do wyjaśnienia, a niejednoznacznych pól nie uzupełnialiśmy na podstawie domysłów.
Co porównywaliśmy po imporcie
| Sprawdzany element | Co daje taka kontrola |
|---|---|
| Identyfikator źródłowy | Kolejne pobranie nie tworzy drugiej kopii tego samego zamówienia. |
| Kwota i pozycje | Obsługa widzi, za co i w jakiej ilości zapłacił klient, nawet jeśli produkt zniknął z aktualnej oferty. |
| Powiązanie z nabywcą | Historię można odszukać przy obsłudze klienta i wyjaśnianiu spraw dotyczących starszych zakupów. |
Przełączenie i powrót sprzedaży
Co przygotowaliśmy przed przełączeniem sklepu
Nowy sklep działał na osobnym środowisku przez okres przygotowań. Rozwijaliśmy katalog, koszyk, dostawy i płatności, zanim skierowaliśmy na niego ruch z dotychczasowej domeny. Przed przełączeniem wykonaliśmy kopię PrestaShop, przeprowadziliśmy ostatni import zamówień oraz zweryfikowaliśmy zapis cen i stanów z Subiekta. Wcześniejsze przygotowanie tych elementów ograniczyło zakres prac w oknie przełączenia.
Jak sprawdziliśmy sprzedaż po starcie
| Moment | Co potwierdził odczyt |
|---|---|
| 23 października wieczorem | Ruch z dotychczasowej domeny trafił do PrestaShop. Kontrola po przełączeniu potwierdziła aktywny sklep, płatności, dostawy i pocztę sklepową w konfiguracji produkcyjnej. |
| 25 października rano | Zakup kontrolny przeszedł przez Przelewy24. Operator potwierdził płatność, sklep zapisał status opłacenia i wysłał wiadomości związane z zamówieniem i płatnością. |
| Kolejne dni | Audyt potwierdził opłacone zamówienia złożone przez klientów. Jedno z nich pozwoliło prześledzić osobno utworzenie zamówienia i późniejsze potwierdzenie operatora płatności. |
Zakup kontrolny dał odpowiedź na praktyczne pytanie zespołu handlowego: czy po wejściu na stronę kupujący może zamówić produkt, wybrać dostawę i zapłacić, a zespół otrzyma poprawny status. Czas do tej próby liczymy od zmiany platformy pod publiczną domeną. Przygotowanie eksportów, katalogu, kont i nowego sklepu było osobnym etapem projektu.
Jak zadbaliśmy o wejścia ze starych linków
Zachowaliśmy domenę, a poprzednie adresy produktów, kategorii i treści powiązaliśmy z odpowiednikami w PrestaShop. Przed startem sprawdziliśmy 1 959 przekierowań i odpowiedzi stron docelowych. Dzięki mapie przekierowań kupujący korzystający z zakładki lub starego linku mieli trafić na właściwą stronę. Taka kontrola dotyczy działania adresów. Widoczność w Google sprawdza się po przełączeniu w raportach indeksowania i skuteczności.
Jak DelkomTech prowadzi migrację sklepu
Każdy sklep ma własną kombinację danych, płatności, dostaw i integracji. Zakres ustalamy na podstawie tego, jak sprzedawca pracuje dziś i jak ma obsługiwać zamówienia po zmianie. W projekcie Śląskiego Centrum najwięcej dały próbne importy, jasne zasady porównywania kolejnych eksportów oraz oddzielny odbiór sprzedaży po przełączeniu.
Co ustalamy przed rozpoczęciem
| Etap | Decyzja lub wynik |
|---|---|
| Audyt źródła | Sprawdzamy możliwość pobrania katalogu, klientów, zamówień i mediów oraz ustalamy, które dane wymagają dodatkowego odczytu. |
| Próbna migracja | Odtwarzamy przykładowe produkty i zamówienia. Rozliczamy warianty, powiązania z klientami i wyjątki, zanim uzgodnimy import całości. |
| Odbiór sklepu | Sprawdzamy zakup od koszyka po potwierdzenie płatności, typowe formy dostawy i odzyskanie dostępu do konta. |
| Przełączenie | Ustalamy termin, ostatnie pobranie danych, źródło stanów magazynowych i weryfikację najważniejszych adresów. |
| Kontrola po starcie | Sprawdzamy rzeczywiste zamówienia, statusy płatności i komunikację. Na tej podstawie ustalamy dalsze prace nad sprzedażą i integracjami. |
Jak sprawdzić, czy sklep jest gotowy do przełączenia?
Przygotuj próbkę odpowiadającą codziennej pracy sklepu. Uwzględnij produkt z wariantami, zamówienie gościnne, zamówienie z historią płatności i stare zamówienie potrzebne przy reklamacji. Po imporcie sprawdź, czy obsługa może znaleźć te rekordy i powiązać je z właściwymi produktami lub klientem.
Na dzień przełączenia ustal, kto porówna ostatni eksport z nowym sklepem i kto odbierze pierwsze rzeczywiste zamówienie. Po starcie porównaj status płatności, wiadomość do klienta i stan magazynowy. Dzięki temu można szybko wskazać etap, na którym pojawiła się rozbieżność.
Porozmawiajmy o Twojej migracji
Jeśli planujesz przejście z Shopera na PrestaShop, opisz wielkość katalogu, metody płatności i dostawy, okres historii potrzebny obsłudze oraz używany system magazynowy. Ustalimy dostęp do danych i zaplanujemy dzień przełączenia wokół tego, kiedy sklep musi przyjmować zamówienia.
Omów migrację swojego sklepu z DelkomTech