Migracja multi-store - łączenie i rozdzielanie sklepów B2B

Kiedy łączyć, kiedy rozdzielać

Decyzja idzie w dwóch kierunkach i każdy ma swój zestaw warunków, które warto rozpisać przed wyborem.

Konsolidację (łączenie sklepów) rekomenduję, kiedy kilka sklepów obsługuje tę samą grupę docelową (różne marki, ten sam typ klienta), kiedy katalog produktowy ma realne nakładanie się ponad 50%, kiedy koszty utrzymania wielu instancji zaczynają być nieproporcjonalne do efektu biznesowego, kiedy zespół IT przestaje nadążać z synchronizacją zmian między sklepami albo kiedy backend (ERP, OMS) jest już jeden, a sklepy są tylko frontendowymi oknami nad tymi samymi danymi.

Rozdzielenie (split jednego sklepu) ma sens, kiedy B2C i B2B zaczynają się gryźć w jednej instancji - polityka cenowa, UX, ton komunikacji. Kiedy regulacje prawne różnią się między rynkami (Niemcy mają inne wymagania Impressum niż Polska). Kiedy typy konwersji wymagają radykalnie innego UX - B2C nastawiony na impuls, B2B na powtarzalność i quick order. Kiedy marketing chce niezależnych domen pod osobny branding. Kiedy potrzebna jest separacja księgowa, bo to dwie różne firmy w grupie.

Decyzja praktyczna, którą widzę na liczbach. Sklep łączący B2B i B2C w jednej instancji Magento "dla wszystkich" typowo ma konwersję B2C w okolicach 1-2% (słabe jak na klasyczny B2C) i konwersję B2B 0.5-1% z loginem klienta. Po rozdzieleniu na dwa sklepy z dedykowanymi UX B2C wchodzi w 2.5-3.5%, a B2B w 1.5-2.5%. Wzrost o około połowę bywa większy niż koszt utrzymania drugiej instancji. Dlatego decyzja split B2B/B2C w większości przypadków, w których ją widziałem, ekonomicznie się zwraca.

Sytuacja odwrotna - trzy sklepy regionalne dla jednej marki - to często marnowanie pieniędzy. Trzykrotne koszty hostingu, devu, contentu. Każda zmiana cennika trzy razy. Konflikty w pozycjonowaniu między subdomenami (Google nie wie, którą wersję preferować). Konsolidacja w jeden multi-store obcina koszty o 30-50% i pozwala zespołowi zająć się rozwojem, nie utrzymaniem.

Multi-store w Magento, Shopware, custom

Każda platforma ma własne podejście do multi-store i własne pułapki. Krótkie porównanie dla trzech, które realnie spotyka się w Polsce.

Magento ma trzy poziomy hierarchii: Website, Store, Store View. Website to osobny pool klientów i osobny koszyk - klienci się nie mieszają. Store to osobny katalog, ale wspólni klienci. Store View to osobna prezentacja (język, waluta) na wspólnym katalogu. W praktyce B2C i B2B robię jako osobne Website (klienci się nie mieszają), wersje językowe tego samego sklepu (PL, DE, EN) jako osobne Store Views. Magento ma to obsłużone natywnie od 2010 roku, znajomość wśród deweloperów wysoka, konfiguracja per store dostępna dla niemal wszystkiego - cenników, kategorii, attribute setów. Wady to wspólna baza dla wszystkich Website (skalujesz wertykalnie, gdy rośniecie), skomplikowane modele permissions między Website i Store oraz ciężki indexer przy więcej niż pięciu Store w jednej instancji.

Shopware używa pojęcia Sales Channel, które jest mniej więcej odpowiednikiem Magento Store/Website. Każdy kanał ma osobne kategorie, cenniki, content. Wspólny katalog produktów w core, customizacja per kanał. Mniej dojrzałe niż Magento (krótszy czas na rynku), ale dla średnich sklepów subiektywnie prostsze w użyciu z panelu.

Custom platforma modeluje multi-store przez logikę aplikacji - pełna elastyczność i pełna odpowiedzialność. Dla małej firmy zwykle przerost formy nad treścią. Sensowne tylko, gdy unikalny model biznesowy faktycznie tego wymaga.

