Migracja WooCommerce - projekt koncepcyjny sklepu z 1000 produktów i historią zamówień

Założenie projektu

To projekt koncepcyjny migracji działającego sklepu WooCommerce z katalogiem około 1000 produktów oraz historią zamówień. Zakres obejmuje nie tylko przeniesienie rekordów z jednej bazy do drugiej, ale też zachowanie ciągłości sprzedaży, obsługi klienta, integracji, analityki i widoczności w Google.

Migracja może dotyczyć przejścia z innej platformy do WooCommerce, przeniesienia pomiędzy dwiema instalacjami WordPressa albo gruntownej przebudowy istniejącego sklepu. W każdym wariancie najważniejsze są dane, proces przełączenia oraz możliwość wycofania zmiany, jeśli kontrola po publikacji wykaże problem.

Ten materiał nie opisuje wykonanej migracji konkretnego klienta. Pokazuje zakres techniczny i organizacyjny, który możemy dopasować po sprawdzeniu systemu źródłowego, dodatków, wolumenu danych oraz integracji.

Dlaczego migracja sklepu jest projektem, a nie importem CSV

Produkty są tylko jednym z wielu obszarów. Działający sklep łączy katalog, klientów, zamówienia, płatności, wysyłki, faktury, kupony, treści, zdjęcia i adresy indeksowane przez wyszukiwarki. Każdy z tych elementów może mieć inne identyfikatory i reguły na platformie docelowej.

Prosty import często pomija:

• warianty oraz relacje pomiędzy produktem głównym i odmianami,
• atrybuty używane do filtrowania,
• ceny regularne, promocyjne i reguły podatkowe,
• stany magazynowe oraz rezerwacje wynikające z otwartych zamówień,
• zdjęcia, kolejność galerii i teksty alternatywne,
• konta klientów i przypisanie wcześniejszych zamówień,
• statusy płatności, dostawy, zwrotów i reklamacji,
• kupony, punkty lojalnościowe i subskrypcje,
• metadane tworzone przez dodatki,
• przekierowania ze starych adresów.

Dlatego przed wyceną potrzebny jest audyt danych i procesów. Liczba produktów pomaga oszacować skalę, ale nie mówi jeszcze, czy każdy produkt ma jeden prosty rekord, czy kilkadziesiąt wariantów oraz zależności z zewnętrznym magazynem.

Inwentaryzacja systemu źródłowego

Pierwszy etap rozpoczyna się od kopii danych i listy elementów, które mają trafić do nowego sklepu. Nie pracujemy bezpośrednio na jedynym środowisku produkcyjnym.

Inwentaryzacja obejmuje:

• wersję platformy i bazę danych,
• katalog produktów, wariantów, kategorii, marek i atrybutów,
• klientów, adresy i zgody marketingowe,
• zamówienia wraz z pozycjami, podatkami, płatnościami i wysyłkami,
• media, dokumenty i pliki do pobrania,
• wpisy, poradniki i strony informacyjne,
• opinie o produktach,
• aktywne kupony, karty podarunkowe lub program lojalnościowy,
• dodatki zapisujące własne dane w zamówieniach i produktach,
• integracje z ERP, księgowością, kurierami, płatnościami oraz marketplace'ami,
• adresy URL, które otrzymują ruch organiczny lub linki zewnętrzne.

Wynikiem jest macierz migracji. Dla każdego typu danych określa źródło, pole docelowe, regułę przekształcenia, sposób walidacji oraz decyzję dotyczącą elementów, których nie warto przenosić.

Produkty i warianty

Katalog około 1000 produktów można przenieść automatycznie, ale skrypt musi uwzględniać strukturę danych. Podstawowym identyfikatorem biznesowym jest zwykle SKU. Jeżeli sklep źródłowy nie ma stabilnych SKU albo powtarza je pomiędzy wariantami, najpierw trzeba ustalić regułę identyfikacji.

Zakres danych produktowych może zawierać:

• nazwę, slug i pełny opis,
• krótki opis używany na listach,
• SKU, EAN i identyfikator producenta,
• cenę regularną, promocyjną i harmonogram promocji,
• stawkę podatku oraz klasę podatkową,
• stan, status dostępności i sposób zarządzania magazynem,
• wagę, wymiary i klasę wysyłkową,
• warianty, atrybuty i wartości filtrów,
• kategorie, tagi i marki,
• zdjęcie główne, galerię oraz teksty alternatywne,
• produkty powiązane, akcesoria i sprzedaż dodatkową,
• pliki cyfrowe oraz zasady dostępu,
• pola niestandardowe wykorzystywane przez motyw i dodatki,
• tytuł SEO, opis i adres kanoniczny, jeśli są przechowywane w źródle.

