Plan cutover migracji sklepu - dzień przesiadki bez wpadek

W skrócie

• 1. Wybierz strategię: hard cutover (downtime), gradual (parallel running), soft (DNS switch)
• 2. Plan w arkuszu z konkretnymi krokami, ownerami, timingiem
• 3. Rehearsal na stage minimum 2× przed prod
• 4. Komunikacja do klientów: T-30, T-14, T-7, T-1, T+0, T+1
• 5. Rollback plan musi istnieć i być przećwiczony
• 6. Hypercare 1-4 tygodnie po cutover

Wybór strategii cutover

Hard cutover (downtime):

• Stary sklep wyłączony, nowy włączony w określonej godzinie
• Downtime 2-8h
• Często w nocy / weekend
• Plus: prostsze, jednorazowe
• Minus: downtime widoczny dla klientów

Gradual cutover (parallel):

• Oba sklepy działają równolegle
• Część ruchu (test users) na nowy, reszta na stary
• Stopniowy DNS switch
• Plus: bezpieczniejsze, możliwość testowania
• Minus: dłuższy proces, koszty utrzymania dwóch systemów

Soft cutover (DNS):

• Nowy sklep gotowy na subdomeńie
• DNS switch domyślny w godzinę X
• Stary sklep w trybie read-only przez okres przejściowy
• Plus: kompromis między prostotą a bezpieczeństwem
• Minus: TTL DNS może opóźnić switch dla niektórych użytkowników

Dla średnich B2B w PL: soft cutover najczęściej. Dla większych - gradual.

Kalendarz cutover - czego unikać

NIE w piątek wieczorem. Klasyczny błąd. Coś pada, weekend, nikt nie reaguje.

NIE w sezonie. Pre-Christmas, pre-summer, początek roku - okresy peak'u. Cutover w „dead season" (np. luty, sierpień).

NIE przed major holidays. Cutover 22 grudnia → Christmas eve bez supportu.

Idealnie: wtorek / środa rano. Cały zespół dostępny, czas na reakcję przed weekendem.

Sekwencja kroków - typowy soft cutover

T-1 dzień:

• Final stage testing
• Walidacja danych (sample queries)
• Communication: email do klientów „Jutro o 9:00 nowa wersja sklepu"
• On-call schedule

T-1h (rano w dniu cutover):

• All hands on deck (zespół techniczny + product + customer success)
• Final sync ze starego sklepu (delta zamówień z ostatnich godzin)
• Check stage = prod parity

T-0 (godzina cutover, np. 9:00):

