Migracja na Shopify krok po kroku: plan, dane, testy i start sklepu

Rozmowa z premierą 9 maja 2023, więc opis funkcji Shopify odpowiada stanowi z tamtego czasu: Shopify Scripts zostały od tego czasu wycofane (zastąpiły je Shopify Functions), aplikacji Transporter do importu historii zamówień nie ma już w dokumentacji Shopify, a od marca 2025 Shopify Payments działa w Polsce, także z BLIK-iem, więc argument o lepszym dopasowaniu do polskiego rynku jest dziś słabszy. Dziś do migracji danych używamy własnego systemu wspieranego przez AI, który przenosi dane szybciej i bezpieczniej.

Kiedy rodzi się pomysł na migrację sklepu?

Tomek: Cześć! Dzisiaj zapraszam was do odcinka, w którym podejmiemy się obszernego tematu, jakim jest migracja sklepu. Skupimy się oczywiście na migracji na Shopify, niemniej sam proces jest dość uniwersalny, niezależnie od technologii. Postaramy się powiedzieć wam, jak uniknąć błędów i pomyłek oraz jak ograniczyć ryzyko związane z tym procesem. Zapraszamy. Cześć, Maćku.

Maciek: Cześć, Tomku.

Tomek: Temat duży, obszerny, niełatwy, ale spróbujmy się z nim zmierzyć. Będzie to oczywiście rozmowa o migracji na Shopify. Może zacznijmy od tego, skąd w ogóle pomysł na migrację? Kiedy taki pomysł rodzi się w głowach właścicieli sklepów?

Maciek: Jasne. Zanim do tego dojdziemy, zrobię jeden wstęp. Mówimy o procesie migracji na Shopify, ale ten proces jest na tyle ogólny, że metody, o których będziemy mówili, pozwolą przeprowadzić migrację z dowolnego systemu na dowolny. Są uniwersalne i myślę, że taki framework migracji jest wszędzie bardzo podobny.

Tomek: Dobrze, zastanówmy się w takim razie, w którym momencie rodzi się ta myśl, czym może być spowodowana i kiedy właściciel decyduje się na tak duży krok w swoim biznesie?

Maciek: Pierwsza sprawa to zdecydowanie ograniczenia technologiczne starej platformy. Chodzi o różne problemy z tym, jak ta platforma działa: czas realizacji poszczególnych funkcjonalności, koszty wdrożeń, problemy z działaniem poszczególnych procesów. Słowem, wraz z rozwojem biznesu naturalnie wyrastamy z platformy, na której byliśmy, albo po prostu chcemy odejść od platform przestarzałych technologicznie.

Tomek: Dodałbym, że rozwój biznesu często wiąże się z wyjściem za granicę, na rynki europejskie czy światowe, a platforma nie przystaje do tych potrzeb, bo klient pierwotnie wybrał rozwiązanie typowo polskie, żeby działać na rynku polskim. Biznes urósł, właściciel ma plany rozwoju i szuka rozwiązania bardziej skalowalnego. To porównanie do wyrośnięcia z obecnego rozwiązania chyba najlepiej oddaje ten punkt zapalny, w którym zaczynasz myśleć o migracji.

Maciek: To kwestia potrzeb. Opowiadamy tu o migracji na Shopify, ale znamy też przypadki, gdy klienci wycofywali się z Shopify i szli do Shopera, bo pod pewnymi względami to rozwiązanie jest lepiej dopasowane do rynku polskiego.

Dlaczego migracja uchodzi za trudną i ryzykowną?

Tomek: Zastanówmy się, skąd w ogóle postrzeganie tego procesu jako bardzo trudnego, skomplikowanego i wymagającego sporego przygotowania.

Maciek: Przede wszystkim to proces obarczony dużym ryzykiem. Bardzo wiele rzeczy może po drodze pójść nie tak. To niezwykle stresujące doświadczenie dla osób zaangażowanych w ten proces, zwłaszcza po stronie klienta.

Tomek: Tak, bo wymieniamy im podstawowe narzędzie, na którym pracowali przez dłuższy czas, na coś, czego być może nie znają i co na pewno ma ogromny wpływ na ich biznes.

Maciek: Warto rozwinąć tę myśl, bo wiele systemów e-commerce ma strukturę monolityczną. Stanowią całość, są w sercu ekosystemu i wszystkie narzędzia są podłączone do tego jednego centralnego systemu. Kiedy go wyciągamy, musimy wszystkie rzeczy dookoła wpiąć w nowy system. Rozwiązaniem w przyszłości może być zastąpienie architektury monolitycznej architekturą potocznie nazywaną composable commerce. To relatywnie nowy termin, a oznacza podejście do projektowania systemów e-commerce, w którym dobierasz narzędzia jak klocki i układasz z nich potrzebne procesy. Jeżeli chcesz wymienić jedną rzecz, powiedzmy, że masz Magento i nie podoba ci się, jak działa zarządzanie jakimś procesem, to nie musisz wymieniać całego Magento, tylko wyciągasz jeden klocek i zastępujesz go rozwiązaniem, które ci pasuje. Na przykład wyszukiwarkę.

Co może pójść nie tak w migracji?

Tomek: To zapytajmy przewrotnie: co może pójść nie tak w takiej migracji?

Maciek: Tak jak przy przeszczepie serca. Może pójść nie tak wszystko.

Tomek: Moim zdaniem właściciele e-commerce'ów najbardziej obawiają się tego, że odpinamy coś, co do tej pory jakoś działało, wpinamy coś nowego, a moment przepięcia czy uruchomienia nowego systemu może przerwać cały proces biznesowy. Ciągłość biznesowa może zostać zachwiana, a w e-commerce zależy nam na tym…

