Post-migration tuning - co poprawić w pierwszych 90 dniach

Co monitorujemy w pierwszym tygodniu

Pierwszy tydzień to maksymalny hypercare - codziennie 4-8 godzin dedykowanego monitoringu, dyżury na zmianę w zespole, telefony do prezesa o 7 rano w razie incydentu. Nie da się tego zrobić "lekko", można tylko zrobić to dobrze albo źle.

Metryki techniczne sprawdzam co 30 minut, najlepiej w dashboardzie Grafany z alertami do Slacka:

Metryka	Próg alarmowy
5xx error rate	powyżej 0.5%
Czas odpowiedzi p95 (PDP)	powyżej 3 s
Czas odpowiedzi p95 (checkout)	powyżej 5 s
Database connections	powyżej 80% max
Queue depth	stagnacja powyżej 10 min
Cache hit rate	poniżej 70% (powinno 90%+)
Memory utilization	powyżej 90%

Metryki biznesowe sprawdzam dwa razy dziennie, porównując do okresu sprzed migracji: zamówienia na godzinę vs ten sam dzień tygodnia z poprzedniego miesiąca, średnia wartość zamówienia vs czterotygodniowa średnia, conversion rate vs baseline, add-to-cart rate, ruch organiczny z Google Analytics, nowe rejestracje.

Customer support w trybie hypercare: codzienny standup z liczbą ticketów i ich kategorią, eskalacja problemów technicznych z czasem reakcji poniżej godziny, bezpośrednia linia z dev teamem dla critical issues.

Najczęstsze problemy pierwszego tygodnia, na które warto być gotowym. Klienci nie mogą się zalogować, bo hashy haseł nie są kompatybilne między platformami - reset wymagany, mail z linkiem do resetu hasła jako pierwsza akcja. Stare URL-e dają 404, bo brak redirect rules dla pojedynczych przypadków - monitoring loga 404 i dodawanie redirectów na bieżąco. Koszyk gubi pozycje, bo sesje nie były migrowane - komunikat do klienta z prośbą o ponowne dodanie. Integracja ERP nie aktualizuje statusów, bo źle skonfigurowane webhooki - poll fallback jako backup. Płatności gubią sesję, bo redirect URL po płatności wskazuje na stary URL - hotfix konfiguracji bramki płatności.

Daily report dla stakeholderów ma jasny format, trzyma się jednej strony:

# Day X post-migration - status

## Health
- Uptime: 99.8%
- Errors: 23 (głównie 404 ze starych URL-i, dodajemy redirecty)
- Response time: p95 1.8 s (target 2 s) ✓

## Business
- Zamówienia dziś: 145 (vs 156 w ten sam dzień tydzień temu - 93%)
- Revenue: 87 tys. zł (vs 92 tys. - 95%)

## Tickets
- Nowe: 34
- Rozwiązane: 28
- Top issue: klienci nie mogą się zalogować, mail z resetem wysłany do wszystkich

## Next actions
- Deploy fixu na cart loss (ETA 14:00)
- Dodanie 50 kolejnych redirectów 301 z monitoringu

Plan cutover migracji - co planujesz na sam dzień D.

Wydajność - typowe regresje

Stary sklep był szybki na stagingu, a teraz na produkcji jest wolny - dlaczego. To pytanie pada w każdej migracji, w której nie zrobiono pełnego load testu z produkcyjną skalą danych. Pięć najczęstszych przyczyn regresji.

Dane produkcyjne są dziesięciokrotnie większe niż na stagingu. Staging miał 5 tys. produktów, produkcja 50 tys. Zapytania, które na 5 tys. wykonywały się w 50 ms, na 50 tys. trwają 5 sekund - brak właściwych indeksów. Akcja: indeksowanie tabel pod wzorce realnych zapytań, slow query log analiza od pierwszego dnia.

Cache jest pusty po cutoverze. Wszystkie cache (Redis, Varnish, page cache) startują od zera. Pierwszy klient na każdej stronie czeka na cache miss. Akcja: skrypty warm-up po cutoverze - automatyczny crawl katalogu i popularnych zapytań, żeby cache był ciepły przed pierwszymi prawdziwymi userami.

Search index jest niekompletny albo zimny. Elasticsearch albo Algolia indexing trwał, ale klient w pierwszej godzinie po cutoverze szuka i dostaje zero wyników. Akcja: pre-build pełnego indeksu przed cutoverem, weryfikacja kompletności indeksu jako element checklisty.

