Replatforming czy naprawa? Jak to rozpoznać

Kiedy problemy w sklepie pojawiają się wszędzie (wolne strony, ryzykowne aktualizacje, każda zmiana kosztuje więcej, niż powinna), replatforming zaczyna wyglądać na rozwiązanie. Nowa platforma, czysty kod, cały nagromadzony dług techniczny zostaje za Tobą. Agencje rzadko od tego odwodzą; migracja to jeden z największych projektów, jakie mogą sprzedać.

Ten rachunek warto przedstawić otwarcie: 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 za to wszystko zapłacić. Ale ta decyzja wymaga najpierw diagnozy.

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.
Zaniedbany hosting. Sklep działa na infrastrukturze zwymiarowanej i skonfigurowanej raz, dawno temu. Cache źle skonfigurowany albo w ogóle go nie ma, brak CDN, baza, w której nigdy nie przeprowadzono przeglądu indeksów.
Problem frontendowy zrzucany na platformę. Konkretnie na Magento architektura Lumy sprawia, że cały sklep wydaje się wolny, choć backend działa poprawnie.
Jedno katastrofalne dostosowanie. Pojedynczy wczesny fork zachowania core’a, przez który każda kolejna aktualizacja jest niebezpieczna. Kosztowny, ale usuwalny za ułamek ceny migracji.

Nic z tego nie znika na nowej platformie. Migracja prowadzona tym samym procesem, który te problemy stworzył, powtórzy je, a droga do tego kosztuje rok pracy.

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 kolejne platformy. Brak oficjalnych łatek bezpieczeństwa niemal na pewno oznacza migrację; nieoficjalne łatki od zewnętrznych dostawców pozwalają zyskać na czasie, 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): dostosowanie checkoutu, na które nie pozwala Twój plan, procesy B2B rozciągnięte poza granice platformy, model katalogu, który fundamentalnie nie pasuje.
Ścieżki aktualizacji już nie ma. 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 oraz utrzymanie przez specjalistów kosztują rocznie więcej, niż platforma zwraca w postaci możliwości.

Na tej liście celowo brakuje jednego punktu: „deweloperzy wolą tę drugą”. To co najwyżej rozstrzyga remis.

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ą, czego nie zapewnia konfiguracja hostingu. Potem wyceń obie ścieżki obok siebie: naprawę na miejscu jako uszeregowaną listę zmian z szacowanym efektem, a naprzeciw niej migrację z wycenionymi danymi, integracjami i zachowaniem SEO.

Czasem audyt mówi: migruj. Robimy migracje i powiemy to wprost, kiedy platforma naprawdę jest ograniczeniem. Wolimy jednak oprzeć tę rekomendację na pomiarach niż na frustracji z jednego słabego kwartału. Jeśli stoisz właśnie przed tą decyzją, odezwij się, zanim podpiszesz umowę na migrację.