Replatforming czy naprawa? Jak to rozpoznać

Kiedy problemy w sklepie pojawiają się wszędzie (wolne strony, ryzykowne aktualizacje, każda zmiana wymaga dużego wysiłku), replatforming zaczyna wyglądać jak ulga. Świeża platforma, czysty kod, wszystkie nagromadzone problemy zostają za Tobą. Agencje rzadko będą Cię od tego odwodzić; migracja to największa pozycja w cenniku.

Niewygodna arytmetyka jest jednak taka: prawdziwa migracja to zwykle sześć do dwunastu miesięcy pracy dla średniej wielkości sklepu, a przy dużych lub mocno zmodyfikowanych dłużej, zamrożenie nowych funkcji na ten czas, ryzyko SEO przy przełączeniu i przerobienie platformowej strony każdej integracji sprzężonej z API platformy. Czasem warto zapłacić to wszystko. Ale ta decyzja powinna wynikać z diagnozy, a nie z nastroju w zespole.

Większość problemów wynika z wdrożenia

Pytanie, które rozstrzyga sprawę: czy problem wynika z platformy, czy z tego, co na niej zbudowano? Z naszego doświadczenia większość przypadków „wyrośliśmy z platformy” to w rzeczywistości:

Nawarstwione rozszerzenia. Dziesiątki modułów, część porzucona, część w konflikcie, każdy dodany lata temu pod jedną kampanię. To one spowalniają sklep, nie sama platforma.
Przestarzała konfiguracja hostingu. Sklep działa na infrastrukturze zwymiarowanej i skonfigurowanej raz, dawno temu. Cache źle ustawiony albo nieobecny, brak CDN, baza, w której nigdy nie przeprowadzono przeglądu indeksów.
Problem frontendowy przypisywany platformie. Konkretnie na Magento architektura Lumy sprawia, że wszystko wydaje się przestarzałe, choć backend działa poprawnie.
Jedna katastrofalna customizacja. Pojedynczy wczesny fork zachowania core’a, który uczynił każdą kolejną aktualizację niebezpieczną. Uciążliwy, ale usuwalny za ułamek ceny migracji.

Wszystkie te problemy przenoszą się razem z Tobą. Migracja wykonana tym samym procesem, który je wytworzył, powtarza te same problemy na nowszej platformie, tylko że odkryjesz to dopiero po roku.

Kiedy platforma naprawdę jest ograniczeniem

Prawdziwe ograniczenia platform istnieją i udawanie, że ich nie ma, to błąd w drugą stronę. Uczciwe sygnały:

Koniec wsparcia. Dziś Magento 1, jutro inne. Brak oficjalnych łatek bezpieczeństwa niemal na pewno oznacza migrację; nieoficjalne łatki od zewnętrznych dostawców kupują czas, ale tylko ją odsuwają.
Ograniczenie architektoniczne, na które realnie natrafiasz. Nazwane wymaganie, którego platforma nie spełni (samo wrażenie, że demo tej drugiej platformy wygląda na szybsze, to za mało): customizacja checkoutu, na którą nie pozwala Twój plan, B2B rozbudowane ponad swoje możliwości, model katalogu, który fundamentalnie nie pasuje.
Ścieżka aktualizacji została utracona. Tyle pominiętych wersji i własnych łatek, że dojście do aktualnej wersji kosztuje tyle samo, co odejście.
Rachunek ekonomiczny się odwrócił. Licencja plus utrzymanie przez specjalistów kosztują rocznie więcej, niż platforma zwraca w możliwościach.

Na tej liście celowo brakuje jednego punktu: „deweloperzy wolą tę drugą”. Preferencja jest realna i może przechylić szalę, ale nie powinna napędzać całej decyzji.

Tani eksperyment przed drogą decyzją

Nie musisz decydować na podstawie opinii. Ustrukturyzowany audyt odpowiada pomiarami na kluczowe pytanie, czyli skąd naprawdę biorą się problemy: ile spowolnienia to backend, a ile frontend, które rozszerzenia ile kosztują, ile rezerw zostaje w hostingu. Potem wyceń obie ścieżki obok siebie: naprawę na miejscu jako uszeregowaną listę zmian z szacowanym efektem, kontra migrację z wycenionymi danymi, integracjami i zachowaniem SEO.

Czasem audyt mówi: migruj. Robimy migracje i taką rekomendację też umiemy wystawić, kiedy platforma naprawdę jest sufitem. Wolimy jednak, żeby ta decyzja wynikała z pomiarów, a nie z jednego słabego kwartału. Jeśli stoisz na tym rozwidleniu właśnie teraz, rozmowa wstępna jest darmowa i często już ona pokazuje, w którą stronę to zmierza.