CDN nie cache'uje, bo nagłówki Cache-Control są źle ustawione. CDN passthroughuje każdy request do origin, sklep się dusi. Akcja: weryfikacja Cache-Control na wszystkich typach stron przed cutoverem, pre-warm CDN.

Zapytania bazodanowe są nieoptymalne, bo nowa platforma generuje inne query niż stara. Plan wykonania może być inny przy realnym wolumenie. Akcja: włączenie slow query loga od pierwszego dnia, analiza po tygodniu, optymalizacja punktowa.

Plan tuningu na pierwsze cztery tygodnie. Dzień 1-2 to monitoring i fix krytycznych bugów. Dzień 3-4 cache warm-up, weryfikacja konfiguracji CDN. Dzień 5-7 slow query analysis, dodawanie indeksów. Tydzień 2: performance profiling (XHProf, Blackfire), identyfikacja top 10 wolnych endpointów, optymalizacja per endpoint. Tydzień 3-4: A/B testy optymalizacji, customer feedback - co czują jako wolne, mobile-specific tuning.

Realistyczne cele:

Metryka	Day 1	Day 14 target
LCP (PDP)	4.5 s	poniżej 2.5 s
INP (PLP z filtrami)	800 ms	poniżej 300 ms
Database queries per request	250	poniżej 100
Cache hit rate	60%	powyżej 90%

Audyt wydajności sklepu - systematyczne podejście do audytu wydajności.

Indeksowanie Google - 6-12 tygodni

Google nie reindeksuje nowego sklepu natychmiast. Cały proces zajmuje 6-12 tygodni i przez ten czas widzisz oscylację pozycji, której nie da się przyspieszyć siłą.

Krzywa reindeksacji wygląda mniej więcej tak. Tydzień 1-2: Google znajduje większość URL-i przez sitemap.xml plus redirecty 301 z poprzednich adresów. Tydzień 3-4: reindeksacja głównych stron - strona domowa, kluczowe kategorie. Tydzień 5-8: reindeksacja produktów, zaczynając od najpopularniejszych. Tydzień 9-12: stabilizacja, 90%+ poprzednich rankingów odzyskane (jeśli wszystko zrobiłeś dobrze).