Maciek: …żeby nie było jak w tym legendarnym urzędzie, który miał stronę czynną od 8:30 do 15:30, w godzinach pracy urzędu, a później nie działała.

Tomek: Dokładnie. W e-commerce klienci mają trochę więcej swobody w dostępie do sklepu. Przede wszystkim bałbym się, że to, co do tej pory działało, przestanie działać. Przerywam proces biznesowy, a to wprost wpływa na wyniki sprzedaży.

Maciek: Absolutnie. Albo wysypie się wszystko i nic nie będzie działać, albo posypią się pojedyncze procesy, które też są krytyczne. Na przykład zwroty, jeśli są zrealizowane w inny sposób, albo wyszukiwanie, filtrowanie, integracje z poszczególnymi narzędziami czy realizacja zamówień.

Tomek: Do tego miejmy na uwadze, że duża część biznesów opiera swój model na bardzo konkretnej funkcjonalności. Na przykład na modelu subskrypcyjnym: budują lojalność, przywiązują użytkowników do produktu i sklepu, mają powtarzalne zakupy. Wyobraźmy sobie, że po migracji ta kluczowa funkcjonalność z jakiegoś powodu przestanie działać albo nie działa tak dobrze jak wcześniej. To bardzo prosta droga do porażki i naprawdę dużych strat.

Maciek: Jasne.

Tomek: Z mojej perspektywy to są największe obawy: że stanie się coś złego z moim biznesem, a to, co jakoś działało i do czego byłem przyzwyczajony, nagle przestanie działać i nie będę wiedział, co dalej.

Maciek: Kolejnym problemem może być utrata części danych. To też realne ryzyko. Zabezpieczeniem jest oczywiście backup i utrzymywanie sklepu produkcyjnego jak najdłużej, nawet przez jakiś czas po starcie nowego systemu, dopóki nie upewnimy się, że wszystko jest w porządku i stary system nie jest już potrzebny. Kluczowe jest też odpowiednie podejście do migracji danych.

Kiedy zacząć, żeby zdążyć przed Black Friday?

Tomek: Ja dołożę jeszcze zły timing. Migracja trwa najczęściej kilka miesięcy, a w rocznym cyklu e-commerce są konkretne wydarzenia, na przykład Black Friday i Cyber Monday, czyli momenty, kiedy sprzedaż jest najwyższa i biznes najwięcej zarabia.

Maciek: Taki niezrozumiały fenomen.

Tomek: Tak, niezrozumiały fenomen. Jestem w stanie sobie wyobrazić, że migracja na nową platformę przeciągnie się za bardzo i okaże się, że w ogóle nie zdążymy…

Maciek: Mam wrażenie, że to nie jest kwestia tego, że się przeciągnie, tylko że po prostu za późno się zacznie.

Tomek: Albo za późno się zacznie. Brak świadomości, ile ten proces będzie trwał, powoduje, że na dużą akcję sprzedażową będziemy totalnie nieprzygotowani, bo będziemy mieli nowy system, którego jeszcze dobrze nie znamy i który nie będzie przetestowany.

Maciek: Dokładnie. To jeden z kluczowych problemów.

Tomek: Obawy i ryzyko będą wtedy potężne. A druga sprawa: zwyczajnie nie wyrobimy się z nowym sklepem i zostaniemy przy tym, co mieliśmy. Włożyliśmy dużo wysiłku w stworzenie czegoś nowego, a nie możemy się tym pochwalić.

Maciek: To chyba największa przestroga: dajcie sobie czas, żeby zrobić to dobrze. Kiedy czasu jest mało, pracuje się pod presją, w nerwach, w stresie, w pośpiechu i dochodzi do przeoczeń. Stąd biorą się problemy, o których mówiliśmy.

Tomek: Tip dla właścicieli sklepów, którzy myślą o dużej migracji i chcą się wyrobić przed szalonym okresem listopadowym: najlepszy moment, żeby zacząć prace nad migracją, to pierwszy kwartał roku.

Maciek: Planowanie launchu nowego sklepu na dzień czy tydzień przed szczytem sezonu to proszenie się o problemy.

SEO, nowe systemy i inne ryzyka

Tomek: Dokładnie tak. Maćku, powiedziałbym jeszcze o czymś, o czym przy migracji myśli się rzadziej, bo to mniej sprawa stricte biznesowa, a bardziej techniczna: o utracie pozycji SEO.

Maciek: Okej.

Tomek: Naprawdę duża część sklepów buduje swoją pozycję w wyszukiwarce, a budowanie jej w sposób naturalny trwa miesiące, wręcz lata. Może pojawić się poważna obawa, że przy migracji kwestie SEO nie zostaną wystarczająco zaopiekowane. I nagle czeka nas bardzo niemiła niespodzianka: pozycja sklepu spada o kilkadziesiąt miejsc i lądujemy na drugiej, trzeciej stronie wyników. To się bardzo prosto przekłada na biznes, bo spadają obroty.

Maciek: Nie polecam.

Tomek: Nie polecam. Tych obaw wymienilibyśmy pewnie jeszcze sporo. Co więcej, każdy właściciel e-commerce'u ma swoje. Jak powiedziałeś, procesy są często bardzo unikalne: własny system kodów rabatowych, nawet powiadomienia, które obsługują sferę customer experience.

Maciek: Tak mi się przypomniało: bardzo często migracja na inną platformę wiąże się z dołączaniem nowych narzędzi. Możemy przy okazji wprowadzać ERP, PIM czy inne narzędzia. Te wdrożenia mogą się na siebie nałożyć albo rozjechać w czasie, co może skomplikować zaplanowany proces. Dlatego warto dobrze ułożyć kolejność tych działań.

