Anatomia porażki: dlaczego replatforming się wysypuje (i jak tego nie powtórzyć)

Replatforming sklepu internetowego kończy się porażką najczęściej nie przez wybór platformy, ale przez błędne założenie, że to zwykłe przeniesienie danych z jednego systemu do drugiego. W praktyce projekt dotyka frontu, checkoutu, integracji z ERP, SEO i obowiązków prawnych naraz, a 47 proc. takich projektów kończy się przekroczeniem budżetu, opóźnieniem albo niezadowoleniem klienta. Bezpieczny model migracji zaczyna się od diagnozy procesów, a nie od wyboru narzędzia, i właśnie tam najczęściej pękają realne projekty.

Czym naprawdę jest replatforming, a czym prosta migracja danych

Wiele projektów wysypuje się już na etapie definicji, zanim ktokolwiek napisze pierwszą linijkę kodu integracji. Replatforming sklepu internetowego oznacza znacznie więcej niż przeniesienie silnika sprzedażowego z jednego dostawcy na drugiego: zmienia architekturę sklepu, model danych, sposób pracy zespołów i całą sieć integracji, która narosła wokół sklepu przez lata.

Zdanie „przenosimy tylko platformę” jest jednym z najbardziej niebezpiecznych założeń, jakie można usłyszeć na starcie projektu. W praktyce migracja platformy e commerce dotyka dużo więcej obszarów, niż widać na pierwszy rzut oka:

• front sklepu i checkout,
• system zarządzania zamówieniami (OMS),
• katalog produktów i PIM,
• integrację z ERP i magazynem,
• CRM i komunikację marketingową,
• analitykę i śledzenie konwersji,
• SEO i strukturę adresów URL.

Rodzaj projektu	Co obejmuje	Typowe ryzyko
Migracja danych	Przeniesienie rekordów między systemami	Niepełne mapowanie pól
Replatforming	Zmiana platformy, architektury i procesów	Rozjazd między starym a nowym modelem operacyjnym
Redesign	Zmiana wizualna i UX	Utrata konwersji przy złej walidacji
Refactoring	Poprawa kodu bez zmiany platformy	Regresje funkcjonalne

Protip ecommerceblog.pl: jeśli w projekcie pada zdanie „przenosimy tylko platformę”, poproś o spis wszystkich procesów realizowanych dziś ręcznie albo poza systemem. To one najczęściej psują się pierwsze.

Dlaczego firmy w ogóle zaczynają taki projekt

Powody rozpoczęcia replatformingu bywają w pełni racjonalne. Problem zaczyna się wtedy, gdy motywacja jest zbyt mglista, żeby przełożyć ją na konkretne kryteria sukcesu.

• stara platforma nie skaluje się przy wzroście ruchu i zamówień,
• koszty utrzymania i wprowadzania zmian rosną szybciej niż przychody,
• narasta dług technologiczny, który blokuje kolejne funkcje,
• biznes potrzebuje nowych modeli sprzedaży, na przykład B2B, marketplace albo omnichannel,
• checkout i personalizacja wymagają elastyczności, której stary system nie daje.

Skala rynku, na którym te decyzje zapadają, robi się coraz większa. W 2025 roku 69,7 proc. osób w wieku od 16 do 74 lat w Polsce kupowało przez internet w ciągu ostatnich 12 miesięcy, czyli o 2,3 punktu procentowego więcej niż rok wcześniej (GUS, 2025). To oznacza, że błędy w replatformingu dotykają coraz większej grupy klientów, nie tylko wewnętrznych procesów firmy.

Najczęstszy błąd: zaczynanie od narzędzia, a nie od problemu biznesowego

Organizacje często kupują rozwiązanie, zanim nazwą problem, który mają rozwiązać. Wybór platformy e commerce wyprzedza wtedy analizę przedwdrożeniową, a to prowadzi do niedoszacowania czasu, budżetu i zasobów.

1. jaki konkretny problem operacyjny albo sprzedażowy ma zniknąć po projekcie,
2. kto jest właścicielem biznesowym decyzji i ponosi odpowiedzialność za wynik,
3. jakie procesy dziś działają poza systemem i muszą znaleźć w nim miejsce,
4. jakie są mierzalne kryteria sukcesu, nie tylko techniczne, ale biznesowe,
5. co się stanie, jeśli projekt się nie uda w zakładanym terminie.

Objaw techniczny	Prawdziwy problem biznesowy
„Platforma jest za wolna”	Brak jasnych priorytetów wydajnościowych
„Nie da się zintegrować z ERP”	Brak jednego źródła prawdy o zamówieniach
„Checkout jest przestarzały”	Zbyt duży odpływ na etapie płatności

