Migracja sklepu internetowego na nowy serwer to dla właściciela e-commerce zawsze stresujący moment. Ale co zrobić, gdy po przełączeniu „wajchy” okazuje się, że część opłaconych zamówień… została na starym hostingu? I co gorsza – nowy sklep już działa, a stary jest odłączony. Oto historia o tym, jak techniczna wiedza uratowała kilkadziesiąt transakcji przed zaginięciem.
Sytuacja kryzysowa: „Mamy wpłaty, nie mamy zamówień!”
To zdanie, które mrozi krew w żyłach każdego e-commerce managera. Wszystko zaczęło się w poniedziałkowy poranek, tuż po weekendowej migracji sklepu. Zespół klienta był w doskonałych nastrojach – nowy, szybszy serwer działał, strona ładowała się błyskawicznie, a pierwsze zamówienia wpadały do panelu. Migracja uznana za sukces. Szampan, gratulacje, powrót do pracy.
Sielanka trwała do momentu, gdy dział księgowości porównał raporty z bramek płatniczych (PayU/Przelewy24) z listą zamówień w nowym WooCommerce.
Bilans się nie zgadzał.
Na kontach operatorów płatności widniały dziesiątki zakończonych sukcesem transakcji na łączną kwotę kilkunastu tysięcy złotych. Pieniądze fizycznie wpłynęły na konto. Problem? W nowym panelu sklepu te numery zamówień po prostu nie istniały. Była to przerażająca „czarna dziura” w danych.
Sytuacja była patowa i groźna prawnie:
-
Mamy pieniądze klientów – więc zawarliśmy umowę kupna-sprzedaży.
-
Nie wiemy, kto wpłacił – po samej kwocie i ID płatności trudno dojść do danych wysyłkowych.
-
Nie wiemy, co kupili – czy to produkty z magazynu, czy może coś na zamówienie?
-
Nie wiemy, gdzie to wysłać – brak adresu, brak telefonu, brak kodu paczkomatu.
Okazało się, że padliśmy ofiarą tzw. efektu split-brain podczas propagacji DNS. Przez kilkanaście godzin, zanim „internet” w pełni odświeżył informację o nowym serwerze, część klientów (zależnie od swojego dostawcy internetu) wciąż trafiała na starą wersję sklepu. Kupowali tam, płacili tam, a dane zapisywały się w starej bazie danych, która została już odcięta od świata i zapomniana.
Klienci czekali na paczki, my mieliśmy ich pieniądze, ale system milczał. Zegar tykał, a ryzyko negatywnych opinii i wściekłych telefonów rosło z każdą godziną.
Problem: Jak wyciągnąć dane z „trupa”?
Stary sklep był już de facto nieaktywny – nie można było się do niego bezpiecznie zalogować przez wp-admin, by nie namieszać w sesjach. Mieliśmy jedynie „surowy” dostęp do starej bazy danych MySQL.
Klient był w kropce. Musiał ręcznie przenieść te zamówienia do nowego sklepu, żeby wysłać towar. Ale baza WooCommerce to labirynt:
-
Chcesz adres klienta? Tabela
wp_postmeta. -
Chcesz wiedzieć, co kupił? Tabela
woocommerce_order_items. -
Chcesz kod Paczkomatu? To zakopane głęboko w metadanych, często w niestandardowym formacie zapisanym przez wtyczkę kurierską.
Ręczne przeklikiwanie się przez tabelki w phpMyAdmin dla każdego zamówienia zajęłoby dni. A klienci czekali na wysyłkę „na wczoraj”.
Rozwiązanie: Chirurgiczne cięcie SQL
Wiedzieliśmy, że nie ma czasu na zabawę. Musieliśmy dostarczyć zespołowi klienta jeden, czytelny plik, z którego będą mogli błyskawicznie przepisać dane do nowego sklepu.
Zamiast odtwarzać środowisko, napisaliśmy zaawansowane zapytanie SQL, które zrobiło całą brudną robotę za nas.
Nasze zapytanie musiało obsłużyć cztery kluczowe obszary w jednym przebiegu:
-
Zidentyfikować dane osobowe i fakturowe (imię, nazwisko, NIP, adres).
-
Sparować je z konkretnymi produktami (nazwy, ilości, warianty).
-
Wyliczyć finanse (rozróżnić kwoty za produkt, wysyłkę i uwzględnić kupony rabatowe).
-
Wydobyć kod Paczkomatu – to było najtrudniejsze. Użyliśmy wyrażeń regularnych (REGEX), aby przeszukać bazę pod kątem wzorców kodów (np. WAW123) oraz słów kluczowych (InPost, Furgonetka), niezależnie od tego, jak wtyczka je zapisała.
Efekt? Pełna lista zamówień w 3 minuty
Zamiast godzin ręcznego „grzebania” w bazie danych i ryzykowania pomyłek przy przepisywaniu adresów, rozwiązanie przyszło błyskawicznie. Kiedy uruchomiliśmy przygotowane zapytanie na starej bazie danych, wynik pojawił się w ułamku sekundy.
To, co otrzymaliśmy, nie było techniczny bełkotem zrozumiałym tylko dla programistów. Surowe, skomplikowane relacje bazy WordPressa zamieniliśmy w idealnie sformatowany arkusz Excel.
Dostarczyliśmy klientowi plik, który był gotową „instrukcją ratunkową”:
-
Czytelność przede wszystkim: Każde zamówienie było osobnym wierszem. Dane klienta, które w bazie były rozrzucone w 15 różnych miejscach, tutaj widniały obok siebie: Imię, Nazwisko, Adres, Telefon. Zero zgadywania.
-
Kody Paczkomatów „na tacy”: To był największy sukces. Nasz algorytm bezbłędnie wyłowił kody odbioru (np. WAW24M) z gąszcza metadanych. Zespół magazynowy mógł je po prostu skopiować do menedżera paczek InPost, mając 100% pewności, że paczka trafi do wybranego przez klienta punktu.
-
Porządek w finansach: Kolumna z kwotami precyzyjnie rozdzielała wartość towaru od kosztów wysyłki, co pozwoliło księgowości błyskawicznie zafiskalizować zaległe paragony.
Reakcja klienta? Bezcenna. Zespół obsługi sklepu, który jeszcze przed chwilą wizualizował sobie nockę spędzoną na ręcznym odtwarzaniu danych, mógł odetchnąć. Wprowadzenie tych kilkudziesięciu zamówień do nowego systemu zajęło im niespełna godzinę – działało to na zasadzie prostego „kopiuj-wklej”.
Paczki, które formalnie „nie istniały” w systemie o 10:00 rano, o 14:00 były już odebrane przez kuriera. Klienci otrzymali swoje numery śledzenia, a kryzys został zażegnany, zanim ktokolwiek zdążył napisać negatywny komentarz w social mediach.
Wniosek: Agencja musi znać „bebechy”
Ta sytuacja pokazuje, dlaczego w e-commerce ładny wygląd to za mało.
Gdy dzieje się katastrofa, nie potrzebujesz grafika, który poprawi baner. Potrzebujesz partnera, który rozumie strukturę bazy danych i potrafi w niej „grzebać”, gdy panel administratora zawiedzie.
Dla nas marketing to też bezpieczeństwo danych i ciągłość biznesowa. Planujesz migrację lub masz problem z danymi, których nie potrafisz wyciągnąć ze sklepu? Napisz do nas. Rozwiązujemy problemy, które innym wydają się niemożliwe.