Jak ograniczyć ryzyko migracji?

Tomek: Przejdźmy w takim razie do pytania, co zrobić, żeby uniknąć tych błędów. Za chwilę o tym powiemy: nie wszystko da się przewidzieć, ale na pewno da się zminimalizować ryzyko i obawy związane z procesem. Jakieś kluczowe rady, Maćku?

Maciek: Dla mnie w planowaniu takiego procesu najważniejsze jest posiadanie planu migracji i postępowanie zgodnie ze sprawdzonymi regułami, procedurami czy wypracowanymi checklistami. Tak przynajmniej robimy my w agencji. Oczywiście migrację można przeprowadzić wewnętrznym zespołem. Praca z partnerem, który ma doświadczenie w takim procesie, minimalizuje jednak ryzyko, bo ty ze swoim zespołem zrobisz taką migrację może kilka razy w całym cyklu życia firmy, a sprawdzony partner robi to kilkanaście, kilkadziesiąt razy w roku, więc ma wypracowane metody. To możemy polecić, chociaż jesteśmy stronniczy.

Tomek: Podsumowując: pracować według sprawdzonego procesu, mieć konkretną metodę i konkretny plan działania.

Maciek: Tak.

Tomek: I dobrze wspierać się specjalistami, którzy mają w tym więcej doświadczenia. W takim razie spróbujmy opowiedzieć, jak organizujemy plan i proces migracji w naszej agencji przy klasycznym przypadku klienta, który chce się do nas przenieść. Jak wyglądają poszczególne kroki? Myślę, że to będzie fajna wiedza dla wszystkich, żeby zobaczyć, w jakiej kolejności…

Maciek: …i można to spokojnie powtórzyć, pracując ze swoim zespołem.

Tomek: Dokładnie.

Etap discovery: warsztaty technologiczne i UX

Maciek: Polecamy ten sposób pracy. My zawsze zaczynamy od warsztatów, scoping session. Z jednej strony mają zbadać stan zastany, czyli gdzie jesteśmy i gdzie chcemy być, a z drugiej nakreślić plan, jak dojść z punktu A do punktu B.

Tomek: Rozwińmy, co wchodzi w skład tego etapu, który nazywamy u nas discovery, czyli etapem poznawania biznesu. Celem jest to, żebyśmy zarówno my, jak i klient dobrze zidentyfikowali obecne rozwiązanie i cały ekosystem, w którym ono funkcjonuje. E-commerce jest często jednym z elementów całego systemu do obsługi sprzedaży, produkcji, działań marketingowych i tak dalej. Dlatego warsztaty dzielimy na dwa obszary. Pierwszy to warsztaty stricte technologiczne i identyfikacja procesów, które występują u klienta zarówno po stronie e-commerce'u, jak i systemów dodatkowych tworzących cały ekosystem. Te procesy musimy potem zmapować, czyli odwzorować w nowej strukturze, którą zaproponujemy.

Maciek: Dokładnie.

Tomek: Jak powiedziałeś: ustalamy cel, miejsce, w którym jesteśmy, miejsce, w którym chcemy być, i to, co jest pomiędzy, czyli tak zwaną analizę gap. Jakie mamy luki w procesach i w biznesie i jak powinny je zaadresować nasze rozwiązania. To część technologiczna. Warto jednak dodać, że migracja sklepu to bardzo dobry moment, żeby zastanowić się nad warstwą wizualną i user experience klientów. Dlatego w fazie discovery często prowadzimy drugi typ warsztatów, poświęcony biznesowi i jego odbiorcom. Może warto to rozwinąć.

Maciek: Zazwyczaj ta operacja jest na tyle rozciągnięta w czasie i skomplikowana, że rzadko zdarza się, żeby ktoś nie wziął się też za ten etap. To dobry moment na redesign. Elementem warsztatów UX-owych w discovery dla e-commerce jest badanie tego, co do tej pory dobrze działało w serwisie i jakie nawyki zakupowe mają klienci. Obserwujemy zachowania, patrzymy na dane jakościowe i ilościowe. W trakcie researchu śledzimy zachowania użytkowników narzędziami typu Hotjar i przeglądamy statystyki. To ważne choćby po to, żeby wiedzieć, skąd do nas trafia ruch, na jakie strony, czy to ruch mobilny, czy desktopowy. Jest dużo rzeczy do zbadania. Można też dołożyć audyt obecnego systemu, który pozwoli wyłapać podstawowe błędy i później je zaadresować. Pewnie będziemy się nad tym rozwodzić w kolejnych odcinkach. Rzadko jednak klient decyduje się przenieść sklep z frontem jeden do jednego. Mieliśmy takie scenariusze i tak naprawdę jedyną różnicą był nowy checkout. Swoją drogą opowiadaliśmy chyba o tym, że konwersje skoczyły wtedy dwukrotnie.

Raport, zakres i roadmapa

Tomek: Wróćmy do procesu i idźmy krok dalej. Przeprowadzamy warsztaty, a ich wynikiem jest najczęściej raport, w którym spisujemy wszystkie spostrzeżenia i wyniki prac i ćwiczeń. Niezwykle istotne jest to, że mamy wtedy ustalony właściwy zakres pracy.

Maciek: Z jednej strony zakres, a z drugiej roadmapę: w jakiej kolejności rzeczy powinny się dziać, co robimy teraz, a co będzie się działo po wdrożeniu.

Tomek: Tak. Ten etap daje klientowi dużo pewności, bo wie dokładnie, czego się spodziewać, jakie kroki są przed nim, które zadania będą wymagały jego uwagi albo działań, a które zaopiekujemy my. Jasna wizja i przejrzysty obraz tego, co chcemy zrealizować w kolejnych krokach.