• Stary sklep → read-only mode (klienci widzą banner „nowa wersja sklepu już dostępna pod...")
• DNS switch (lub HTTP redirect ze starego → nowy)
• Włączenie monitoringu intensywnego

T+15 min:

• Smoke test: zalogowanie, dodanie do koszyka, finalizacja zamówienia
• Walidacja integracji: czy zamówienie testowe wpadło do ERP
• Check Search Console - bez warnings

T+1h:

• Pierwsze prawdziwe zamówienie klienta → manualne sprawdzenie w ERP
• Monitoring metryk (response times, error rates)

T+4h:

• Status report do zarządu
• Major issues - escalation

T+1 dzień:

• Pierwsza retrospektywa
• Lista issues do naprawienia
• Komunikacja do klientów (follow-up email)

T+7 dni:

• Pełen audyt (analytics, SEO, customer feedback)
• Lessons learned

Plan rollback

Co jeśli coś pójdzie źle? Plan rollback musi istnieć ZANIM zaczniesz cutover.

Scenariusze:

1. Nowy sklep ma critical bug (np. nie da się złożyć zamówienia).

• Rollback DNS na stary sklep
• Stary sklep wciąż działa (dlatego soft cutover)
• Czas: 5-15 minut

2. Integracje z ERP nie działają.

• Wyłączyć sync nowy → ERP (pauza zamówień)
• Klient może oglądać sklep, ale nie zamawiać (banner „chwilowy problem")
• Czas: 10 min do wyłączenia, naprawa godzinami

3. Performance issue (sklep nie wytrzymuje obciążenia).

• Scale up infrastruktury (więcej maszyn)
• Lub rollback do starego sklepu

4. Hard cutover całkowita awaria.

• Pełen rollback: DNS → stary sklep, stary sklep z trybu read-only → normal
• Czas: 15-30 min

Rehearsal rollback: Najlepiej przećwiczyć rollback na stage. Wielu zespołom rollback nigdy nie zadziałał bo nikt go nie próbował.

Read-only mode dla starego sklepu

Po cutover stary sklep powinien działać w trybie read-only:

Klienci mogą:

• Zalogować się
• Zobaczyć historię zamówień
• Pobrać faktury PDF

Klienci NIE mogą:

• Złożyć zamówienia
• Modyfikować danych
• Zmienić hasła

Banner:

"Nowa wersja sklepu już dostępna: https://sklep.pl
Tutaj możesz wciąż zobaczyć swoje historyczne zamówienia."

Czas trzymania read-only: 1-3 miesiące. Potem archive (zamówienia w S3 + link w nowym sklepie do PDF).

Komunikacja z klientami

T-30 dni: Email „Modernizujemy sklep". Co nowego, co lepsze. Bez technicznych szczegółów.

T-14 dni: Email z konkretną datą.

T-7 dni: Reminder + co użytkownik powinien wiedzieć (reset hasła, nowy UI).

T-1 dzień: Final reminder.

T+0 (cutover): Maintenance / informational banner na starym sklepie.

T+1 dzień: „Nowy sklep wystartował! Tutorial, kontakt support".

T+7 dni: Follow-up: „Jak ci się podoba? Daj nam znać o problemach".

Targets:

• Open rate: >50% (klienci B2B są zaangażowani)
• Click rate: >15%
• Helpdesk tickets w cutover week: <10% wzrost vs. baseline

Komunikacja wewnętrzna

Zespół IT: Slack channel dedykowany #cutover-2026-X. War room w cutover day.

Customer success: Briefing 2 tygodnie wcześniej. Lista FAQ. Eskalacja path.

Sales / handlowcy: Prezentacja nowego sklepu. Zmiany w workflow. Trening 1-2 sesje.

Zarząd: Status updates: T-30 (high-level plan), T-7 (gotowość), T+0 (cutover status), T+7 (retrospektywa).

Hypercare - pierwsze 4 tygodnie

Po cutover zespół w trybie intensywnym:

Tydzień 1:

• 24/7 on-call rotation
• Bug triage daily
• Status report do zarządu daily

Tydzień 2-4:

• On-call standard hours
• Bug fixing
• Performance optimization (na podstawie real data)
• Customer feedback integration

Po 4 tygodniach:

• Powrót do normal operations
• Retrospektywa: co poszło dobrze, co źle, co next time

Najczęstsze błędy cutover

1. Brak rehearsal. Plan na papierze, nikt nie przećwiczył. W cutover day okazuje się, że krok 7 nie zadziała.

2. Brak ownerów per krok. „Zespół to zrobi". Nikt nie wie kto konkretnie. Krok pomijany.

3. Brak rollback testowanego. Plan rollback istnieje, ale nikt go nie próbował. W kryzysie nie działa.

4. Brak monitoringu. Cutover gładki, nikt nie patrzy. Po 4h klient telefonuje - coś nie działa.

5. Komunikacja z klientami zaniedbana. T-7 brak emaila → klient w cutover day nie wie co się dzieje → eskalacja.

6. Cutover w peak'u. Cutover w listopadzie (Black Friday przygotowania). Coś pada - katastrofa.

7. Brak hypercare resources. Cutover OK, zespół wraca do normalnych projektów. Tydzień później bugi nieobsłużone.

FAQ

Ile zespół powinien być dedykowany cutover day? Cały zespół technical (dev, ops) + product manager + 1-2 osoby customer success. Minimum 5-8 osób w war roomie.

Czy mogę robić cutover w sobotę? Można. Plus: mniej klientów. Minus: zespół w weekend, koszty. Jeśli klient B2B mało aktywny w weekendy - sobota rano OK.

Co jeśli cutover trwa dłużej niż planowane? Komunikacja do klientów (banner, email). Decyzja po 2h opóźnienia: rollback lub kontynuacja.

Czy mogę robić cutover incrementally (np. po kategoriach)? W teorii tak (gradual), ale w praktyce bardzo skomplikowane (integracje, sesje, cenniki). Najczęściej one-shot.

Co z multi-language i multi-region? Każda wersja językowa może być cutover'owana osobno. Plus: można testować PL pierwsze, potem DE. Minus: dłuższy proces.

Co dalej

• Pillar migracji: Migracje e-commerce
• SEO podczas migracji: SEO podczas migracji
• Mapowanie danych: Mapowanie danych