Migracje platform e-commerce - z Magento 1, PrestaShop, custom

W skrócie

• 1. Kluczowe ścieżki: Magento 1 → 2 (najczęstsza w PL), PrestaShop → Magento/Shopware, custom → cokolwiek nowoczesnego
• 2. Trzy największe ryzyka: utrata SEO (rankingi), utrata danych (zamówienia, klienci), downtime
• 3. Czas wdrożenia: 6-12 miesięcy dla średniego B2B
• 4. Koszt: 500 tys. - 2 mln zł zależnie od scope i skali
• 5. Najważniejszy element: plan cutoveru i ścieżka rollback

Typowe ścieżki migracyjne w polskim B2B

Magento 1 → Magento 2. Najczęstsza w PL. Magento 1 koniec wsparcia w 2020, nadal sklepy na M1 to bomby zegarowe. Migracja standardowa, dobrze udokumentowana, dużo narzędzi.

Magento 1 → Magento 2.

PrestaShop → Magento / Shopware. Gdy sklep wyrósł z PrestaShopa. Skala (>5k SKU + B2B) wymusza zmianę.

PrestaShop → Magento.

Custom (PHP 5.6, MySQL 5.5) → Shopware / Magento. Sklepy zbudowane 10+ lat temu, własny stack, brak wsparcia. Migracja do dojrzałej platformy.

Custom → Shopware.

Magento → Shopware (lub odwrotnie). Rzadsze, ale się zdarza. Klient zmienia platformę z powodów politycznych (Adobe podniosło ceny) lub zespołowych (zespół Symfony vs. Magento legacy).

Magento → BigCommerce. Sklepy idące w stronę SaaS, mniej kontroli a mniej utrzymania.

Co konkretnie migrujesz

1. Dane produktowe:

• SKU, EAN, nazwy, opisy
• Atrybuty (kolory, rozmiary, materiały)
• Kategorie i drzewo
• Zdjęcia produktów
• Dokumenty PDF (certyfikaty, karty katalogowe)

2. Klientów i ich kontakty:

• Dane firmowe (NIP, adres, kontakt)
• Adresy dostawy (predefined)
• Cenniki kontraktowe (link do ERP)
• Limit kredytowy (link do ERP)
• Historia zakupów

3. Zamówienia historyczne:

• Pełne zamówienia + statusy
• Faktury (PDF)
• Dokumenty wysyłki

4. SEO:

• URL struktury → mapa redirectów 301
• Meta tagi (title, description)
• Structured data (Schema.org)
• Mapa strony (sitemap.xml)
• Backlink profile (znalezione przez Search Console / Ahrefs)

5. Konfiguracje:

• Metody płatności
• Metody dostawy
• Stawki podatkowe
• Promocje aktywne

6. Integracje:

• ERP (Comarch XL, SAP, etc.)
• PIM (Akeneo)
• OMS / WMS
• BaseLinker
• Marketplace'y
• Płatności bramki

Każdy element to osobny projekt mapowania i migracji.

Mapowanie danych.

SEO migracja - najczęstsze ofiary

Najczęstszym kosztem złej migracji jest utrata pozycji w Google. Czasem 30%, czasem 80%. Zwrot ruchu po utracie - 6-12 miesięcy odbudowy.

Co psuje:

1. Zmiana struktury URL bez redirectów 301.

Stary URL: /sklep/kategoria/produkt-12345.html
Nowy URL: /produkt/produkt-12345

Bez 301: Google indeksuje stary URL → 404 → utrata rankingu
Z 301: Google podąża → rozpoznaje przesunięcie → przenosi ranking

2. Zmiana taksonomii kategorii.

Stara kategoria „Narzędzia → Ręczne → Wkrętaki". Nowa „Narzędzia → Wkrętaki". URL inny, redirect potrzebny.

3. Utrata meta tagów.

Stare meta title/description starannie zoptymalizowane przez lata. Migracja ze stratą = wracasz do generic'ów.

4. Schema.org structured data zerwane.

Sklep miał Article / Product schema. W nowej platformie default schemata to inne pola - Rich Snippets znikają.

5. Sitemap.xml zmienione bez submit do Search Console.

Google nie wie o nowych URL. Indexacja powolna.

SEO podczas migracji.

Cutover - moment przesiadki

Cutover to dzień, gdy stary sklep zostaje wyłączony, nowy włączony.

Strategia 1: Hard cutover.

• W noc, 2:00 - 6:00, downtime 4-6h
• Stary sklep → maintenance page
• Final sync danych (zamówienia z ostatnich godzin)
• Włączenie nowego sklepu

Plusy: prosty, jednorazowy. Minusy: downtime, ryzyko (jeśli coś pójdzie źle - rollback w nocy).

Strategia 2: Gradual cutover.

• Stary sklep dalej działa
• Nowy sklep włączony z subdomeną (new.sklep.pl)
• Część klientów (np. test users) testuje
• Po validation - DNS switch (główna domena na nowy)
• Stary sklep w trybie read-only przez 2-4 tygodnie (zamówienia historyczne dostępne)

Plusy: bezpieczniejszy, możliwość testowania w real conditions. Minusy: dłuższy proces, koszty utrzymania dwóch systemów.

Strategia 3: Soft cutover z parallel running.

• Oba sklepy aktywne równolegle
• Klient widzi tylko jeden (zależnie od DNS)
• Stare zamówienia w starym sklepie, nowe w nowym
• Po stabilizacji - wyłączenie starego

