Migracja sklepu bez zatrzymywania sprzedaży

Sklep, który sprzedaje za kilkadziesiąt tysięcy dziennie, nie może sobie pozwolić na "przerwę techniczną na czas wdrożenia". Dlatego migrację projektujemy tak, żeby stary sklep sprzedawał do ostatniej godziny, a nowy przejął ruch w kontrolowanym cutoverze. Ten tekst zakłada, że decyzja o zmianie platformy już zapadła; jeśli jeszcze nie, zacznij od tego, czy to na pewno moment na migrację.

Krok 1: dane przed kodem

Migracja wykłada się prawie zawsze na danych, nie na kodzie. Dlatego Blueprint zaczyna od audytu katalogu: atrybuty, kategorie, warianty, zdjęcia. Braki i niespójności naprawiamy w trakcie migracji (tu ciężko pracuje AI), więc nowy sklep startuje z lepszymi danymi niż stary.

Krok 2: nowa platforma buduje się obok

Nowy sklep powstaje na osobnej infrastrukturze i przez cały czas budowy jest zasilany realnymi danymi ze starego: produkty, stany, ceny. Testujemy na prawdziwym katalogu, nie na próbce dwudziestu SKU.

Krok 3: SEO nie znika w noc

Mapujemy każdy istotny URL starego sklepu na nowy, przenosimy metadane i dane strukturalne, a przekierowania 301 przygotowujemy przed cutoverem. Pozycje wypracowane latami to aktywo, traktujemy je jak stany magazynowe: nic nie może zginąć w przeprowadzce.

Krok 4: cutover w godziny, nie tygodnie

Sama zmiana to przełączenie DNS i finalna synchronizacja zamówień, zaplanowana na okno najmniejszego ruchu. Stary sklep zostaje w trybie odczytu jeszcze przez jakiś czas: mamy dokąd wrócić, choć jeszcze nigdy nie było trzeba.

Tak wygląda to w przykładowej realizacji, na której pokazujemy zakres i tempo typowego wdrożenia: sprzedaż idzie nieprzerwanie przez całą budowę, bo stary sklep pracuje do dnia przełączenia. To scenariusz, nie zmierzony wynik klienta. Migracja nie musi być operacją na otwartym sercu, jeśli plan powstaje przed pierwszą linijką kodu.