Maciek: Często po tym etapie jesteśmy w stanie przedstawić dokładniejszą estymację, ale to kwestia poboczna. Czy przeprowadzenie tego etapu pozwala wyeliminować wszystkie niedopatrzenia i ryzyka?

Tomek: Zdecydowanie nie. Nie będę specjalnie odkrywczy: e-commerce i cały ekosystem to bardzo złożony proces i na pewno w trakcie prac wyskoczą niespodziewane sytuacje czy nieprzewidziane przeszkody. Ważne jest to, że taki raport i warsztaty minimalizują ryzyko, bo na początku identyfikujemy tyle obszarów, ile się da.

Maciek: Nie zdarzyło nam się, żeby któryś klient powiedział po czasie: „Słuchajcie, chłopaki, zapomnieliśmy zrobić checkoutu”. Ale zdarzają się sytuacje, gdy ktoś mówi: „Kurczę, zapomnieliśmy, że reklamujemy się w takiej sieci albo że jesteśmy zintegrowani z jakimś marketplace'em”.

Tomek: Zgadza się.

Maciek: Bo umknęło gdzieś na…

Tomek: …na etapie rozpoznania. Dokładnie tak.

Pierwsze kroki: konfiguracja środowiska Shopify

Tomek: Mamy więc discovery za sobą i przystępujemy do prac. Jak w przypadku Shopify wyglądają pierwsze kroki? Od czego zaczynamy?

Maciek: Jak mówiłeś, możemy ruszyć z kilkoma etapami równolegle. Mogą trwać prace projektowe, może trwać stawianie środowiska deweloperskiego, a jak tylko ono będzie gotowe, od razu mogą ruszyć prace związane z importem produktów. Przepraszam, z importem danych.

Tomek: Dokładnie tak. Chciałbym, żebyśmy rozwinęli te obszary. Co do konfiguracji środowiska, ważna informacja w przypadku Shopify: tworząc je na samym początku, od razu dajemy klientowi dostęp do docelowego środowiska, na którym będzie pracował. Dzięki temu poznaje, jak ono działa, i może się go nauczyć.

Maciek: Jest czas na zaznajomienie się z nim i nie są potrzebne późniejsze szkolenia po wdrożeniu.

Tomek: Tak. Szkolenie dedykowane pod klienta prowadzimy zawsze przed uruchomieniem. Ale panel nie jest dla niego nowy w momencie szkolenia, bo może na nim pracować przez cały proces migracji, co ma duże znaczenie przy przesiadce na coś zupełnie nowego. Na etapie konfiguracji może tylko wylistujmy, co robimy, bo nasze procesy migracji opieramy na bardzo dokładnych checklistach, nawet najmniejszych zadań na danym etapie. Tych zadań jest tak dużo, że bardzo łatwo zapomnieć o najbardziej podstawowych, a z punktu widzenia biznesu są równie istotne. Dlatego korzystamy z checklist, które sobie stworzyliśmy.

Maciek: Dokładnie. Żeby pokazać, jak szczegółowo rozpisany może być nawet tak prosty krok jak postawienie środowiska, możemy opowiedzieć, co robimy, stawiając sklep na Shopify.

Tomek: Jasne. Po kolei. Zaczynamy od sprawdzenia, czy nowo utworzony sklep ma ustawione hasło dostępu, tak żeby w fazie developmentu nikt się do niego nie dostał. Następnie podajemy dane właściciela, dane firmowe, konfigurujemy adresy firmy, która jest właścicielem sklepu, i dane do rozliczeń z Shopify. Potem przechodzimy do konfiguracji bramek płatniczych. Przy okazji umożliwiamy ich testowanie przez konta sandboxowe, żeby przetestować te procesy w fazie testów. Ustawienia podatków, ustawienia…

Maciek: …płatności, stref dostawy…

Tomek: …stref dostawy, czyli kurierów. Następnie od razu dodajemy listę osób, które będą miały dostęp do sklepu. Właśnie po to, o czym mówiliśmy: żeby od samego początku mogły poznawać to środowisko i się go uczyć. Co jeszcze? Adresy e-mail, z których sklep będzie prowadził komunikację. Tu można rozwinąć kwestię wpisów w domenie pod kątem Shopify.

Maciek: Tak, dokładnie. Trzeba dodać do domeny rekord SPF, czyli rekord tekstowy, który informuje, że Shopify może w naszym imieniu wysyłać maile z naszego adresu, i dzięki temu nie lądują one w spamie.

Tomek: Jasne.

Maciek: Niuans, ale istotny.

Tomek: Niuans istotny. Podajemy tę listę w komplecie właśnie po to, żeby uzmysłowić, ile drobnych elementów tej układanki jest potrzebnych. Na koniec polityki prywatności i regulaminy. To również możemy dodać na samym początku.

Maciek: Zgadza się.

Design: gotowy szablon czy projekt od zera?

Tomek: To idziemy dalej. Mamy dwa etapy, które możemy prowadzić i najczęściej prowadzimy równolegle. Z jednej strony praca nad warstwą graficzną nowego sklepu, a za chwilę powiemy, jak w przypadku Shopify wygląda ten krok. Z drugiej, jak mówiliśmy, od razu zajmujemy się importem danych. Też rozwiniemy, jakich danych i w jakiej kolejności, bo to ma znaczenie.

Maciek: Pierwszy temat jest w miarę prosty, drugi bardziej rozbudowany. Szybko więc o designie. Mamy dwa podejścia. Możemy pracować na gotowym szablonie, który dostosujemy, ale tego podejścia nie polecamy. Raczej rekomendujemy projektowanie interfejsu od zera.

Tomek: A dlaczego? Możesz rozwinąć?

