Migracja platformy

Migracja sklepu to ryzykowny projekt: dane katalogowe tracą spójność, widoczność w wyszukiwarkach spada, dane klientów się fragmentują, a zakres po drodze się podwaja przez zadania dopisywane w trakcie projektu. Przeprowadziliśmy takich migracji wystarczająco dużo, aby wiedzieć, w których miejscach te projekty zawodzą.

Migracje, które robimy

• Magento 1 na Magento 2 / Mage-OS, razem z audytem rozszerzeń i przepisaniem własnych modułów. Magento 1 jest end-of-life; sklep, który na nim pozostał, jest podatny na publicznie znane CVE.
• WooCommerce na Shopify lub Magento: najczęstsza ścieżka dla sklepów, które wyrosły z WordPressa. Mapujemy wtyczki WP na aplikacje, migrujemy treści i pilnujemy SEO.
• Custom / legacy na Shopify lub Magento, kiedy własny stack zaczął bardziej ograniczać, niż pomagać.
• Shopify i Magento, w obie strony zdarza się rzadziej; zwykle powodem są wymagania B2B albo złożoność katalogu.

Co zachowujemy

• SEO. Pełny inwentarz URL-i, mapa przekierowań 301, obsługa canonicali i hreflang. Ruch organiczny benchmarkujemy przed migracją i po niej.
• Katalog: produkty, warianty, ceny, własne atrybuty, media, lokalizacje magazynowe, wszystko walidowane wiersz po wierszu.
• Dane klientów: konta, adresy, historia zamówień. Wszystko zgodnie z RODO, z uwzględnieniem zgód marketingowych.
• Integracje. Każdy działający dziś hook do ERP, PIM, WMS czy płatności jest przed cutoverem zaimplementowany na nowo i przetestowany.

Jak robimy cutover

Równolegle, na shadow traffic, zamiast podejścia big-bang. Stary sklep pozostaje systemem obowiązującym, dopóki nowy nie udowodni, że mu dorównuje. Deploy jest odwracalny: ścieżkę rollbacku utrzymujemy sprawną do 30 dni po uruchomieniu. Listę go/no-go podpisujemy przed cutoverem, aby w trakcie samego przełączenia nikt nie musiał podejmować decyzji pod presją czasu.