Po imporcie liczymy rekordy i porównujemy próbki z różnych grup. Sam zgodny wynik liczbowy nie wystarcza. Trzeba sprawdzić produkty proste, wariantowe, promocyjne, niedostępne, cyfrowe oraz zawierające nietypowe pola.

Klienci i konta

Przeniesienie klientów wymaga szczególnej ostrożności. Zakres danych powinien być ograniczony do informacji potrzebnych w nowym sklepie, a podstawy prawne i obowiązki informacyjne muszą zostać sprawdzone przez właściciela danych.

Koncepcja uwzględnia:

• konto i dane kontaktowe klienta,
• adres rozliczeniowy oraz wysyłkowy,
• przypisanie zamówień do właściwej osoby,
• role B2B i indywidualne ustawienia, jeśli występują,
• zgodę marketingową wraz ze źródłem i datą, o ile dane źródłowe pozwalają ją udokumentować,
• bezpieczny proces ustawienia nowego hasła.

Haseł nie należy kopiować jako zwykłego tekstu. Jeżeli format skrótów jest niezgodny z nowym systemem, klient otrzymuje bezpieczną ścieżkę ustawienia hasła przy pierwszym logowaniu.

Historia zamówień

Historia zamówień jest potrzebna klientom, księgowości i obsłudze. Po migracji użytkownik powinien widzieć wcześniejsze zakupy, a pracownik sklepu musi być w stanie odtworzyć cenę, podatek, płatność, dostawę i status z momentu złożenia zamówienia.

Mapowanie może obejmować:

• numer i datę zamówienia,
• konto klienta albo zamówienie gościnne,
• pozycje, warianty, ilości i ceny historyczne,
• rabaty, kupony, dostawę oraz opłaty dodatkowe,
• stawki i kwoty podatków,
• metodę i status płatności,
• metodę wysyłki, numer przesyłki i status realizacji,
• notatki klienta oraz bezpiecznie wybrane notatki wewnętrzne,
• zwroty i korekty,
• identyfikatory dokumentów księgowych, jeżeli są potrzebne do dalszej obsługi.

Nie uruchamiamy ponownie automatycznych wiadomości dla historycznych rekordów. Import powinien oznaczać zamówienia w sposób odróżniający je od nowych transakcji, aby webhooki, fakturowanie i integracje nie przetworzyły ich po raz drugi.

Media i pliki

Przeniesienie zdjęć wymaga pobrania oryginałów, sprawdzenia dostępności oraz przypisania do właściwych produktów. Nie warto kopiować wielu nieużywanych rozmiarów wygenerowanych przez poprzedni motyw.

Proces może obejmować:

• listę wszystkich aktywnie używanych plików,
• kontrolę błędnych lub zewnętrznych adresów,
• pobranie oryginałów,
• zmianę nazw tylko wtedy, gdy nie zrywa istniejących powiązań,
• generowanie nowych rozmiarów przez środowisko docelowe,
• optymalizację w nowoczesnym formacie,
• zachowanie tekstów alternatywnych,
• raport brakujących zdjęć i dokumentów.

SEO i przekierowania

Migracja bez mapy adresów może usunąć z wyników wyszukiwania podstrony, które przez lata zdobywały widoczność. Przed przełączeniem pobieramy listę indeksowanych URL-i z sitemap, analityki, Search Console oraz crawla sklepu.

Dla każdego starego adresu ustalamy:

• identyczny URL w nowym sklepie,
• przekierowanie 301 do bezpośredniego odpowiednika,
• przekierowanie do nadrzędnej kategorii, gdy produkt został trwale wycofany i nie ma zamiennika,
• odpowiedź 410 dla treści, której celowo nie przenosimy i nie posiada wartościowego odpowiednika.

Nie kierujemy wszystkich usuniętych produktów na stronę główną. Taka mapa jest mało użyteczna dla klienta i może zostać potraktowana jak pozorny błąd 404.

Poza przekierowaniami sprawdzamy metadane, canonicale, nagłówki, breadcrumbs, dane strukturalne, robots.txt, sitemapę, paginację oraz indeksowanie filtrów.

Integracje i źródła prawdy

Przed migracją trzeba ustalić, który system jest właścicielem każdego rodzaju danych. Produkt może być tworzony w ERP, opis uzupełniany w PIM, stan aktualizowany przez WMS, a zamówienie wysyłane do księgowości. Nowy sklep nie może przejąć odpowiedzialności przypadkowo.

Analiza obejmuje:

• ERP i księgowość,
• magazyn lub WMS,
• operatorów płatności,
• kurierów i brokerów przesyłek,
• BaseLinker oraz marketplace'y,
• PIM,
• CRM i marketing automation,
• narzędzia analityczne,
• system opinii i programu lojalnościowego,
• rozwiązania niestandardowe korzystające z API albo plików wymiany.