Maciek: Nasze doświadczenie pokazuje, że serwisy zaprojektowane pod twojego użytkownika osiągają lepsze współczynniki konwersji. Oszczędność, którą masz, pracując na gotowym szablonie, jest więc pozorna. Druga sprawa: często są po prostu szybsze.

Tomek: Czyli wydajność rozwiązań customowych jest lepsza. Myślę, że tu możemy postawić kropkę.

Jakie dane migrować i w jakiej kolejności?

Tomek: Przejdźmy do migracji danych. Po pierwsze: o jakich danych myślimy, mówiąc o migracji? Po drugie: dlaczego ważne jest zachowanie właściwej kolejności?

Maciek: Przede wszystkim trzeba się zastanowić, które dane chcemy, możemy i powinniśmy zmigrować. Pierwsza sprawa to import produktów, w następnej kolejności klientów, ale też zamówień. To trzy podstawowe grupy danych. Są też inne rzeczy, na przykład treści, które musimy przenieść: wpisy na blogu, strony tekstowe, może kody rabatowe, choćby rzeczy dotyczące SEO.

Tomek: Jasne.

Maciek: A kolejność jest następująca: najpierw produkty, później klienci, na koniec zamówienia, żebyśmy w historii zamówień mogli wskazać powiązania między klientami a produktami. Dzięki temu mamy historię zamówień klienta, widzimy, co kupował, i możemy prowadzić lepszą analitykę.

Tomek: Dodałbym, dlaczego zależy nam na tym, żeby produkty migrować w pierwszej kolejności. Bo wtedy zarówno w fazie projektowej, jak i przede wszystkim deweloperskiej pracujemy od razu na realnych danych. Nie musimy mockować ani symulować przykładowego produktu. Pamiętajmy, że różne produkty mają różne atrybuty i cechy: inaczej na stronach produktowych prezentują się zabawki, inaczej elektronarzędzia, a jeszcze inaczej moda. Zaimportowanie produktów na początku ułatwia prace deweloperskie, a jak powiedziałeś, pozwala też później powiązać klientów z produktami i daje informacje o historii zamówień.

Dlaczego import produktów potrafi trwać tygodniami?

Maciek: Warto wspomnieć, że „import produktów” brzmi bardzo niewinnie, a często jest to całkiem złożony proces, który w zależności od struktury i liczby danych może trwać tygodniami.

Tomek: Dlaczego? Z jakiego powodu?

Maciek: Powodów jest kilka. Po pierwsze, każda platforma ma swoją określoną strukturę danych. Powiedzmy, że masz produkty przedstawione w tabeli i na przykład warianty produktu w kolumnach. Możesz mieć różne pola opisujące produkt, ułożone inaczej niż na platformie docelowej.

Tomek: Czyli dostosowanie struktury danych to często dość duże wyzwanie.

Maciek: Dokładnie. Chyba że masz PIM, czyli system do zarządzania informacją o produkcie. Wtedy jest to relatywnie proste i bezbolesne. Jeżeli nie masz systemu PIM, często masz problem. Shopify ma oczywiście narzędzia do migracji z najpopularniejszych platform, z Magento czy z WooCommerce, ale nie wszyscy są na tych systemach. Bardzo często migrujemy z innych. Można próbować ręcznie modyfikować pliki CSV. Są narzędzia, które pomagają w mapowaniu, na przykład Matrixify, szczególnie polecany. Można też migrować dane przez API. Zarówno modyfikowanie plików CSV, jak i praca z API często wymaga jednak napisania skryptu, który przekształci jedną strukturę danych w drugą. Potem lecimy z importem i na tym etapie też często wychodzą niedociągnięcia: coś trzeba poprawić, coś się zgubiło, o czymś zapomnieliśmy. I to trwa.

Klienci, historia zamówień, treści i rabaty

Tomek: Zdecydowanie czynnikiem, który wpływa na poziom skomplikowania, jest skala. Im więcej produktów, tym większa baza i tym bardziej zaawansowanego rozwiązania wymaga. Przy małej bazie i niewielkiej liczbie produktów często wystarczy nawet wprowadzić je ręcznie do nowego systemu. Im większa skala, tym bardziej trzeba sięgnąć po rozwiązanie automatyczne. Podobnie jest z klientami. Tu również mamy pliki CSV, które możemy importować do Shopify, ale mają one swoją strukturę, często inną niż struktura pliku źródłowego. Trzeba więc przekonwertować jedną strukturę na drugą, żeby dało się je zaimportować.

Tomek: Co do historii zamówień, powiedzmy, co jest możliwe w Shopify i na jakich zasadach. Ogólna reguła jest taka, że historię zamówień domyślnie, natywnie pozwala zaimportować dopiero plan Shopify Plus. Można do tego użyć aplikacji Transporter, która pozwoli zaciągnąć historię zamówień. Ona też nie jest kompatybilna z każdym systemem, z którego importujemy, więc często trzeba dodatkowo przygotować dane. To w przypadku Shopify Plus. W pozostałych planach nie ma klasycznego wbudowanego importu, nawet przycisk jest tam po prostu nieaktywny. Z pomocą przychodzą aplikacje, na przykład wspomniany Matrixify, który pozwala zaimportować te dane. Znowu trzeba się jednak liczyć z tym, że będzie to wymagało przygotowania danych, opracowania ich w tej aplikacji i skorzystania z płatnej aplikacji, jaką jest Matrixify.

