Kiedy nie migrować - argumenty, których nie usłyszysz od agencji

Gdy problemem jest model danych

To jest najczęstszy przypadek i najdroższa pomyłka. Sklep „nie ogarnia" cenników kontraktowych, więc pada wniosek, że trzeba zmienić platformę.

Tyle że model cenowy nie jest cechą platformy. Jest cechą twojej firmy - i przeniesiesz go ze sobą. Jeśli dziś nikt nie potrafi jednoznacznie odpowiedzieć, w jakiej kolejności naliczają się rabat grupowy, cena kontraktowa i promocja, to po migracji nadal nikt nie będzie potrafił. Tylko rachunek będzie większy.

Test jest brutalnie prosty: czy potrafisz opisać swój model cenowy na jednej kartce, tak żeby dwie osoby policzyły z niego tę samą cenę? Jeśli nie, migracja niczego nie naprawi. Naprawi to praca nad modelem - i można ją wykonać na obecnej platformie.

Gdy nikt nie zmierzył, co jest wolne

„Sklep muli" to objaw, nie diagnoza. Migracja podjęta na podstawie objawu ma jakieś 50% szans, że trafi w przyczynę.

Wolno może być, bo listing odpytuje ERP o cenę dla każdego produktu z osobna. Bo baza nie ma indeksu na kolumnie, po której filtrujesz. Bo obrazki idą z serwera aplikacji zamiast z CDN. Żadnej z tych trzech rzeczy nie naprawia zmiana platformy - dwie pierwsze przeniesiesz ze sobą, trzecią naprawisz w tydzień bez migracji.

Zanim ktokolwiek wymówi słowo „replatforming", potrzebujesz audytu wydajności, który wskaże konkretne zapytanie i konkretny milisekund. Jeśli po audycie okaże się, że wąskim gardłem jest ERP - patrz punkt następny.

Gdy problem jest w ERP

Sklep jest twarzą, ale dane rodzą się gdzie indziej. Jeśli ERP liczy cenę kontraktową w cztery sekundy, to nowy sklep będzie ładował się cztery sekundy. Będzie tylko ładniejszy w trakcie.

To jest szczególnie bolesne, bo migracja platformy jest projektem, który da się kupić, a uporządkowanie ERP-a projektem, którego nie da się kupić od agencji e-commerce. Więc kupuje się to, co jest w ofercie.

Sygnał ostrzegawczy: jeśli w rozmowie o migracji pada zdanie „a przy okazji poprawimy integrację", to znaczy, że integracja jest prawdziwym tematem, a migracja - okazją.

Gdy nie masz kto ma to utrzymać

Migracja to projekt z datą końca. Utrzymanie nie ma daty końca.

Firma, która dziś nie ma nikogo od e-commerce, po migracji nadal nie będzie miała nikogo od e-commerce - tylko na nowszym stacku, którego nikt w firmie nie zna, u dostawcy, do którego trzeba dzwonić przy każdej zmianie. To bywa gorsza pozycja niż przed migracją, mimo lepszej technologii.

Pytanie do zadania przed decyzją brzmi: kto kliknie „deploy" za dwa lata? Jeśli odpowiedź brzmi „no, agencja", policz ten koszt na pięć lat, a nie na czas projektu.

Gdy jedynym argumentem jest wiek

„Jesteśmy na starej platformie" nie jest problemem biznesowym. Problemem biznesowym jest brak wsparcia bezpieczeństwa, niemożność zrealizowania konkretnego wymagania albo koszt utrzymania, który przekracza koszt zmiany.

To są konkretne, policzalne rzeczy. Jeśli któraś zachodzi - migruj i nie zwlekaj, bo zwlekanie jest wtedy droższe. Jeśli żadna nie zachodzi, a argumentem jest wersja w changelogu, to jest to argument dla dostawcy, nie dla ciebie.

Kiedy więc migrować? Gdy potrafisz nazwać wymaganie, którego obecna platforma nie zrealizuje przy żadnym rozsądnym nakładzie, i gdy zmierzyłeś, że to nie jest problem danych ani ERP-a. Wtedy migracja jest inwestycją, a nie ucieczką - i wtedy warto zajrzeć do planu cutover oraz do reszty materiałów o migracjach.

Reszta przypadków to zmiana dostawcy problemu.