Jak przenieść sklep bez utraty zamówień, danych klientów i widoczności SEO?

Inwentaryzacja danych i zależności

Dla każdego elementu zapisz źródło, format, właściciela, sposób migracji i kryterium akceptacji. Sprawdź jakość danych przed kopiowaniem. Duplikaty SKU, brak GTIN i błędne kodowanie łatwiej naprawić przed migracją niż po uruchomieniu.

Mapa adresów i ochrona widoczności

Zbierz URL-e z crawla, sitemap, Search Console, analityki, logów, Merchant Center i linków zewnętrznych. Każdy wartościowy stary adres przypisz do najbardziej zgodnego nowego odpowiednika. Nie przekierowuj wszystkiego na stronę główną. Brak odpowiednika powinien zwracać 404 lub 410, chyba że istnieje logiczna kategoria zastępcza.

Przekierowania muszą być bezpośrednie, bez łańcuchów. Zaktualizuj linki wewnętrzne, canonicale, hreflang, dane strukturalne i feedy. Zostaw reguły przez długi czas, ponieważ użytkownicy i roboty mogą wracać do starych adresów.

Hasła klientów, zgody i historia zamówień

Sposób migracji haseł zależy od algorytmów obu platform. Czasem możliwa jest zgodność lub mechanizm stopniowego rehashowania, a czasem konieczny bezpieczny reset. Nie eksportuj haseł do arkusza ani nie obchodź zabezpieczeń. Klient powinien otrzymać jasną informację, jeśli po migracji musi ustawić nowe hasło.

Zgody marketingowe potrzebują źródła, daty i zakresu. Nie ustawiaj wszystkim klientom zgody podczas importu. Zamówienia powinny zachować identyfikatory, kwoty, podatki, statusy i relacje z płatnościami. Część historycznych danych może być dostępna w archiwum tylko do odczytu, jeśli pełna migracja jest nieproporcjonalna.

Jak nie zgubić zamówień między eksportem a startem?

Pierwszy pełny eksport odbywa się zwykle przed przełączeniem, ale sklep nadal sprzedaje. Powstaje delta: nowe i zmienione zamówienia, klienci, stany oraz kupony. Plan musi określać, jak zostaną przeniesione i w którym momencie stary system przestanie przyjmować transakcje.

Możliwe strategie to krótkie okno serwisowe, synchronizacja przyrostowa lub ograniczenie wybranych operacji. Wybór zależy od wolumenu i integracji. Po delcie porównaj liczbę zamówień, sumy wartości, ostatni identyfikator oraz status płatności. Nie otwieraj nowego sklepu, dopóki rozbieżność nie jest wyjaśniona.

Migracja próbna i scenariusze akceptacyjne

1. Uruchom pełny import na środowisku izolowanym.
2. Porównaj liczby produktów, wariantów, klientów i zamówień.
3. Przetestuj rejestrację, logowanie, reset hasła oraz zakup gościnny.
4. Wykonaj płatności w trybie testowym i obsłuż webhooki, anulowanie oraz zwrot.
5. Sprawdź podatki, dostawę, faktury, e-maile i aktualizację magazynu.
6. Przecrawl nowy sklep i przetestuj pełną mapę przekierowań.
7. Zweryfikuj GA4, Ads, consent, schema, feed oraz duplikację transakcji.

Plan dnia przełączenia

Obniż TTL DNS odpowiednio wcześniej, wykonaj końcowy backup, zamroź zmiany, uruchom deltę i kontrolę. Dopiero po akceptacji przełącz ruch. Certyfikat, host, CDN, poczta transakcyjna i zadania cron muszą być gotowe przed pierwszym klientem. Stary system zachowaj w trybie tylko do odczytu zgodnie z polityką bezpieczeństwa.

Plan wycofania określa warunki powrotu, osobę decyzyjną i sposób zachowania transakcji z nowego systemu. Powrót po przyjęciu zamówień nie może ich po prostu usunąć. Dlatego punkt bezpiecznego odwrotu powinien być jasno zdefiniowany.

Pierwsze 30 dni po migracji

• Błędy płatności, webhooków, dostawy, e-maili i synchronizacji.
• Liczba oraz wartość zamówień względem porównywalnego okresu.
• 404, 5xx, łańcuchy przekierowań i stare URL-e w logach.
• Indeksacja, canonicale i sitemap w Google oraz Bing.
• Dane produktów i odrzucenia w Merchant Center.
• Konwersje GA4 i Ads, identyfikatory transakcji oraz zgody.
• Wydajność mobilna i błędy JavaScript w procesie zakupu.

Spadek widoczności może być przejściowy, ale błędy nie powinny czekać. Priorytetem są płatności, zamówienia, 5xx, brakujące przekierowania ważnych stron i blokada indeksacji. Raport dzienny w pierwszym tygodniu pozwala reagować zanim problem urośnie.