Tomek: To są kluczowe dane. Pamiętajmy jednak, że do zmigrowania często są też strony typowo contentowe, na przykład wpisy na blogu z obecnego serwisu. Jeżeli mieliśmy na stronie kody rabatowe i całą politykę z nimi związaną, musimy się zastanowić, jak odwzorować to w Shopify. Trzeba mieć świadomość, że przy zniżkach i kodach rabatowych, czyli rozwiązaniach trochę odstających od standardu sprzedaży, każdy system ma własną logikę. Możemy nie tyle zderzyć się ze ścianą, ile napotkać trudności w odwzorowaniu ich jeden do jednego. Import często sprowadza się więc do tego, że musimy je fizycznie odtworzyć w Shopify albo trochę zmodyfikować, tak żeby model biznesowy został jak najlepiej zachowany. W przypadku Shopify Plus, o którym mówiliśmy ostatnio, z pomocą przychodzi Shopify Scripts, które pozwalają dodatkowo rozszerzyć funkcjonalność zniżek.

Czym jest migracja delta?

Tomek: Ostatnia rzecz, ale wcale nie najmniej ważna, jeśli chodzi o migrację danych, to pojęcie delta migration. Powiedz, Maćku, co się pod nim kryje.

Maciek: Jeśli dane importujemy na początku albo w trakcie procesu, trzeba pamiętać, że jest duża szansa, że część z nich od momentu importu do momentu launchu się zdezaktualizuje. Dlatego tuż przed launchem trzeba wykonać tak zwaną migrację delta. Być może nie zmienią ci się produkty, bo masz stały asortyment, ale na pewno mogli przybyć nowi klienci, mogły pojawić się nowe zamówienia i bez wątpienia zmieniły się stany magazynowe.

Tomek: Jasne.

Maciek: Trzeba więc po prostu zaktualizować dane, żeby te wprowadzone do systemu były aktualne. Nie „jak najbardziej aktualne”, tylko aktualne.

Tomek: Aktualne. Z tym bywa różnie, bo jeśli ktoś ma bardzo dużo transakcji, dane zmieniają się co godzinę i trudno odwzorować ten idealny moment na żywo. Ale im bliżej, tym lepiej.

Maciek: Migrację delta najlepiej zrobić wtedy, gdy wyłączamy sklep produkcyjny i przełączamy go na czas migracji w tryb utrzymaniowy.

Development i integracje

Tomek: Idźmy dalej. Dane mamy zmigrowane, projekt szaty graficznej również jest za nami. Dochodzimy do fazy twardego developmentu, który dzielimy na front-end i back-end i który może się dziać równolegle.

Maciek: Back-end może wystartować wcześniej, bo bardzo często dotyczy integracji z różnymi systemami, z którymi musimy spiąć nasze narzędzia. Front-end musi poczekać przynajmniej na część designu, zanim będziemy mogli ruszyć.

Tomek: Podalibyśmy jakieś konkretne przykłady tych integracji? Co najczęściej się integruje?

Maciek: Na przykład chcesz zintegrować sklep z platformą, która dostarcza wideo, albo włączyć Algolię, czyli silnik wyszukiwania, albo zintegrować Klaviyo czy Gorgiasa, czyli inne narzędzia do różnych obszarów e-commerce: marketingu, obsługi klienta, lojalności. Albo ERP, albo równolegle leci integracja z customowym PIM-em czy systemem magazynowym.

Tomek: Czyli wszystkie systemy, o których mówiliśmy wcześniej i które wchodzą w skład ekosystemu sprzedażowego. To moment, w którym się je integruje.

Maciek: A korzyścią z wcześniejszego zaimportowania danych jest to, że możemy sprawdzać, jak…

Tomek: …jak przebiega wymiana danych. Na razie powiedzieliśmy bardzo ogólnie, jakie systemy się integruje, ale nasz proces oczywiście identyfikuje te obszary i systemy. Kolejnym zagadnieniem jest ustawienie narzędzi marketingowych, czyli ich integracja i konfiguracja. Z jednej strony mamy na myśli kanały sprzedaży w social mediach, czyli integrację z Google, Facebookiem, Instagramem, z kanałami, w których biznes sprzedaje albo chce sprzedawać. Bo jak mówiliśmy na początku, może z warsztatów wyniknie, że dopiero chcemy otworzyć te kanały, a w Shopify będą one dostępne. Dalej klasyczne systemy CRM, które wspierają działania marketingowe. Wymieniłbym HubSpot i pewnie Salesforce.

Maciek: edrone.

Tomek: edrone, chociażby nasz polski, jak najbardziej. Czyli systemy, w których prowadzimy komunikację z klientami, reklamy, newslettery.

Maciek: Trzeba dodać, że z integracją CRM-ów czy narzędzi działających na froncie często trzeba poczekać, aż kodowanie frontu będzie gotowe. Choćby dlatego, że automatyzacje marketingowe bardzo często dzieją się w określonych miejscach witryny.

Tomek: Jak najbardziej. Mamy więc zaopiekowane narzędzia marketingowe, zintegrowaliśmy ERP, jeśli występuje w naszej konfiguracji, i wydaje się, że mamy już całkiem gotowe rozwiązanie. Czy to moment, w którym decydujemy się na uruchomienie? Startujemy ze sklepem? Czy coś trzeba zrobić wcześniej?

Testy przed wdrożeniem

Maciek: Nie polecam. Zanim do tego dojdzie, wchodzimy w krytyczną fazę testów przedwdrożeniowych, które pomogą wyłapać wszystkie ewentualne niedociągnięcia.

Tomek: Byłoby wskazane, żebyśmy powiedzieli, jak wygląda nasza checklista testów przedwdrożeniowych: co badamy, co testujemy, dlaczego to robimy i dlaczego to istotne. Chcesz zacząć?