Rekomendacja dla typowego B2B z 1-3 sklepami: Magento multi-store, sprawdzone i znane. Dla 5+ sklepów regionalnych pod jednym brandem - rozważ Spryker albo headless setup z wieloma frontendami nad jednym backendem, bo Magento przy tej skali zaczyna boleć indeksacją.

Mapowanie kategorii, atrybutów, cenników

Konsolidacja dwóch sklepów to przede wszystkim ćwiczenie z mapowania danych, nie z technologii. Tu padają wszystkie projekty, w których zespół skupił się na technicznym cutoverze, a pominął analizę domenową.

Kategorie. Sklep A ma "Elektronika > Komputery > Laptopy", sklep B ma "IT > PC > Notebooks". Cel to wspólna struktura, np. "Elektronika > Komputery > Laptopy". Proces, który stosuję: mapowanie 1:1 dla oczywistych przypadków, decyzja biznesowa dla kolizji (kto wygrywa - sklep A czy B?), multi-mapping (jeden produkt w wielu kategoriach), gdy nie ma jednoznacznej reguły, aktualizacja URL-i z canonical i redirectami. Pierwsza pułapka pojawia się przy decyzjach biznesowych - mapowanie 200 kategorii wymaga obecności merchandiserki przez kilka dni, nie godzin.

Atrybuty. Sklep A ma atrybut "Kolor" z wartościami "Czerwony, Niebieski". Sklep B ma "Color" z "Red, Blue, Czarny". Cel to jeden atrybut "Kolor" z normalizowanymi wartościami "Czerwony, Niebieski, Czarny". Typowe pułapki: atrybut w sklepie A jest tekstem, w B dropdownem, sklep A ma "Marka" jako atrybut, sklep B jako kategorię, atrybuty filtrowalne w jednym sklepie i niefiltrowalne w drugim. Każda z tych rzeczy wymaga ręcznego rozstrzygnięcia.

Mapowanie danych przy migracji - szczegółowy przewodnik po tej fazie.

Cenniki. Każdy sklep miał własne cenniki, po konsolidacji powinien być jeden cennik bazowy plus cenniki per website lub sales channel. Klient B2B ze sklepu A ma cennik X, klient ze sklepu B cennik Y, oba przeniesione 1:1. Konflikt pojawia się, gdy ten sam produkt różnił się ceną między sklepami (np. promocja sezonowa w jednym, normalna cena w drugim). Decyzja biznesowa: ujednolicić, zachować różnicę, komunikować klientom. Najczęściej wygrywa ujednolicenie z komunikacją "po konsolidacji obowiązuje cennik X, bo był głównym katalogiem", ale to nie jest decyzja techniczna.

Migracja klientów i historii zamówień

Klienci dzielą się na dwa scenariusze, każdy z własną złożonością.

Klienci nie nakładają się: sklep A ma 500 kontrahentów (głównie PL), sklep B ma 300 (głównie DE), po konsolidacji jest 800 w jednym poolu. Prosta sprawa - import 1:1, mapowanie ról i grup, koniec. To rzadszy przypadek, ale najprzyjemniejszy.

Klienci się nakładają: 200 z 500 kontrahentów sklepu A jest też w sklepie B (różne marki tej samej firmy, ten sam NIP). Trzeba deduplikować, jeden rekord per klient. Algorytm matchingu zaczynam od twardych identyfikatorów (NIP musi pasować, email musi pasować), miękkie (nazwa firmy) tylko jako wskazówka. Manualne review dla przypadków "być może ten sam", typowo 10-30% rekordów wymaga ręcznej decyzji. Decyzje, które trzeba podjąć: która marka klienta dostaje, która historia zamówień łączy się z którą, czy zachować osobne loginy z różnych sklepów (zwykle nie - jeden klient, jedna kartoteka).

Historia zamówień to święta krowa B2B. Klient nie zaakceptuje "zaczynamy od zera", bo historia jest mu potrzebna do analizy zakupów, ponownych zamówień i sprawozdań rocznych. Strategia: eksport wszystkich zamówień z każdego sklepu, mapowanie ID na nowe ID w skonsolidowanym sklepie, import z zachowaniem dat, statusów, pozycji i cen historycznych. W panelu klienta dodaję filtr "Sklep źródłowy: A / B / wszystko" - klient widzi pełną historię, ale z możliwością segregacji.

