Migracja z WooCommerce lub Shopify na własny sklep w Next.js: kiedy się opłaca, a kiedy nie

Pierwszym sygnałem jest liczba wtyczek utrzymujących funkcje, które powinny być częścią sklepu. Sklep z 34 aktywnymi wtyczkami w WooCommerce, z czego siedem dotyczy samego koszyka i wysyłki, ma już własny system, tylko złożony z cudzych części i bez testów. Każda aktualizacja WordPressa jest wtedy wydarzeniem, a nie rutyną.

Drugim sygnałem są koszty, których nikt nie sumuje. Shopify Plus przy 1,5 mln zł miesięcznego obrotu to około 2300 dolarów abonamentu, do tego zestaw aplikacji za 400-900 dolarów, prowizja bramki płatniczej i płatny motyw. Roczna suma potrafi przekroczyć 200 tys. zł, zanim doliczysz czas agencji poświęcony na obchodzenie limitów. To nie znaczy automatycznie, że własne będzie tańsze, ale znaczy, że porównanie ma sens.

Trzeci sygnał jest najtwardszy: masz w planach funkcję, której platforma nie zrobi. Konfigurator liczący cenę z ośmiu parametrów, ceny kontraktowe dla klientów B2B, system rezerwacji montażu, sprzedaż na wymiar. Jeśli zespół od pół roku odpowiada na te potrzeby zdaniem tego się nie da, to jest już koszt, tylko niewidoczny na fakturach.

Są co najmniej trzy różne rzeczy nazywane migracją na Next.js i różnią się kosztem o rząd wielkości. Pierwsza to frontend w Next.js na istniejącym backendzie: Shopify Storefront API albo WooCommerce przez REST lub GraphQL, z procesem zakupowym pozostawionym na platformie. Dostajesz szybkość i pełną kontrolę nad wyglądem oraz strukturą treści, nie ruszając najbardziej ryzykownej części systemu. Wdrożenie zajmuje zwykle 8-14 tygodni.

Druga to własny frontend plus silnik sprzedaży w postaci gotowej usługi, na przykład Medusa, Saleor albo commercetools. Tu przejmujesz koszyk i płatności, więc dochodzi integracja bramek, kurierów i podatków, ale nie piszesz katalogu ani zarządzania zamówieniami od zera. To najczęstszy sensowny punkt docelowy dla polskiego sklepu z obrotem 5-40 mln zł rocznie.

Trzecia to pełna aplikacja pisana pod konkretny model sprzedaży. Ma sens tam, gdzie sklep jest w istocie systemem: sprzedaż na wymiar, konfiguratory, złożone ceny B2B, integracja z produkcją. Kosztuje najwięcej i wymaga zespołu, który zostanie po wdrożeniu. Jeśli nie potrafisz wskazać osoby odpowiedzialnej za ten kod za dwa lata, wybierz jeden z wcześniejszych wariantów.

Proces zakupowy to nie jest formularz. To obsługa błędów bramki, ponowna próba płatności, częściowa dostępność magazynowa w momencie zapłaty, kody rabatowe wykluczające się wzajemnie, różne stawki VAT w jednym koszyku, wysyłka do paczkomatu z mapą i walidacja adresu. W projektach, które prowadziliśmy, sam checkout z pełną obsługą przypadków brzegowych to 25-35 procent budżetu wdrożenia.

Druga niedoszacowana warstwa to integracje operacyjne. Baselinker albo bezpośrednie połączenie z ERP, faktury, korekty, zwroty i wymiany, etykiety kurierskie, statusy przesyłek, synchronizacja stanów co kilka minut, obsługa zamówień telefonicznych. To rzadko wygląda efektownie na makiecie, a decyduje o tym, czy zespół obsługi klienta będzie mógł pracować po wdrożeniu.

Trzecia to wszystko, z czego korzysta marketing. Feed do Merchant Center z etykietami własnymi, warstwa danych dla analityki, integracja z platformą opinii, newsletter z segmentacją, strony landingowe edytowalne bez udziału deweloperów. Pominięcie ostatniego punktu jest częstym błędem i kończy się tym, że każda kampania wymaga wdrożenia produkcyjnego. Dlatego przy własnym sklepie prawie zawsze dokłada się headless CMS na treści.

Migracje psują się najczęściej na adresach. Zasada jest prosta: jeśli obecna struktura URL nie ma poważnej wady, zachowaj ją co do znaku. Zmiana schematu kategorii przy okazji przepisywania frontendu to dwie ryzykowne operacje naraz i przy spadku ruchu nie będziesz wiedzieć, która zawiniła. Jeśli musisz zmienić, przygotuj mapę jeden do jednego, a nie zbiorcze przekierowanie do strony głównej.

Przed wdrożeniem robimy pełny crawl starego sklepu Screaming Frogiem, eksportujemy wszystkie adresy odpowiadające kodem 200 i łączymy je z listą adresów generujących ruch, pobraną z Search Console i analityki za ostatnie 12 miesięcy. To jest lista kontrolna. Po wdrożeniu ten sam crawl na nowym sklepie musi pokazać dla każdego adresu albo 200, albo 301 do jednoznacznego odpowiednika.

Realistyczne oczekiwanie po dużej migracji to wahnięcie widoczności przez cztery do ośmiu tygodni, nawet przy poprawnie wykonanej pracy. Google musi przeindeksować całość, a przy sklepie z 30 tys. adresów to po prostu trwa. Wdrożenie w szczycie sezonu jest błędem, który kosztuje więcej niż cała migracja.

Przepisanie całego sklepu i przełączenie w jedną noc to najdroższy sposób na odkrycie, czego nie przewidziano. Lepiej działa podejście, w którym nowy frontend przejmuje ruch fragmentami: najpierw blog i strony informacyjne, potem karty produktu, potem listingi, a proces zakupowy zostaje na starym systemie do końca. Proxy na poziomie CDN kieruje ścieżki do właściwej aplikacji i z każdego kroku można się wycofać w minutę.

Przy przejmowaniu ruchu warto użyć podziału procentowego zamiast pełnego przełączenia. Dziesięć procent ruchu na nowe karty produktu przez trzy dni pokaże błędy, których nie wyłapał żaden test, i zrobi to na skali niezagrażającej przychodowi. Przy okazji dostajesz porównanie współczynnika konwersji między starą a nową wersją na tym samym ruchu, co bywa pouczające i nie zawsze przyjemne.

Przy obrocie poniżej mniej więcej 3 mln zł rocznie własny sklep zwykle nie zwraca się w horyzoncie trzech lat. Różnica w abonamentach nie pokryje kosztu wdrożenia i utrzymania, a uwaga zespołu przesunie się z marketingu na technologię. W tym przedziale więcej daje porządny motyw, uporządkowany feed, przyzwoita analityka i praca nad konwersją.

Odradzam także wtedy, gdy nie ma nikogo odpowiedzialnego za system po odbiorze. Własny sklep to zobowiązanie: aktualizacje zależności, monitoring, dyżury w szczytach sprzedażowych, poprawki po zmianach w API kurierów i bramek płatniczych. Jeśli plan kończy się na słowie wdrożymy, projekt będzie po osiemnastu miesiącach w gorszym stanie niż WooCommerce, od którego uciekałeś. Policz całkowity koszt na trzy lata razem z utrzymaniem i porównaj z sumą abonamentów, a decyzja zwykle staje się oczywista w jedną albo w drugą stronę.