Dane z analiz zarządzania projektami pokazują, że 25 proc. organizacji czasem albo nigdy nie tworzy dokumentów zakresu projektu, a jeśli decyzje zarządcze zajmują 5 godzin lub więcej, wskaźnik niepowodzeń projektów Agile rośnie do 22 proc. (Visual Planning, 2024). Brak jasnego zakresu na starcie kosztuje potem znacznie więcej niż jego dopracowanie przed podpisaniem umowy.

Dane, które się rozsypują: katalog, klienci, historia zamówień

Migracja danych bywa jedną z najbardziej niedoszacowanych części całego projektu. Stare systemy zwykle mają niespójne atrybuty, lokalne obejścia i dane wpisywane ręcznie tam, gdzie automatyzacji nigdy nie było.

Typowe obiekty do migracji obejmują:

• katalog produktów i atrybuty,
• historię zamówień i płatności,
• dane klientów i zgody marketingowe,
• treści SEO i opisy kategorii,
• rabaty, promocje i reguły cenowe.

Eksport i import rzadko wystarczają do migracji katalogu produktów, zwłaszcza gdy PIM staje się sercem katalogu i musi domykać braki w atrybutach, które wcześniej uzupełniano doraźnie w kilku miejscach jednocześnie.

Obiekt danych	Ryzyko	Sposób walidacji
Atrybuty produktów	Niekompletne dane wejściowe	Porównanie liczby aktywnych SKU
Historia zamówień	Rozjazd statusów	Test na próbie losowych zamówień
Dane klientów	Duplikaty kont	Deduplikacja przed importem

Protip ecommerceblog.pl: zrób osobny arkusz dla danych krytycznych, danych do archiwizacji i danych do odtworzenia po starcie. Jedna wspólna tabela na wszystko prawie zawsze kończy się tym, że nikt nie wie, które rekordy są źródłem prawdy.

SEO i adresy URL: cichy zabójca migracji

Spadek ruchu organicznego po replatformingu rzadko wynika z algorytmu wyszukiwarki. Znacznie częściej to efekt błędnego mapowania adresów URL i zgubionych elementów struktury informacji.

Przed startem trzeba sprawdzić:

• pełną mapę przekierowań 301 ze starych na nowe adresy,
• canonicale i statusy indeksacji na kluczowych stronach,
• strukturę nagłówków i breadcrumbs,
• sitemapę i jej zgodność z nową architekturą,
• strony filtrów i kategorii generowane dynamicznie.

Stary URL	Nowy URL	Typ przekierowania	Status testu
/kategoria-stara	/kategoria-nowa	301	do zweryfikowania
/produkt-123	/produkt/nazwa-slug	301	zweryfikowany

UOKiK, monitorując platformy internetowe, stwierdził 19 przypadków naruszeń obowiązków informacyjnych i wezwał przedsiębiorców do zmiany praktyk (UOKiK, 2023). Choć to nie statystyka SEO, dobrze pokazuje, że problemy ze strukturą informacji w ecommerce są egzekwowane realnie, nie tylko teoretycznie.

Integracje, które miały być proste, a stają się największym blokiem

Nowa platforma rzadko pracuje sama. Największym ryzykiem bywa nie sam system, ale ukryta logika biznesowa zakodowana w drobnych skryptach i ręcznych obejściach, o których nikt nie pamiętał, bo działały latami.

Do testów przed startem warto włączyć wszystkie systemy, które wymieniają dane ze sklepem:

• ERP i magazyn (WMS),
• PIM i katalog produktów,
• CRM i marketing automation,
• płatności i integracje kurierskie,
• warstwa analityczna i śledzenie konwersji.

W środowiskach opartych na wielu mikroserwisach kluczowe staje się to, żeby awarię widzieć zanim zobaczy ją klient, a nie po fakcie. To dokładnie ten obszar, w którym observability jest niezbędna w architekturze headless, bo bez niej cutover zamienia się w zgadywanie, który komponent właśnie przestał odpowiadać.

Protip ecommerceblog.pl: przed wdrożeniem zrób listę wszystkich miejsc, gdzie dane są przepisywane ręcznie. Jeśli taki punkt istnieje, to znaczy, że w projekcie już teraz jest ukryta integracja, tylko bez API.

Zakres puchnie, termin się przesuwa, budżet pęka

Do projektu dochodzą kolejne oczekiwania, bo skoro już zmieniamy platformę, to przy okazji można dodać jeszcze jedną funkcję. Pojedynczo wydają się drobne, ale razem tworzą osobny strumień prac, którego nikt nie policzył na starcie.

Kontrola zakresu wymaga twardych zasad:

1. każda nowa funkcja przechodzi przez formalną ocenę wpływu na termin i budżet,
2. decyzję o wycięciu funkcji podejmuje jedna osoba z mandatem biznesowym,
3. zakres obowiązkowy jest spisany i zamrożony przed startem prac,
4. zakres życzeniowy trafia do osobnego backlogu na etap po stabilizacji.

