Migracja do Magento bez przenoszenia starych problemów

Zmiana platformy to coś więcej niż przeniesienie produktów, klientów i zamówień do nowej bazy. Trzeba zachować to, co działa, zabezpieczyć integracje i widoczność w wyszukiwarce, a jednocześnie zdecydować, których ograniczeń starego rozwiązania nie warto przenosić dalej.

Prowadzimy migracje z Magento 1, platform customowych, WooCommerce i innych systemów do Magento 2. Nową platformę projektujemy na podstawie rzeczywistych procesów firmy i wymagań na kolejne lata, zamiast odtwarzać poprzedni sklep funkcja po funkcji.

Bezpłatna rozmowa, 30-60 minut. Poznamy obecną platformę, zakres danych, integracje i ograniczenia migracji. Wstępnie określimy największe ryzyka oraz obszary wymagające dalszego discovery.

Kontekst

Kiedy zmiana platformy zaczyna mieć sens

Decyzja o migracji rzadko wynika z jednego problemu. Z czasem obecna platforma zaczyna wymagać coraz większej liczby obejść, integracje stają się trudniejsze do utrzymania, a każda nietypowa funkcja kończy się kompromisem.

Magento ma sens szczególnie wtedy, gdy firma potrzebuje większej kontroli nad kodem i architekturą, rozbudowanych integracji, własnej logiki biznesowej albo obsługi wielu rynków i modeli sprzedaży.

W takim projekcie nie chodzi wyłącznie o uruchomienie Magento. Chodzi o przeniesienie działającego biznesu na nową technologię bez utraty danych, procesów i ciągłości sprzedaży.

Decyzje

Nie kopiujemy starego systemu 1:1

Stary sklep zwykle zawiera warstwy logiki, które powstały w konkretnych okolicznościach kilka lat temu. Część nadal ma sens biznesowy. Część rozwiązuje problem, którego już nie ma. Część robi ręcznie coś, co Magento obsługuje standardowo.

Dlatego podczas discovery każdy istotny element istniejącego rozwiązania przechodzi przez jedną z czterech decyzji:

Istniejący proces

  • Zachować

    Funkcja jest potrzebna i działa dobrze.

  • Przebudować

    Potrzeba jest realna, ale implementacja może być prostsza lub lepiej dopasowana do Magento.

  • Zastąpić standardem Magento

    Funkcja istnieje natywnie albo może zostać obsłużona przez sprawdzone rozwiązanie bez tworzenia kolejnego customowego mechanizmu.

  • Usunąć

    Proces nie wnosi już wartości, choć nadal funkcjonuje w obecnym systemie.

Ostatnia decyzja bywa najbardziej niewygodna, bo wymaga zakwestionowania funkcji, które kiedyś miały swoje uzasadnienie. Warto odbyć tę rozmowę przed rozpoczęciem developmentu, kiedy można jeszcze zmienić założenia bez kosztownego przepisywania gotowego rozwiązania.

Próba odwzorowania starej platformy 1:1 zwykle kończy się przeniesieniem jej problemów do nowego systemu i zapłaceniem za to pełnej stawki.

Bezpieczeństwo

Co zabezpieczamy podczas migracji

Dane

Zakres zależy od projektu. Możemy przenieść produkty i warianty, kategorie, konta klientów, adresy, zamówienia i historię zakupów, ceny, reguły cenowe, rabaty, kupony, treści CMS, media, dane B2B oraz konfigurację języków, store views i rynków.

Nie wszystkie dane zawsze warto przenosić. Dobrym przykładem jest historia zamówień: może trafić do Magento, jeśli korzysta z niej obsługa klienta lub raportowanie, ale przy dużych wolumenach bardziej racjonalne bywa pozostawienie starszych danych w systemie legacy jako archiwum.

Zakres wynika z potrzeb biznesowych, nie z zasady, że wszystko musi zostać przeniesione.

Integracje

Migracja platformy oznacza zwykle również zmianę sposobu komunikacji z ERP, PIM, CRM, systemami magazynowymi i rozwiązaniami dedykowanymi.

Najpierw ustalamy, jakie procesy realizuje obecna integracja i które z nich muszą zostać zachowane. Dopiero potem decydujemy, czy istniejące rozwiązanie techniczne warto wykorzystać, czy zaprojektować integrację ponownie pod Magento.

Dla każdego przepływu - produktów, cen, stanów magazynowych, klientów, zamówień i statusów - ustalamy kierunek synchronizacji, częstotliwość, obsługę błędów oraz to, który system jest źródłem prawdy. Ta ostatnia decyzja w starych wdrożeniach często nie jest nigdzie zapisana, a rozjazdy danych biorą się właśnie z jej braku.

