Strona głównaE-commerceMigracja sklepu internetowego. Co musi być gotowe, zanim przepniesz DNS

Migracja sklepu internetowego. Co musi być gotowe, zanim przepniesz DNS

Migracja sklepu internetowego to jedyny moment w życiu e-Commerce, w którym wszystko może się wywrócić w ciągu kilkunastu minut. Nie dlatego, że przeniesienie danych jest trudne technicznie. Dlatego, że przepięcie domeny jest w praktyce nieodwracalne: jeśli w tym momencie czegoś brakuje, sklep przestaje sprzedawać, a Ty dowiadujesz się o tym z alertu albo z telefonu od obsługi klienta.

Poniżej opisujemy procedurę, według której w Satisfly przeprowadzamy migracje. Punktem odniesienia jest projekt laneperfumy.pl — przejście z PrestaShop na Shopify Plus wraz z autorskim integratorem spinającym sklep z systemem ERP. Migracja odbyła się w jedną noc, bez rollbacku, bez przestoju w sprzedaży i bez ani jednego krytycznego zgłoszenia w pierwszych dniach po starcie.

To nie jest opis szczęśliwego zbiegu okoliczności. To jest opis listy kontrolnej.

Dlaczego migracje się wykrzaczają

Trzy przyczyny odpowiadają za większość nieudanych przepięć.

Niekompletna mapa przekierowań. Każdy stary adres produktu, kategorii, filtra i wpisu blogowego musi mieć swój odpowiednik na nowej platformie. Nowy silnik prawie zawsze generuje inną strukturę URL, a mapa 301 powstająca po starcie oznacza, że przez kilka dni Google indeksuje setki błędów 404. Pozycje wypracowane latami znikają w tydzień, a wracają miesiącami.

Reguła noindex przeniesiona ze środowiska testowego. Klasyk, który wciąż zbiera żniwo. Sklep działa, sprzedaje, wygląda dobrze — i po kilku dniach wypada z indeksu. Ten błąd wykrywa się zwykle wtedy, gdy ruch organiczny spadnie na tyle, żeby ktoś zajrzał do Search Console.

Nieprzetestowane integracje. Sklep, który przyjmuje zamówienia, ale nie przekazuje ich do magazynu, jest w gorszej sytuacji niż sklep wyłączony. Wyłączony nie generuje zobowiązań, których nie da się zrealizować. Ten sam mechanizm dotyczy płatności, kurierów i feedów do porównywarek.

Do tego dochodzą problemy, które nie wywrócą projektu, ale wygenerują falę zgłoszeń w pierwszym tygodniu: nieprzeniesiona historia zamówień, zresetowane hasła klientów, zgubione punkty lojalnościowe, zniknięte recenzje. Produkty i kategorie migrują się prosto. Problem zaczyna się przy danych, o których nikt nie pomyślał na etapie ustalania zakresu.

Etap 1: wszystko na domenie tymczasowej

Nowe środowisko uruchamiamy najpierw pod adresem tymczasowym i traktujemy je jak produkcję. Testujemy ścieżki krytyczne — rejestrację, logowanie, dodanie do koszyka, checkout, płatność, wygenerowanie listu przewozowego. Testujemy ustawienia serwera, konfigurację cache, moduły i wszystkie integracje.

Pracujemy na czterech typach środowisk: developerskim, testowym, preprodukcyjnym i produkcyjnym. Każde zadanie i całe wydanie przechodzi testy przed startem produkcyjnym, a przed wdrożeniem uruchamiamy automatyczne testy regresji najważniejszych ścieżek zakupowych. Przed samym startem dochodzą testy wydajnościowe i obciążeniowe, a moc serwera liczymy od początku z uwzględnieniem peaków sprzedażowych.

Przy Lane Perfumy kluczowym elementem był integrator ERP pisany specjalnie pod ten projekt. Integracja z systemem magazynowo-księgowym to zwykle najbardziej ryzykowny styk całej migracji, bo zależy od tego, jaki interfejs udostępnia druga strona. Dlatego najbardziej niepewne połączenia weryfikujemy krótkim proof of concept jeszcze przed rozpoczęciem właściwych prac, a nie na tydzień przed startem. Integrowaliśmy Magento i inne platformy między innymi z Wapro, Comarch XL, Comarch Optima, Vendo ERP i Gardens.

Każdą integrację projektujemy z automatycznymi ponowieniami i kolejką błędów typu dead-letter queue. Jeśli ERP albo operator płatności chwilowo padnie, dane nie giną i nie tworzą się duplikaty — po przywróceniu systemu kolejka zostaje przetworzona, a sklep przez ten czas normalnie sprzedaje.

Etap 2: SEO przed przepięciem, nie po

Mapa przekierowań 301 musi być gotowa i przetestowana przed oknem serwisowym. Nie po. Do tego zachowanie struktury URL wszędzie, gdzie to możliwe, przeniesienie meta tytułów i opisów, atrybutów alt zdjęć oraz tagów kanonicznych.

Osobna pozycja na liście kontrolnej: weryfikacja, czy z nowego środowiska zdjęto blokadę indeksowania. Brzmi banalnie. Jest jednym z najczęstszych kosztownych błędów w branży, właśnie dlatego, że brzmi banalnie i nikt nie chce marnować na to punktu w checkliście.

Przy migracji 19 sklepów szwedzkiej firmy Allabeslag ze starego Magento na nowe skala tego zadania rosła liniowo — każdy sklep wymagał własnej mapy i własnej weryfikacji.

Etap 3: okno serwisowe i kryterium przerwania