Maciek: Mogę zacząć. Zacząłbym od testów krytycznych ścieżek w e-commerce, czyli czy działa proces zakupowy. Trzeba przetestować ścieżkę użytkownika od strony głównej przez listing, stronę produktu i koszyk po checkout. Mówimy też o testach przeglądarkowych, czy działają wszystkie funkcjonalności. Ruch przychodzi z różnych źródeł i z różnych przeglądarek, więc wszystko musi być przetestowane. Dalej testujemy transakcje: czy działają wszystkie bramki płatnicze i wszystkie metody dostawy. Mówimy zarówno o transakcjach zrealizowanych, jak i o tych, które zakończyły się niepowodzeniem. O tym też trzeba pamiętać: co się dzieje, gdy coś po drodze się wysypie, i jak to obsłużyć. To często zapomniany obszar.

Tomek: Dołożyłbym do tego jedną rzecz. Wspomniałeś o wszystkim, co dzieje się na froncie, czego klient jest świadkiem i czego będzie doświadczał. Równolegle musimy przetestować, co dzieje się z zamówieniami, które spływają do sklepu: jak są przesyłane dalej do systemów zajmujących się fulfillmentem, czy trafiają do CRM-u i ERP-a. Musimy sprawdzić, czy biznes po stronie backendu również działa zgodnie z oczekiwaniami.

Maciek: Czyli realizacja zamówienia, anulowanie zamówienia, zwroty.

Tomek: Tak, dokładnie. Dołożyłbym jeszcze sprawdzenie, jak wysyłane są powiadomienia do klienta.

Maciek: Częściowe zamówienia.

Tomek: Częściowe zamówienia, zapisy do newslettera. Czyli zarówno kwestie stricte biznesowe, jak i marketingowe, okołobiznesowe.

SEO przy migracji: od warsztatów do testów

Tomek: Tu warto też wspomnieć o SEO, o którym mówiliśmy na początku jako o obszarze czasem zaniedbywanym albo niewystarczająco zaopiekowanym. Zawsze rekomendujemy, żeby agencja SEO albo osoby odpowiedzialne za SEO po stronie klienta wzięły udział w naszych warsztatach, szczególnie technologicznych, gdy mapujemy procesy. Dla nas pozycjonowanie i pozycja sklepu w Google to element kluczowy, biznesowy.

Maciek: Mieliśmy przypadek klienta, który był super entuzjastycznie nastawiony do rozwiązania, i mieliśmy warsztaty kick-offowe, które miały rozpocząć współpracę. Temat się wysypał, bo agencja SEO miała bardzo konkretne wymagania co do struktury linków, a po przejściu na Shopify ta struktura musiała być wtedy nowa. Dałoby się tego uniknąć przy podejściu headless, ale tam były inne wymagania i temat się o to rozbił.

Tomek: Zgadzam się, pamiętam dokładnie. Chodziło o linki, które powstają przy filtrowaniu. Dość unikalne wymaganie, ale pokazuje, że w niektórych biznesach to niezwykle istotne.

Maciek: Jeżeli masz ruch generowany głównie z SEO. Czasami to nie jest problem: mamy masę biznesów, które jadą na performance, sprzedają w płatnych kampaniach w social mediach i w ogóle nie stawiają na SEO.

Tomek: Niemniej w fazie testów chcemy odnieść się również do SEO: sprawdzić opisy, tytuły, alty, czy nie ma broken linków, przekierowania 301 krytyczne dla sklepu. Jest tego całkiem sporo i to też moment, w którym często prosimy o wsparcie agencję, która się tym zajmuje, żeby zrobiła testy po swojej stronie i sprawdziła, czy wszystko odpowiada jej oczekiwaniom. To ostatni moment, w którym możemy przynajmniej część rzeczy zmodyfikować i dostosować do tych wymagań. Jak widzicie, testów jest sporo, ale to wciąż nie znaczy, że jesteśmy w stu procentach pewni, że sklep jest idealny. Ostateczną weryfikacją, o czym za chwilę powiemy, jest puszczenie go na żywo, ale jesteśmy na nią dużo lepiej przygotowani.

Kiedy uruchomić nowy sklep, a kiedy tego nie robić?

Tomek: Doszliśmy do ostatniego etapu, czyli planowania uruchomienia sklepu. Zastanówmy się, Maćku, kiedy to robić albo przewrotnie: kiedy tego nie robić.

Maciek: To zawsze super stresujące przeżycie dla founderów i managerów e-commerce. Moment kulminacyjny, emocje często są duże. Najlepiej robić to wtedy, kiedy w sklepie jest najmniejszy ruch, więc warto poczekać.

Tomek: Czyli pierwsza sprawa: analiza statystyk sklepu i ustalenie, w jakich dniach i godzinach ruch jest najmniejszy.

Maciek: Dokładnie. Najczęściej jest to późny wieczór. Zdarzało nam się przeprowadzać takie migracje często nawet po północy.

Tomek: A co do dnia: weekend? Z reguły to czas, kiedy ruch jest najmniejszy.

Maciek: Super pomysł robić to w weekend, tylko gorzej, jeśli nie będziesz mieć wtedy wsparcia.

Tomek: Jasne. Czyli róbmy to owszem wtedy, kiedy ruch jest najmniejszy, ale…

Maciek: …nie róbmy tego w piątek.

Tomek: Nie róbmy tego w piątek ani w weekend. Wtedy mamy pewność, że choćby następnego dnia z samego rana możemy liczyć na wsparcie developera czy agencji, która nam pomagała, gdyby pojawiły się błędy.

Maciek: My oferujemy klientom tak zwany hypercare, czyli okres kilku tygodni po wdrożeniu, kiedy jesteśmy w pogotowiu na wypadek, gdyby coś się działo. To działa bardzo uspokajająco.