Każda integracja otrzymuje scenariusz testowy. Sprawdzamy nie tylko szczęśliwą ścieżkę, ale też brak produktu, powtórzoną wiadomość, timeout, błąd API i ponowienie zadania.

Migracja próbna

Pierwszy import odbywa się na środowisku testowym. Dzięki temu można zmierzyć czas, znaleźć braki w mapowaniu i przygotować raport porównawczy bez wpływu na sprzedaż.

Po migracji próbnej sprawdzamy między innymi:

• liczbę produktów, wariantów, klientów i zamówień,
• sumy wartości zamówień w wybranych okresach,
• zgodność podatków i walut,
• relacje pomiędzy klientem a zamówieniami,
• obrazy oraz pliki do pobrania,
• przykładowe kategorie i filtry,
• logowanie klienta i ustawienie hasła,
• poprawne działanie integracji,
• mapę przekierowań,
• czas potrzebny na pełny oraz przyrostowy import.

Właściciel sklepu otrzymuje listę przypadków do odbioru. Dobrze dobrana próbka obejmuje produkty i zamówienia o różnej złożoności, zamiast pierwszych dziesięciu rekordów z tabeli.

Strategia przełączenia

Celem jest ograniczenie przerwy sprzedażowej i utraty danych. Po migracji próbnej przygotowujemy dokładny harmonogram.

Typowy plan zawiera:

1. pełny import wykonany przed terminem publikacji,
2. odbiór danych i funkcji na środowisku testowym,
3. obniżenie TTL DNS, jeśli zmienia się infrastruktura,
4. krótkie okno zamrożenia zmian administracyjnych,
5. import przyrostowy nowych klientów, zamówień i zmian magazynowych,
6. przełączenie domeny albo trybu sklepu,
7. test zakupu, płatności, dostawy, faktury i wiadomości,
8. kontrolę statusów integracji i kolejek,
9. monitoring błędów, ruchu i zamówień przez kolejne godziny,
10. decyzję o zakończeniu okna rollbacku.

Jeśli sklep nie może zostać zamrożony, potrzebna jest synchronizacja przyrostowa albo mechanizm kolejkowania zmian. To jeden z najważniejszych elementów wpływających na wycenę.

Plan rollbacku

Migracja powinna mieć jasno określony punkt powrotu. Zachowujemy kopię starego sklepu i danych, zapisujemy moment wykonania ostatniego importu oraz ustalamy, co stanie się z zamówieniami złożonymi po przełączeniu.

Rollback nie może polegać wyłącznie na ponownym skierowaniu domeny. Trzeba wiedzieć, jak przenieść nowe transakcje do poprzedniego systemu albo bezpiecznie je obsłużyć ręcznie. Decyzję podejmuje się na podstawie kryteriów ustalonych przed publikacją, na przykład błędu płatności, utraty zamówień lub niedostępności integracji magazynowej.

Kontrola po uruchomieniu

Po publikacji monitorujemy:

• liczbę i wartość zamówień,
• odsetek udanych płatności,
• błędy formularza, koszyka i finalizacji,
• synchronizację stanów oraz dokumentów,
• kolejki i webhooki,
• odpowiedzi 404 i działanie przekierowań,
• indeksowanie sitemap,
• Core Web Vitals,
• wiadomości od klientów i zespołu obsługi.

Pierwsze poprawki są priorytetyzowane według wpływu na sprzedaż i dane. Drobny błąd wizualny nie może odciągnąć zespołu od problemu powodującego podwójne faktury albo błędny stan magazynu.

Dokumentacja przekazania

Po zakończeniu migracji powstaje dokumentacja obejmująca źródła danych, mapowanie, uruchomione integracje, harmonogramy zadań, zasady backupu, konta administracyjne, procedurę aktualizacji i listę znanych ograniczeń.

Zespół sklepu powinien wiedzieć, gdzie zgłaszać problem, które dane może poprawić samodzielnie i jak odróżnić błąd sklepu od niedostępności zewnętrznego operatora.

Status koncepcji

To projekt koncepcyjny migracji, a nie opis przeprowadzonego przeniesienia konkretnego sklepu. Liczba około 1000 produktów służy pokazaniu skali. Rzeczywisty nakład zależy przede wszystkim od wariantów, jakości danych, historii zamówień, dodatków i integracji.

Planujesz migrację WooCommerce albo zmianę platformy sklepu? Wyślij informacje o katalogu, zamówieniach i integracjach przez formularz bezpłatnej wyceny. Możesz też zobaczyć, jak realizujemy WordPress i WooCommerce oraz integracje e-commerce.