Samo przepięcie wykonujemy w oknie serwisowym, w godzinach najmniejszego ruchu. Przed nim wykonujemy pełną kopię zapasową. Standardowo backup to pełny obraz serwera wysyłany raz na dobę na zewnętrzne serwery Amazon S3; podniesienie serwera z kopii po całkowitej awarii zajmuje kilka godzin, zależnie od skali projektu. Hosting opieramy o Hetzner, OVH lub AWS.

Najważniejszy element tego etapu to coś, czego większość planów migracji nie zawiera: zdefiniowane kryterium przerwania. Ustalone wcześniej warunki, przy których przerywamy operację, przywracamy poprzednią konfigurację i przenosimy przepięcie na kolejny termin. Bez takiego kryterium zespół w środku nocy podejmuje decyzję pod presją, zwykle na korzyść brnięcia dalej. To jest moment, w którym z drobnego problemu robi się wielogodzinny przestój.

Rollback nie jest oznaką porażki. Jest opcją, która musi istnieć i być przećwiczona.

W oknie serwisowym musi być obecny zespół po obu stronach. U nas dział delivery liczy około 30 osób, zespół project managerów sześć, a w projektach zatrudniamy wyłącznie developerów z kilkuletnim doświadczeniem. Utrzymujemy stały skład w projekcie i procesy zastępowalności — wiedza projektowa jest udokumentowana w backlogu i dokumentacji, nie zamknięta w jednej głowie. Przy operacji, która trwa jedną noc i nie ma drugiego podejścia, to nie jest szczegół organizacyjny.

Etap 4: pierwsze 72 godziny

Po starcie liczy się to, jak szybko wykryjesz problem, a nie to, czy go nie będzie.

Monitoring obejmuje infrastrukturę, procesy integracji i ścieżkę zakupową. Pracujemy na Zabbiksie, Uptime Kumie, Sentry i Cloudflare. Alert o istotnym spadku liczby zamówień trafia jednocześnie do zespołu klienta i do nas — bo spadek zamówień jest najszybszym wskaźnikiem, że coś w checkoucie przestało działać, nawet jeśli wszystkie serwery odpowiadają poprawnie. Większość incydentów wyłapujemy sami, zanim zgłosi je klient.

Zgłoszenia klasyfikujemy priorytetami, od P1 — sklep niedostępny lub zablokowany checkout — do P3, czyli usterek niewpływających na sprzedaż. Ta klasyfikacja musi być ustalona przed startem, nie w trakcie pierwszej awarii. Zgłoszenia krytyczne wydajemy na produkcję w formie hotfixa.

Równolegle monitorujemy Search Console pod kątem błędów indeksowania i skuteczności przekierowań.

Migracja to też moment na odzyskanie kontroli nad kodem

Wiele firm migruje nie dlatego, że technologia zawiodła, ale dlatego, że skończyła się możliwość rozwoju u dotychczasowego dostawcy. Jeśli to Twój przypadek, warunki współpracy są równie ważne co plan techniczny.

Majątkowe prawa autorskie do kodu powinny przechodzić na Ciebie z chwilą zapłaty. Repozytorium ma być dostępne na bieżąco, a umowy hostingowe zawarte bezpośrednio na Ciebie. Stack powinien być otwarty — u nas jest to Magento Open Source, Docker, Ansible i moduły dostępne na rynku — żeby projekt mogła przejąć każda kompetentna agencja. Przy zmianie dostawcy przekazujemy repozytoria z pełną historią zmian, dokumentację i komplet dostępów.

Migracja przeprowadzona bez tych warunków rozwiązuje jeden problem i buduje ten sam od nowa, tylko na innej platformie.

Checklista przed przepięciem

  • Mapa przekierowań 301 kompletna i przetestowana
  • Blokada indeksowania zdjęta z nowego środowiska
  • Meta dane, alty i tagi kanoniczne przeniesione
  • Wszystkie integracje przetestowane na domenie tymczasowej
  • Ścieżka zakupowa przeklikana od rejestracji do listu przewozowego
  • Testy regresji i testy obciążeniowe wykonane
  • Pełna kopia zapasowa wykonana i zweryfikowana
  • Scenariusz rollbacku spisany i przećwiczony
  • Kryterium przerwania operacji ustalone na piśmie
  • Monitoring i alerty skonfigurowane przed startem, nie po
  • Klasyfikacja priorytetów zgłoszeń uzgodniona z klientem
  • Okno serwisowe wyznaczone na godziny najmniejszego ruchu
  • Zespół po obu stronach dostępny w oknie i przez pierwsze 24 godziny

Co z tego wynika

Migracja przeprowadzona w jedną noc bez przestoju nie jest efektem wyjątkowo sprawnego zespołu w dniu przepięcia. Jest efektem tego, co wydarzyło się w tygodniach wcześniej: testów na środowisku tymczasowym, gotowej mapy przekierowań, przećwiczonego rollbacku i monitoringu uruchomionego przed startem, a nie po pierwszym alarmie.

Wszystkie ryzyka opisane wyżej są przewidywalne. Wszystkie da się kontrolować. Ale tylko procesem — nie improwizacją w oknie serwisowym o trzeciej w nocy.

O Satisfly

Satisfly to agencja e-Commerce z Wrocławia, działajająca od 14 lat. Wdrażamy i rozwijamy sklepy internetowe oraz platformy B2B na Magento 2 Open Source, PrestaShop, Shopify i Shopware. Dział delivery liczy około 30 osób. Zrealizowaliśmy migracje między innymi dla Lane Perfumy, Allabeslag i Victoria Vynn.

Popularne