Migracja to nie kopiowanie danych, tylko renegocjacja modelu

Dane to zapis kompromisów

W każdym starym sklepie jest pole, które nie znaczy tego, co jego nazwa.

Ktoś kiedyś potrzebował oznaczyć produkty dostępne tylko dla trzech kontrahentów. Platforma tego nie potrafiła, ale miała wolne pole „kod producenta". Więc wpisano tam znacznik. Zadziałało. Osoba, która to zrobiła, odeszła cztery lata temu, a znacznik żyje w piętnastu tysiącach kartotek i steruje logiką, o której nikt nie pamięta.

Takich rzeczy w typowym sklepie B2B jest kilkanaście. Nie są udokumentowane, bo nie były decyzjami architektonicznymi - były obejściami, które przetrwały. I dopiero migracja je odkrywa, bo w nowym systemie „kod producenta" jest kodem producenta.

Trzy typowe znaleziska

Pola użyte niezgodnie z przeznaczeniem. Jak wyżej. Rozpoznasz je po tym, że migracja techniczna przechodzi bez błędu, a potem trzech kontrahentów widzi produkty, których widzieć nie powinni.

Kategorie, które są trzema rzeczami naraz. Drzewo kategorii w starym sklepie zwykle miesza podział logiczny („Śruby"), marketingowy („Nowości") i techniczny („Nie pokazuj w menu"). W nowym systemie trzeba to rozdzielić - a to znaczy, że ktoś musi zdecydować, do której kategorii należy każdy z ośmiu tysięcy produktów. To nie jest zadanie dla skryptu.

Kontrahenci, którzy są tym samym kontrahentem. Ta sama firma jako trzy konta, bo tak było wygodniej przy trzech oddziałach. Nowy system ma multi-account i rozwiązuje to porządnie - tylko trzeba zdecydować, czyja historia zamówień trafia dokąd i który limit kredytowy obowiązuje.

Żadne z tych trzech nie jest problemem technicznym. Wszystkie trzy są decyzjami biznesowymi, których firma nie podjęła, bo do tej pory nie musiała.

Dlaczego nie da się przenieść jeden do jednego

Bo „jeden do jednego" zakłada, że oba modele mają te same pojęcia. Nie mają.

Stary sklep miał jedno pole na cenę i obejście na cenniki. Nowy ma cenniki natywnie. Przeniesienie jeden do jednego oznaczałoby przeniesienie obejścia - czyli zapłacenie za nową platformę i nieskorzystanie z tego, po co ją kupiłeś.

Więc migracja z definicji jest tłumaczeniem między modelami, a tłumaczenie wymaga rozstrzygnięć. Każde rozstrzygnięcie to pytanie do biznesu, a nie do zespołu technicznego. I to jest ta część, której nie ma w wycenie liczonej godzinami skryptu importującego.

Praktyczna konsekwencja: to biznes jest wąskim gardłem migracji, nie deweloperzy. Skrypt importujący pisze się w tydzień. Odpowiedź na pytanie „co zrobić z tymi trzema kontami tej samej firmy" potrafi czekać miesiąc, bo wymaga rozmowy trzech działów.

Co z tym zrobić

Zinwentaryzuj obejścia, zanim wycenisz. Usiądź z osobą, która pracuje w tym sklepie codziennie, i zapytaj wprost: co tu jest zrobione „na około"? Dostaniesz listę, której nie ma w żadnej dokumentacji. To jest jeden dzień, który zmienia wycenę o rzędy wielkości.

Potraktuj mapowanie jako etap z własnym terminem i właścicielem po stronie biznesu. Nie jako zadanie techniczne w tle. Rozbieram to w tekście o mapowaniu danych.

Zdecyduj, czego nie migrujesz. To jest najbardziej niedoceniana decyzja w całym projekcie. Historia zamówień sprzed pięciu lat, kontrahenci nieaktywni od trzech, produkty wycofane - każda z tych rzeczy kosztuje w mapowaniu, testach i utrzymaniu. Migracja jest jedyną okazją, żeby ich nie zabierać ze sobą, i większość firm z niej nie korzysta.

Reszta materiałów o tym, jak to poprowadzić, jest w pillarze o migracjach - łącznie z tym, jak przy okazji nie stracić SEO.