Funkcja	Wartość biznesowa	Koszt wdrożenia	Decyzja
Nowy checkout	Wysoka	Średni	Zostaje
Personalizacja rekomendacji	Średnia	Wysoki	Odkłada się

Dane z analiz projektów Agile pokazują skalę tego zjawiska: 47 proc. projektów kończy się przekroczeniem budżetu, opóźnieniem albo niezadowoleniem klienta, a 11 proc. nie dostarcza w ogóle działającego rozwiązania (Visual Planning, 2024).

Zespół i zarządzanie zmianą: technologia przegrywa z organizacją

Projekt nie wygrywa samym kodem. Jeśli obsługa klienta, sprzedaż i magazyn nie rozumieją nowego procesu, start będzie bolesny niezależnie od tego, jak dobrze zaprojektowano architekturę.

Stary sposób pracy wraca po starcie, jeśli nowy system nie jest osadzony w procedurach, a szkolenia mają charakter ogólny, niedopasowany do ról.

Rola	Nowe obowiązki	Ryzyko bez szkolenia
Obsługa klienta	Nowy panel zamówień	Wydłużony czas reakcji
Magazyn	Nowy proces WMS	Błędne stany towarowe
Sprzedaż	Nowe reguły cenowe	Niezgodne oferty

Do projektu trzeba włączyć konkretnych interesariuszy: właścicieli procesów operacyjnych, osoby odpowiedzialne za dane, obsługę klienta, dział prawny i osoby zarządzające analityką. Bez ich udziału decyzje techniczne żyją własnym życiem, oderwane od tego, jak firma naprawdę pracuje.

Prawo i zgodność w Polsce: co replatforming może popsuć

Przy zmianie platformy łatwo zgubić elementy, które nie są widoczne w demo, ale są obowiązkowe w regulaminie sklepu. Sklep internetowy musi zachować jasne informacje o cenie, kosztach dodatkowych, prawie odstąpienia i procedurze reklamacyjnej.

UOKiK wskazuje też obowiązki dla platform handlowych, w tym informację o tym, czy ofertę wystawia przedsiębiorca czy osoba fizyczna, oraz podział odpowiedzialności między platformą a sprzedawcą (UOKiK, 2023). Jeśli zmienia się sposób przetwarzania danych, od początku projektu trzeba uwzględnić zgodność z RODO, zwłaszcza przy integracjach z nowymi dostawcami zewnętrznymi.

To, w jakiej skali te obowiązki dotyczą polskiego rynku, dobrze pokazuje jedna liczba: w 2025 roku 96,2 proc. gospodarstw domowych w Polsce miało dostęp do internetu (GUS, 2025), co oznacza, że błąd w checkoutach informacyjnych dotyka niemal całej populacji potencjalnych klientów.

Elementy do audytu po migracji:

• informacja o cenie i kosztach dodatkowych,
• dostęp do regulaminu i polityki prywatności,
• checkboxy zgód marketingowych,
• komunikaty o prawie odstąpienia,
• ścieżka reklamacyjna i dane identyfikujące przedsiębiorcę.

Protip ecommerceblog.pl: zrób osobny test zgodności checkoutu po migracji. To, że koszyk działa technicznie, nie znaczy, że prawidłowo pokazuje obowiązki informacyjne, ceny, zgody i dostęp do regulaminu.

Jak nie powtórzyć porażki: praktyczny model bezpiecznego replatformingu

Bezpieczny projekt zaczyna się od diagnozy procesów, a nie od wyboru narzędzia. Dopiero po niej można wydzielić ścieżki krytyczne, które muszą działać od pierwszego dnia, i te, które można uruchomić etapowo.

Etap	Cel	Artefakt
Diagnoza	Zrozumienie procesów i danych	Mapa procesów
Projekt	Architektura i integracje	Specyfikacja techniczna
Testy	Weryfikacja danych, SEO, prawa	Raporty z testów
Start	Kontrolowany cutover	Plan rollback
Stabilizacja	Utrzymanie bez nowych funkcji	Raport incydentów

Lista kontroli przed startem powinna obejmować testy danych, SEO, integracji, wydajności i zgodności prawnej, wykonane na realnych scenariuszach, nie na przykładowych rekordach demo. Po starcie kluczowy jest okres stabilizacji, w którym zespół nie dokłada nowych funkcji, tylko obserwuje, jak system zachowuje się pod prawdziwym ruchem.

Mierniki sukcesu warto ustalić zanim projekt się zacznie, bo dashboard zbudowany po fakcie zwykle pokazuje dane, których nikt wcześniej nie potrzebował. To dokładnie ten moment, w którym pomaga przeprojektowanie raportów pod realne decyzje, zamiast budowania kolejnego zestawu wykresów, na które nikt już nie patrzy po pierwszym tygodniu po starcie.