Hasła klientów to drobny detal, który wraca jako wielki problem, jeśli o nim zapomnisz. Hashy z różnych platform nie da się przenieść kompatybilnie (Magento używa innego algorytmu niż Shopware). Klient musi zresetować hasło przy pierwszym logowaniu. Komunikacja: dwutygodniowe wyprzedzenie mailem z linkiem do resetu plus instrukcja "co się zmieniło i dlaczego". Bez tej komunikacji telefon na infolinię od 20% bazy w pierwszym tygodniu.

SEO - redirects i konsolidacja domeny

Straty SEO podczas migracji multi-store są największe wśród wszystkich typów migracji, jakie znam. Bo zmieniają się jednocześnie domeny, struktura URL-i, taksonomia kategorii i często też produkty.

Trzy źródła ryzyka. Pierwsze - URL-e się zmieniają. Stary URL sklepA.pl/komputery/laptop-dell-xps-15 przechodzi na nowy sklep-konsolidowany.pl/elektronika/komputery/laptopy/dell-xps-15. Bez redirectów Google przestaje rankować, ruch organiczny spada o 60-80% w 2-3 miesiące. Drugie - duplicate content między sklepami. Konsolidacja oznacza, że ten sam produkt istniał na sklepA.pl i sklepB.pl. Po konsolidacji jedna wersja jest kanoniczna, druga musi mieć 301 redirect. Trzecie - backlinki. Stare linki z forów branżowych, blogów partnerów, katalogów handlowych kierują na stare URL-e. Bez redirectów to 404 i utracony link juice. Z porządnymi 301 redirektami zachowujesz w okolicach 90% wartości linków.

Plan mapowania redirectów wygląda mniej więcej tak:

sklepA.pl/komputery/laptop-dell-xps-15 → 301 → sklep-konsolidowany.pl/elektronika/komputery/laptopy/dell-xps-15
sklepB.pl/it/pc/notebook-dell-xps-15  → 301 → sklep-konsolidowany.pl/elektronika/komputery/laptopy/dell-xps-15

Implementacja zależy od stacku. Najczęściej generuję plik CSV z mapowaniem URL-i na dziesiątki tysięcy linii, ładuję do serwera (nginx, Apache) z dedykowanymi regułami albo importuję do Magento URL Rewrites. Cloudflare Page Rules albo Workers działają jako warstwa pośrednia, gdy nie chcesz dotykać serwera. Wybór zależy od skali - poniżej 50 tys. redirectów nginx daje radę, powyżej rozważ Cloudflare.

Testowanie nie może być pominięte. Wyciągam 100 najlepiej rankujących URL-i z poprzedniego sklepu, sprawdzam redirect ręcznie i automatycznym skryptem curl, po cutoverze monitoruję Google Search Console pod kątem nagłego skoku 404. Submission nowej sitemap w GSC jest jeszcze tego samego dnia.

SEO podczas migracji sklepu - pełna procedura dla migracji platformy.

Praktyka cutover dla multi-store

Konkretna oś czasu cutoveru dla konsolidacji trzech sklepów w jeden, której używam jako szablonu.

Cztery do dwóch tygodni przed: przygotowanie. Mapowanie kategorii, atrybutów, cenników zatwierdzone przez biznes (nie technologię). Import testowych danych na staging, weryfikacja przejścia kompletnego cyklu (login klienta, koszyk z towarem z każdego sklepu źródłowego, checkout, faktura). Reguły redirectów wygenerowane i testowane na próbce.

Tydzień przed: dry-run. Pełny przebieg cutoveru na środowisku stagingu, jakby to była produkcja. Mierzę czas trwania każdego kroku, listę pułapek, plan B dla każdej fazy. Komunikacja do klientów wychodzi z dwutygodniowym wyprzedzeniem mailem i banerem w sklepach: "W weekend X.Y.Z zmieniamy sklep, hasła zresetujemy, instrukcja w załączniku".