Co robić w tym czasie. Submission strategia: pełna nowa sitemap.xml wysłana w Google Search Console pierwszego dnia. Top 100 najważniejszych URL-i ręcznie przez URL Inspection plus "Request Indexing" w GSC. Sprawdzenie linkowania wewnętrznego, czy nie wskazuje na stare URL-e (czasem moduły cache'ują linki przez tygodnie po deploymencie). Backlinki: jeśli macie partnerów blogowych z linkami, prosicie o update.

Monitoring SEO codzienny przez pierwsze cztery tygodnie. Google Search Console: Coverage report (czy "Excluded" rośnie czy spada), Performance (impressions per query), Crawl stats (czy Googlebot odwiedza wystarczająco często). Rank tracking: top 100 query, porównanie dzień po dniu, identyfikacja "gdzie straciliśmy najwięcej" - te query mają priorytet w naprawie.

Cztery typowe problemy, które obniżają ranking po migracji. Stare URL-e w Google dają 404 - brak redirectu dla rzadko crawlowanych ścieżek (głównie blog, archiwalne kategorie). Fix: crawl logów GSC "Excluded - Not found (404)" i dopisywanie redirectów. Duplicate content - stara wersja sklepu wciąż dostępna na dev albo staging domenie, którą Google znalazł. Fix: noindex dla stage, robots.txt block dla dev. Soft 404 - strona zwraca 200, ale wygląda jak pustka ("Sorry, nie znaleziono"). Google klasyfikuje jako 404. Fix: hard 404 dla wycofanych produktów plus 301 do kategorii nadrzędnej. Spadek Core Web Vitals - nowy sklep wolniejszy niż stary. Fix: priorytet na tuning wydajności w tygodniu 1-2.

SEO podczas migracji - prewencja problemów, lepsza niż reaktywne łatanie.

Konwersja spada - jak ratować

Spadek konwersji 15-30% w pierwszych 30 dniach po migracji to scenariusz typowy, nie wyjątkowy. Klienci adaptują się do nowego UX-u, nowe URL-e nie są jeszcze w wynikach Google, search wewnętrzny wymaga tuningu. Ważne, żeby wiedzieć, dlaczego spada, bo to determinuje sposób ratowania.

Pięć najczęstszych przyczyn, które warto wykluczać po kolei.

Klienci nie znajdują produktów - regresja wyszukiwarki. Sygnał: search-to-purchase rate spadł, bounce z organicznych wzrósł. Plan: analiza top 100 zapytań - czy wyniki sensowne, tuning relevance w Elasticsearchu/Algolii, sprawdzenie czy synonimy ze starej platformy zostały przeniesione (często nie - to dodatkowa praca).

UX zmienił się drastycznie. Sygnał: add-to-cart spadł, time-on-page wzrósł (klient błądzi). Plan: heatmapy (Hotjar, Microsoft Clarity), session recordings - obserwujesz jak klienci nawigują, A/B test - powrót do układu zbliżonego do starego dla kluczowych elementów, ankieta do klientów "co cię w nowym sklepie irytuje".

Klienci stracili koszyki, bo sesje nie były migrowane. Sygnał: porzucenia koszyka wzrosły, abandoned cart emails spadły. Plan: mail do klientów z linkiem "odtwórz koszyk z historii", wyciąganie ze starej bazy co było w koszyku, manualne odtworzenie dla VIP-ów.

Klienci nie mogą się zalogować, bo hashy haseł nie są kompatybilne. Sygnał: drop unique logged-in users. Plan: reset wszystkich haseł plus komunikacja, dedykowana strona "logowanie po migracji" z instrukcją, telefoniczny support dla VIP-ów, sales aktywnie kontaktuje top 50 klientów osobiście.

Mobile UX zregredował mocniej niż desktop. Sygnał: mobile conversion spadł znacznie bardziej niż desktopowy. Plan: mobile audit (responsywność, touch targety, font sizes), mobile-specific performance check, hotfix najgorszych elementów.

Realistyczne cele comeback:

• Day 7: bounce rate spadł o 5 pp vs Day 1
• Day 14: search-to-cart na 80% baseline
• Day 30: conversion rate na 90% baseline
• Day 60: conversion rate na 100% baseline
• Day 90: conversion rate powyżej baseline (zysk z migracji)

Jeśli któryś z tych targetów nie jest osiągany, red flag - prawdopodobnie któryś problem nie został zidentyfikowany albo źle naprawiony.

Backlog poprawek - priorytetyzacja

Pierwszy tydzień zbiera 200+ ticketów. Zespół nie da rady wszystkich naprawić od razu, więc trzeba mądrze priorytetyzować. Używam macierzy impact × frequency:

Impact / Frequency	Wielu użytkowników	Niewielu użytkowników
Krytyczne (blocker)	P0 - fix dziś	P1 - fix w tym tygodniu
Major (hamuje biznes)	P1 - fix w tym tygodniu	P2 - fix w 2 tygodnie
Minor (drażniące)	P2 - fix w 2 tygodnie	P3 - backlog
Kosmetyczne	P3 - backlog	P4 - kiedyś

Przykłady realnej kategoryzacji z wdrożeń: "Klienci nie mogą złożyć zamówień" - P0 (blocker, many users). "Płatność nie kończy się sukcesem" - P0 (blocker, many). "Search nie zwraca wyników dla niektórych query" - P1 (major, many). "Quick order CSV nie działa" - P1 (blocker, ale tylko VIP-y używają). "Filtr ceny w PLP nie ma wartości min/max" - P2 (minor, many). "Logo na 404 niewyrównane" - P3 (kosmetyczne, many).

Daily war room standup przez pierwsze cztery tygodnie. Czas: 9:00, 30 minut. Uczestnicy: tech lead, product owner, customer success manager, QA. Agenda: status P0 z wczoraj (5 min), nowe tickety od wczoraj z kategoryzacją (10 min), plan dnia kto co (10 min), blockery (5 min).

Komunikacja ze stakeholderami: daily report dla executive, weekly summary dla biznesu (co się poprawiło, jakie wciąż problemy), customer-facing status page jeśli major issues.

Lessons learned po hypercare. Po każdym P0 i P1 retrospektywa: co się stało, dlaczego nie złapaliśmy w testach, co dodać do test suite, żeby się nie powtórzyło. Buduje długoterminową jakość, a nie tylko gasi pożary.

Kiedy ogłosić koniec hypercare

Hypercare to drogi tryb pracy. Zespół on-call, dedykowany monitoring, daily standupy, brak nowych feature-ów. Nie może trwać wiecznie i nie powinien.

Kryteria wyjścia z hypercare - minimum cztery z pięciu spełnione, zanim ogłosisz koniec.

Stabilność techniczna: brak ticketów P0 i P1 przez 14 dni z rzędu, error rate poniżej 0.5% stabilnie, response time na zaplanowanych targetach.

Stabilność biznesowa: konwersja powyżej 90% baseline, zamówienia powyżej 90% baseline, customer satisfaction (NPS, opinie supportu) na poziomie sprzed migracji.

SEO recovery: 80%+ rankingów odzyskanych, organic traffic powyżej 80% baseline albo rosnący, brak krytycznych issues w Google Search Console.

Customer adoption: 80%+ aktywnych klientów zalogowało się przynajmniej raz po reset hasła, wszystkie VIP-y w pełni operacyjne, większość issues UX zaadresowanych.

Operacyjna gotowość: zespół dev wrócił do normalnego trybu, customer service ogarnia volume bez nadgodzin, procedury BAU (business as usual) udokumentowane.

Typowy timeline. Tydzień 1-2: intensywny hypercare (24/7 monitoring, daily standupy). Tydzień 3-4: hypercare lżejszy (godziny biznesowe, daily standupy). Tydzień 5-8: stabilizacja (weekly standupy, alerty tylko krytyczne). Tydzień 9-12: BAU resumed, monthly review of migration success. Day 90: final migration retrospective plus dokument lessons learned.

Anti-pattern, który widzę regularnie: ogłoszenie sukcesu zbyt szybko. Day 30 widać poprawę, więc zespół jest rozwiązany. Day 60-90 ujawnia kolejne issues, ale nie ma już nikogo, kto by je rozwiązał. Skutki rozciągają się na kolejne kwartały i kosztują wielokrotnie więcej niż dodatkowe dwa miesiące hypercare.

FAQ

Jak długo trwa hypercare po migracji? Realnie 60-90 dni dla typowej migracji średniego sklepu B2B. Krótszy (30 dni) tylko dla bardzo prostych migracji - i często okazuje się to optymistyczne. Dłuższy (120+ dni), jeśli migracja była bardzo skomplikowana albo zmieniał się cały stack technologiczny (np. Magento na Spryker).

Co zrobić, gdy konwersja spada o 30% po cutoverze? Spadek 10-20% w pierwszych 30 dniach jest normalny - klienci adaptują się. Spadek 30%+ to red flag - prawdopodobnie poważne UX, performance albo SEO issues. Akcja: dedykowany task force 3-5 osób z fokusem na conversion recovery. Sprawdź heatmapy, session recordings, customer feedback. Zidentyfikuj top 3 issues, naprawiaj per tydzień.

Czy Google szybko reindeksuje nowe URL-e? Zależy od skali i jakości redirectów. Z dobrymi 301 redirectami i submissionem sitemap - 80% URL-i reindexowane w 30-60 dni. Bez redirectów - powyżej 90 dni i znaczne straty rankingu. Mało popularne URL-e (rzadko crawlowane) - do 120 dni reindeksacji.

Czy mogę uruchamiać nowe funkcje podczas hypercare? Najlepiej nie. Hypercare to czas stabilizacji, nie wprowadzania zmian. Każda nowa funkcja to ryzyko nowego buga i przedłużenia hypercare. Po Day 60 małe usprawnienia są OK. Większe feature-y - po końcu hypercare, czyli typowo po dniu 90.

Co, jeśli klienci nie zalogują się po 30 dniach? Aktywne kontakty: sales dzwoni do VIP-ów osobiście, mailowa kampania z personalizowanymi linkami do resetu, opcja zalogowania przez stary login (jeśli masz mapping). Po 60 dniach klienci, którzy nie wrócili - traktowani jako "lost" - dane do anonimizacji albo przeniesienia do segmentu "dormant".

Co dalej

• Migracje platform e-commerce: Migracje e-commerce
• Plan cutover: Plan cutover migracji
• SEO podczas migracji: SEO podczas migracji