Tomek: Tak. Kiedy klienci dopytują, co będzie potem i na jakie wsparcie mogą liczyć, często podkreślam jedną rzecz, istotną z punktu widzenia samego Shopify. Jeśli mówimy o nieoczekiwanych błędach krytycznych, których moglibyśmy się spodziewać po uruchomieniu, to Shopify robi bardzo dużo, żeby ich nie było. W e-commerce naprawdę krytyczne są błędy, które przerywają proces zakupowy i podstawowe działanie sklepu. A o to Shopify dba przez swój checkout. Poziom stresu i ryzyka jest więc na pewno dużo niższy.

Maciek: Tu się zgodzę. Chociaż jak sobie teraz przypominam różne sytuacje, to z perspektywy czasu wydają się śmieszne, ale w momencie przepięcia często takie nie są.

Przepięcie domeny i pierwsze godziny po starcie

Tomek: A samo przepięcie? Musimy mieć świadomość, że domena zostaje ta sama, ale zmienia się sklep, który obsługuje ruch i serwuje treści. Ile to może trwać?

Maciek: W teorii czas propagacji domeny, czyli poinformowania wszystkich serwerów, że ten adres wskazuje teraz na nowy numer IP, może wynosić nawet do 24 godzin. W praktyce to godzina, maksymalnie dwie, zanim adres się rozpropaguje.

Tomek: Czyli relatywnie krótko.

Maciek: Często jest taki okres, że ty wpisujesz adres i widzisz stary sklep, a ktoś inny już widzi nowy, i to są niepotrzebne nerwy. A to naturalny…

Tomek: …naturalny proces.

Maciek: Dokładnie.

Tomek: Czy w takim razie po uruchomieniu sklepu możemy spokojnie usiąść i cieszyć się nowym rozwiązaniem? Czy jednak…

Maciek: Zazwyczaj ludzie idą wtedy spać, a rano bardzo szybko wstają i sprawdzają, czy wszystko dalej działa. Oczywiście trzeba sprawdzić krytyczne rzeczy. Po pierwsze, czy działają parametry biznesowe: czy dalej spływają zamówienia, czy ruch przychodzi z kanałów, które mieliśmy zachować. Możemy podpiąć narzędzia analityczne, na przykład Hotjar, który pokaże zachowania użytkowników i pomoże wyłapać błędy, których nie złapaliśmy na etapie testów. Możemy też zaglądać do analityki i sprawdzać, czy nie pojawiły się strony błędów albo linki do nieistniejących stron, które nam umknęły. I jeszcze jedna krytyczna rzecz: trzeba sprawdzić wymianę danych między systemami. Wszystko to robiliśmy wcześniej, więc w 99,99% to działa.

Tomek: Nazwałbym to czujnością po uruchomieniu. Wystartowaliśmy z nowym systemem, więc monitorujmy wskaźniki i metryki, czy nie ma odchyleń albo wyników, które w jakikolwiek sposób odstają od tego, co obserwowaliśmy do tej pory. I monitorujmy warstwę back-endową, biznesową: czy dane nie są zaburzone.

Po co utrzymywać stary sklep po migracji?

Maciek: Dokładnie. I pamiętajmy, że w razie czego cały czas mamy stary sklep. Możemy na chwilę przywrócić na niego ruch z domeny, zależnie od tego, jak poważna jest sytuacja w nowym. Takie sytuacje zdarzają się jednak bardzo rzadko. Nie przypominam sobie, żebyśmy kiedykolwiek musieli się cofać.

Tomek: Takiej sytuacji nie mieliśmy. Ale to, co podkreślałeś na początku, czyli utrzymywanie starego środowiska przez jakiś czas po uruchomieniu nowego, na pewno daje tu poczucie bezpieczeństwa na wypadek czegokolwiek.

Maciek: Choćby po to, żeby sprawdzić w starym systemie archiwalne zamówienia, kody rabatowe czy naliczenia. Różne rzeczy mamy tam po prostu porozrzucane.

Tomek: Tym bardziej że klienci, którzy widzą nowy sklep, też się go uczą i czasem zgłaszają się do właściciela albo do helpdesku z pytaniami, gdzie znajdą funkcje, które były wcześniej.

Maciek: „A jak zrobić to, bo tutaj robiliśmy to tak”.

Tomek: Dokładnie tak. Dobrze jest wtedy móc podejrzeć, jak to wyglądało w poprzednim rozwiązaniu, żeby szybko odpowiedzieć na pytanie.

Podsumowanie: sprawdzony proces zamiast stresu

Tomek: Maćku, myślę, że udało nam się dopłynąć do brzegu z tym procesem. Chwilę to zajęło. Jak widzieliście, cały proces jest dość kompleksowy, obejmuje wiele obszarów i ważne jest, żeby trzymać się tej struktury. Może więc podsumowanie i rada dla osób, które myślą o migracji, trochę się jej obawiają albo zastanawiają się, jak do niej podejść.

Maciek: Konkluzją może być myśl, że przestrzeganie sprawdzonych procesów i procedur pozwoli zminimalizować ryzyko i zapewni, że proces będzie poukładany i przemyślany, a przechodząc przez niego, będziecie mieli poczucie, że jest po prostu bezpieczny. Bo największą obawą przy migracji jest chyba właśnie ryzyko, a z nim pojawia się dużo wątpliwości, obaw, stresu i nerwów. Przez to często też pomyłek.

Tomek: Świetne podsumowanie, Maćku. Bardzo ci dziękuję za kolejną wspólną rozmowę i wspólny odcinek. Wam również bardzo dziękuję. Mam nadzieję, że udało nam się przekazać kilka cennych rad, jak podejść do migracji sklepu, jak uniknąć błędów i zminimalizować związane z nią ryzyko. Wielkie dzięki za dzisiaj i zapraszamy na kolejne odcinki.