Plusy: maksymalne bezpieczeństwo. Minusy: skomplikowane (zarządzanie 2 produkcjami).

Dla większości polskich B2B średniego segmentu: gradual cutover to standard.

Plan cutover.

Migracja danych historycznych - granica

Pytanie: ile danych przenosimy?

Wszystkie:

• Klienci z kontami (musisz, inaczej tracisz B2B kontrakty)
• Adresy dostawy (predefined)

Tak, ale selektywnie:

• Zamówienia ostatnie 1-2 lata (klient potrzebuje historii)
• Stare zamówienia (5+ lat) - archiwum, ale niekoniecznie w nowym sklepie

Nie:

• Zamówienia 10+ lat (osobny system / pdf'y do księgowości)
• Stare promocje (już nieaktywne)
• Stare moduły custom (przebudowa zamiast portu)

Compromise dla starych zamówień:

• Read-only widok w starym sklepie (klient może wejść, zobaczyć, pobrać PDF)
• Lub: export do PDF + storage w S3, link w nowym sklepie

Integracje - jedne z najtrudniejszych

Integracje z ERP, PIM, OMS, marketplace'ami - każda potencjalnie psuje cutover.

Strategia:

1. Test integracji w nowym sklepie przed cutover. Stage environment, real sync z ERP / PIM. Wszystkie scenariusze (nowe zamówienie, aktualizacja stanu, etc.).

2. Plan synchronizacji w cutover.

• Stop sync ze starego sklepu
• Final sync (catch-up brakujących zdarzeń)
• Start sync z nowego sklepu

3. Walidacja integracji po cutover.

• Każde zamówienie z pierwszej godziny → manualna weryfikacja w ERP
• Monitoring real-time

4. Rollback plan.

• Co się dzieje, gdy integracja w nowym sklepie pada?
• Możliwość włączenia starego sklepu wstecznie z aktualnym statem?

Pillar /integracje.

Koszt migracji

Dla typowej migracji średniego B2B (30k SKU, 10 M zł obrotu, Magento 1 → Magento 2 + integracja Comarch XL):

Discovery + projekt: 50-100 tys. zł, 2-3 miesiące.

Migracja techniczna:

• Setup nowego sklepu: 300-500 tys. zł
• Re-implementacja modułów custom: 200-400 tys. zł
• Migracja danych: 80-200 tys. zł
• Migracja integracji ERP: 100-300 tys. zł
• SEO migracja: 30-60 tys. zł

Cutover: 20-50 tys. zł.

Hypercare (1 miesiąc po cutover): 40-100 tys. zł.

Razem: 800 tys. - 1.7 mln zł, 8-12 miesięcy.

Najczęstsze błędy migracji

1. Brak planu rollback. Coś pada w cutover, nikt nie wie jak wrócić do starego. Klient bez sklepu na dni.

2. Migracja "big bang" zamiast iteracyjnej. Wszystko naraz. Niemożliwe do przetestowania. Większość iść źle.

3. Brak SEO migration plan. Skupienie na technice. SEO planowane na końcu = utrata rankingów.

4. Niedoszacowanie integracji. „Integracje skopiujemy" - w praktyce to przebudowa.

5. Brak testów z prawdziwymi klientami. UAT na test users. Real customer behaviors → bugi w prod.

6. Cutover w piątek wieczorem. Klasyk. Coś pada, nikt nie reaguje w weekend, klient stratny.

Rozwiązanie: cutover w środę / wtorek rano. Cały zespół dostępny, czas na reakcję przed weekendem.

7. Brak komunikacji do klientów. Klient B2B loguje się w piątek - sklep wygląda inaczej, hasła nie działają, nikt go nie ostrzegł. Telefon do biura obsługi → eskalacja.

Komunikacja z klientami

Plan komunikacji:

T-30 dni: email „Modernizujemy sklep - informacja". Nowe funkcje, korzyści. Bez technicznych szczegółów.

T-14 dni: drugi email z konkretną datą cutoveru.

T-7 dni: reminder + co użytkownik powinien wiedzieć (np. „hasło zostanie zresetowane przy pierwszym logowaniu").

T-1 dzień: finalna komunikacja.

T+0 (cutover): maintenance page z konkretną informacją.

T+1 dzień: „Nowy sklep wystartował! Tutaj instrukcja, tu kontakt do supportu".

T+7 dni: follow-up („Jak ci się podoba? Daj nam znać o problemach").

FAQ

Czy mogę zmigrować zachowując ten sam URL? Tak, to najprostszy scenariusz dla SEO. URL jest właściwy, struktura ta sama. Migrujesz tylko backend.

Czy mogę zmigrować bez utraty rankingów? Z dobrym SEO migration plan - tak, w 90%+. Bez planu - utrata 20-50% jest realna.

Jak długo trwa cutover dla średniego sklepu? Hard cutover: 4-6h downtime. Gradual: 2-4 tygodnie parallel.

Czy mogę migrować w sezonie sprzedaży? Lepiej nie. Klienci B2B mają sezony (np. pre-Christmas, pre-summer). Migruj w „dead season" jeśli możliwy.

Czy migracja zawiera nowe funkcje? To pułapka. Migrate jak jest = mniej ryzyka. Nowe funkcje = phase 2. Łączenie obu = projekt rozwala się w pół.

Co dalej

• Konkretne ścieżki: M1 → M2, PrestaShop → Magento, Custom → Shopware
• Mapowanie danych: Mapowanie danych
• SEO migracja: SEO podczas migracji
• Plan cutover: Plan cutover