Mamy doświadczenie w integracjach z SAP, Comarch, Microsoft Dynamics i Enova oraz z systemami dedykowanymi po stronie klienta.

Integracje systemowe →

SEO

Jednym z największych ryzyk replatformingu jest utrata widoczności organicznej po zmianie adresów URL i struktury serwisu. Techniczna część migracji SEO powinna być elementem projektu, a nie zadaniem na dzień przed uruchomieniem.

Przygotowujemy mapowanie starych adresów na nowe, przekierowania 301, canonicale, sitemap i pozostałe elementy związane z indeksacją. Tam, gdzie ma to sens, zachowujemy istniejącą strukturę URL. Możemy też wdrożyć rekomendacje przygotowane przez Wasz zespół SEO lub agencję.

Nie da się uczciwie zagwarantować, że po dużej zmianie platformy pozycje nigdy się nie zawahają. Można natomiast dobrze przygotować migrację i ograniczyć ryzyko wynikające z błędów technicznych.

Ciągłość sprzedaży

Dane przenosimy przed finalnym uruchomieniem, żeby zweryfikować ich kompletność i poprawność, zanim nowa platforma zacznie obsługiwać zamówienia.

Go-live przygotowujemy jako kontrolowane przełączenie: ustalamy moment zamrożenia zmian w starym systemie, wykonujemy finalne uzupełnienie danych przyrostowych, testy, przełączenie domeny, sprawdzenie integracji w warunkach produkcyjnych i kontrolę pierwszych zamówień.

Scenariusz rollbacku powstaje wcześniej, nie w trakcie.

Stary system zwykle nie jest wyłączany od razu. Może przez pewien czas pozostać jako archiwum danych historycznych lub rozwiązanie awaryjne.

Migracja, walidacja i porządkowanie danych

~500 000

produktów

Migracja dużego katalogu to również praca nad jakością danych

Przy dużych migracjach sam import rekordów jest tylko częścią zadania.

W jednym z realizowanych przez nas procesów migracyjnych zakres obejmował około 500 000 produktów. Dane przed i podczas migracji wymagały walidacji, czyszczenia oraz uzupełniania brakujących informacji.

Prace obejmowały między innymi:

  • wykrywanie brakujących danych,
  • walidację poprawności danych przed importem,
  • czyszczenie i normalizację wartości,
  • uzupełnianie brakujących informacji,
  • poprawianie błędnie przypisanych lub niespójnych atrybutów,
  • kontrolę poprawności danych już po migracji.

Przy tej skali nie wystarczy odpowiedzieć na pytanie „czy produkty zostały zaimportowane”. Trzeba również sprawdzić, czy dane po migracji są kompletne, spójne i mogą być bezpiecznie wykorzystywane przez Magento, wyszukiwarkę, integracje oraz klientów sklepu.

UX/UI

Migracja może oznaczać redesign, ale nie musi

Zmiana technologii jest dobrym momentem na przebudowę UX/UI, ale nie każdy projekt tego potrzebuje.

Jeśli obecny interfejs działa dobrze, możemy zachować jego kierunek i skoncentrować projekt na technologii, architekturze i integracjach. Ogranicza to liczbę zmiennych w projekcie i ułatwia późniejszą ocenę wpływu samej zmiany technologicznej.

Jeśli stary sklep wymaga również zmian w doświadczeniu użytkownika, możemy przeprowadzić pełny proces UX/UI i zaprojektować nowy interfejs.

To dwie niezależne decyzje. Migracja na Magento nie powinna automatycznie oznaczać redesignu tylko dlatego, że powstaje nowa platforma.

Wariant 01

Migracja bez redesignu

Zmiana technologii przy zachowaniu obecnego kierunku interfejsu.

Wariant 02

Migracja + redesign

Nowa technologia oraz nowy UX/UI.

Proces

Jak wygląda migracja z Velocity

  1. 01

    Discovery

    Podsumowanie obecnej platformy: funkcje, procesy, dane i integracje. Ustalenie wymagań nowego rozwiązania.

  2. 02

    Projekt rozwiązania

    Decyzja, co zachować, przebudować, zastąpić standardem Magento lub usunąć. Dokumentacja funkcjonalno-techniczna i architektura docelowa.

  3. 03

    Development Magento + Hyvä

    Budowa platformy, customowych funkcjonalności i integracji. UX/UI, jeśli jest częścią projektu.

  4. 04

    Migracja i weryfikacja danych

    Przeniesienie danych przed uruchomieniem i sprawdzenie ich kompletności oraz poprawności na działającym środowisku.

  5. 05

    Cutover

    Finalne uzupełnienie danych, testy, przełączenie i kontrola kluczowych procesów.

  6. 06

    Stabilizacja

    Monitoring zamówień, integracji i wydajności po uruchomieniu.