Cutover w nocy z soboty na niedzielę. O 22:00 maintenance mode na wszystkich trzech sklepach. O 22:15 finalne ekstrakty danych (delta od ostatniego sync). O 23:00 import do skonsolidowanego sklepu i pełna indeksacja. O 2:00 weryfikacja smoke testów - login klienta z każdego sklepu źródłowego, dodanie do koszyka, checkout. O 3:00 DNS update: sklepA.pl, sklepB.pl, sklepC.pl przekierowane na skonsolidowanySklep.pl. O 4:00 włączenie reguł 301 redirect po stronie nowego sklepu. O 5:00 wyłączenie maintenance, sklep otwarty. O 8:00 w niedzielę powiadomienie klientów mailem o zmianach z linkiem do resetu hasła. O 9:00 w poniedziałek hypercare - zespół gotowy, monitoring intensywny.

Pierwsze dwa tygodnie po cutoverze: codzienny monitoring metryk (sprzedaż, błędy, tickety w supporcie), aktualizacja reguł redirectów na podstawie logów 404 (klienci znajdują linki, których nie przewidziałeś), pomoc przy resecie haseł - typowo 10-20% klientów wymaga manualnej asysty, bo nie czyta maila.

Plan cutover migracji - bardziej szczegółowy przewodnik dla zwykłej migracji platformy.

FAQ

Czy mogę połączyć sklep B2C i B2B w jednej instalacji Magento? Technicznie tak, przez multi-website. Biznesowo rzadko ma to sens. B2C i B2B mają zupełnie różne UX, polityki cenowe, ścieżki konwersji. Dwa wyspecjalizowane sklepy konwertują lepiej i są łatwiejsze w utrzymaniu pod względem contentu. Wspólny backend (ERP, OMS) wystarcza, żeby operacje były spójne. Łączenie tych dwóch światów na froncie zwykle obniża konwersję w obu kanałach.

Jak nie stracić rankingu przy łączeniu domen? Redirect 301 z wszystkich starych URL-i na nowe, pełne mapowanie (nie wildcard - wildcard rzadko obsługuje strukturę kategorii poprawnie). Submission nowej sitemap w Google Search Console od razu po cutoverze. Cierpliwość - Google indeksuje nowe URL-e przez 2-12 tygodni i przez ten czas widzisz wahania pozycji. Z dobrymi redirectami straty są poniżej 10% i wracają w 3-6 miesięcy.

Co z subdomenami regionalnymi - zostawiać czy łączyć? Zależy od strategii. Subdomeny (de.sklep.pl, fr.sklep.pl) ułatwiają multi-language i lokalne SEO, ale każda jest osobnym hostem dla Google. Jedna domena z folderami (/de/, /fr/) buduje silniejsze authority i prostszy stack techniczny. Dla średniej firmy polecam folder structure z hreflang, dla dużej z osobnymi zespołami marketingu per region - subdomeny.

Jak zachować historię zamówień klientów po konsolidacji? Pełny import historycznych zamówień z każdego sklepu do nowego, z mapowaniem ID i powiązaniem do klientów po deduplikacji. W panelu klienta filtr "Sklep źródłowy" pozwala segregować. Backupy starych sklepów trzymane minimum pięć lat (wymagania prawne dla dokumentów księgowych), w trybie tylko do odczytu, na wypadek audytu.

Czy konsolidacja zmniejszy koszty utrzymania o połowę? Realnie 30-50% w pierwszym roku. Hosting tnie się znacząco - z trzech maszyn na jedną mocniejszą - ale nie schodzi do jednej trzeciej, bo skonsolidowana instancja musi być potężniejsza. Dev kosztuje mniej, bo mniej kontekstu do utrzymania, ale rosnąca złożoność multi-store potrafi to częściowo niweczyć. Zespół zarządza jednym sklepem zamiast trzema. Pełny ROI z konsolidacji widzę po 12-18 miesiącach.

Co dalej

• Migracje platform e-commerce: Migracje e-commerce
• Plan cutover w praktyce: Plan cutover migracji
• SEO podczas migracji: SEO podczas migracji sklepu