Poszczególne obszary mogą być realizowane równolegle. Nie traktujemy tego procesu jako sztywnego waterfallu.

Ryzyko

Cztery ryzyka, które trzeba opanować przed migracją

SEO

Mapowanie URL-i, przekierowania i kontrolę indeksacji planujemy przed uruchomieniem, nie po zaobserwowaniu spadków.

Dane

Migrację wykonujemy przed cutoverem i weryfikujemy kompletność danych na nowej platformie. Sam fakt, że rekordy zostały zaimportowane, nie oznacza jeszcze, że są prawidłowo powiązane.

Customowa logika

Identyfikujemy procesy, które rzeczywiście trzeba odtworzyć. Niedoszacowanie tego obszaru może prowadzić do wzrostu zakresu i kosztów już w trakcie developmentu.

Przenoszenie legacy 1:1

Nowa platforma nie powinna dziedziczyć ograniczeń starego systemu. Każdy istotny element przechodzi przez świadomą decyzję: zachować, przebudować, zastąpić standardem albo usunąć.

Technologia

Dlaczego Magento

Magento nie jest właściwym wyborem dla każdego sklepu.

Jego przewaga pojawia się wtedy, gdy e-commerce wymaga kontroli nad technologią, customowych procesów, wielu integracji albo sprzedaży na kilku rynkach.

W nowych projektach najczęściej pracujemy na Magento Open Source i Hyvä. Adobe Commerce rekomendujemy wtedy, gdy konkretne wymagania uzasadniają jego dodatkowe funkcje i koszt licencji.

Nie zaczynamy od wyboru licencji - zaczynamy od wymagań.

Dopasowanie

Kiedy to nie jest właściwa usługa

Budujecie platformę od zera

Nie ma istniejącego sklepu ani danych, które trzeba przenieść.

Wdrożenia Magento →

Zależy Wam wyłącznie na technicznym odwzorowaniu obecnego systemu

Najwięcej wartości dajemy w projektach, w których migracja pozwala również zweryfikować istniejące procesy. Jeśli możliwość zakwestionowania obecnego rozwiązania jest całkowicie wykluczona, prawdopodobnie nie jesteśmy właściwym wykonawcą.

Pytania

FAQ

VLCT

Tak. Nie jest to klasyczna aktualizacja wersji - architektura obu wersji różni się zasadniczo, więc M1 → M2 oznacza wdrożenie nowej platformy z zaplanowanym przeniesieniem danych oraz odtworzeniem lub przeprojektowaniem funkcji i integracji.

VLCT

Tak. Produkty, klienci i zamówienia zwykle można przenieść w przewidywalny sposób. Więcej analizy wymagają funkcje oparte na wtyczkach i customowej logice - trzeba ustalić, które z nich odtworzyć w Magento, a które zastąpić standardem platformy.

VLCT

Nie i zwykle nie jest to dobry pomysł. Część funkcji można zastąpić standardem Magento, część przebudować, a część usunąć, jeśli przestały wnosić wartość. Każdy istotny element przechodzi przez świadomą decyzję podczas discovery.

VLCT

Nie. Decyzja zależy od tego, do czego te dane są realnie używane: obsługi klienta, reklamacji, raportowania czy innych procesów biznesowych. Część firm migruje pełną historię, inne pozostawiają starsze dane w systemie legacy dostępnym jako archiwum.

VLCT

Zaczynamy od ustalenia, co obecna integracja faktycznie robi i które procesy muszą zostać zachowane. Następnie oceniamy, czy istniejące rozwiązanie warto odtworzyć, czy zaprojektować je pod Magento na nowo. Dla każdego przepływu ustalamy kierunek synchronizacji, częstotliwość, obsługę błędów i źródło prawdy.

VLCT

Każda duża zmiana platformy niesie ryzyko, ale można je ograniczyć. Kluczowe są prawidłowe mapowanie adresów, przekierowania 301, kontrola indeksacji i przygotowanie technicznej części migracji SEO przed uruchomieniem, a nie po zaobserwowaniu spadków.

VLCT

Nie. Możemy zachować obecny kierunek UX/UI albo przeprowadzić pełny redesign. To dwie niezależne decyzje.

VLCT

Może zostać wyłączony albo pozostawać przez pewien czas jako archiwum danych historycznych lub rozwiązanie awaryjne. Sposób postępowania ustalamy podczas planowania cutoveru.