Migracja z Magento do VTEX: co przenosisz, co się psuje i jak to zaplanować

VTEX rozwiązuje wszystkie trzy problemy, ale tylko wtedy, gdy migracja zostanie odpowiednio zaplanowana. Zły kolejność działań oznacza debugowanie błędów importu katalogu o drugiej w nocy przed startem produkcyjnym albo obserwowanie, jak pozycje organiczne topnieją, bo mapowanie przekierowań potraktowano po macoszemu. Ten przewodnik daje seniorskim zespołom inżynierskim gotowy playbook: co przenosi się bez problemów, co wymaga ręcznej interwencji i jakie trzy decyzje architektoniczne musisz podjąć, zanim nastąpi pierwsze wywołanie API.

TL;DR: Co się przenosi, co się psuje i 3 decyzje do podjęcia na początku

VTEX Catalog API przyjmuje dane produktowe, ale trzy decyzje podjęte przed pierwszym wywołaniem API przesądzają o tym, czy migracja zajmie cztery miesiące czy dziewięć: VTEX IO vs. Legacy storefront, headless vs. FastStore oraz stopniowe przełączanie ruchu vs. twarde uruchomienie w dniu startu.

Na podstawie naszych doświadczeń z wycenianiem migracji do VTEX dla mid-marketowych i enterprise'owych sprzedawców na Magento wiemy, że typowy sklep posiada od 20 do 60 rozszerzeń, a 30-40% z nich nie ma bezpośredniego odpowiednika w VTEX, to właśnie ta luka determinuje harmonogram bardziej niż wolumen danych. Co przenosi się bezproblemowo: katalog (przez VTEX Catalog API), dane klientów i treści CMS. Co się psuje lub wymaga niestandardowej pracy: logika biznesowa uzależniona od rozszerzeń, zagnieżdżone wzorce URL w Magento (wymagające pełnego audytu mapowania przekierowań 301 przed przełączeniem) oraz historia zamówień, VTEX nie traktuje jej jako aktywnych danych transakcyjnych, historyczne zamówienia migrują jako archiwum tylko do odczytu, a nie do aktywnego OMS (VTEX Community, Importing historical and in-flight orders when migrating to VTEX). Rozszerzone wsparcie dla Adobe Commerce 2.4.5 kończy się 11 sierpnia 2026 roku, zgodnie z oficjalną dokumentacją cyklu życia wydań Adobe, jeśli Twój sklep działa na tej wersji, decyzja o sekwencjonowaniu jest już pilna.

Trzy decyzje do podjęcia w pierwszej kolejności:

1. VTEX IO vs. Legacy, IO to obecne środowisko developerskie; Legacy wymaga własnej zaplanowanej ścieżki migracji wewnątrz VTEX.
2. Headless vs. FastStore, headless daje Twojemu zespołowi pełną kontrolę nad frontendem przez VTEX IO; FastStore to zarządzana opcja storefront z krótszym czasem wdrożenia, lecz mniejszą elastycznością.
3. Stopniowe przełączenie vs. twarde uruchomienie, podejście stopniowe pozwala zwalidować integrację z VTEX Catalog API i mapowanie przekierowań 301 pod realnym ruchem, zanim całkowicie wygasisz Magento. Każda z tych decyzji odzwierciedla szersze wyzwanie modernizacji bez przerywania działalności, problem sekwencjonowania dotyczy migracji platform na każdą skalę.

Dlaczego zespoły odchodzą od Magento teraz: daty EOL i ryzyko PCI

Rozszerzone wsparcie dla Adobe Commerce 2.4.5 kończy się 11 sierpnia 2026 roku, tego samego dnia, co regularne wsparcie dla wersji 2.4.6 (Adobe Commerce - Experience League (Release Versions)). Zespoły, które po tej dacie nadal korzystają z którejkolwiek z tych wersji, eksploatują nieobsługiwaną platformę, dla której nie będą już publikowane łatki bezpieczeństwa.

Polityka cyklu życia oprogramowania Adobe Commerce wyznacza te terminy bez niedomówień: rozszerzone wsparcie dla wersji 2.4.4 skończyło się już 14 kwietnia 2026 roku. Sprzedawcy korzystający z Magento Enterprise (Adobe Commerce) 2.4.5 lub 2.4.6 mają teraz tygodnie, nie kwartały, zanim znajdą się w strefie bez wsparcia. Magento 1 jest w pełni na końcu cyklu życia od 30 czerwca 2020 roku, bez łatek, bez wyjątków (Adobe, Support for Magento 1 software ends June 30, 2020).

Wymiar PCI DSS sprawia, że trudno to odkładać na później. PCI Security Standards Council jest jednoznaczna: uruchamianie oprogramowania, które nie otrzymuje już łatek bezpieczeństwa, w środowisku danych posiadaczy kart wymaga wdrożenia kontroli kompensacyjnych lub usunięcia podatności. Pozostanie na nieobsługiwanej wersji Magento nie powoduje automatycznie niepowodzenia audytu QSA, ale tworzy udokumentowaną lukę, którą Twój bank przejmujący i QSA będą chcieli zamknąć.

Obraz kosztów wsparcia generuje dodatkową presję. Backportowanie poprawek bezpieczeństwa i utrzymywanie niestandardowych mostków rozszerzeń dla nieobsługiwanego rdzenia Magento nie tanieje, koszty narastają. Migracja do VTEX zaplanowana teraz, z perspektywą sierpniowej bramy 2026, może być właściwie zwymiarowana i zsekwencjonowana, zamiast przeprowadzana pod przymusem.

Magento vs. VTEX: architektura, hosting, TCO i możliwości headless

VTEX to w pełni zarządzana platforma SaaS: nie ma provisjonowania serwerów, cyklu łatania Magento Enterprise ani kontraktu hostingowego do negocjowania. Ta jedna zmiana architektoniczna zmienia kalkulację całkowitego kosztu posiadania bardziej, niż większość zespołów spodziewa się przed rozpoczęciem wyceny migracji do VTEX.

Model self-hosted lub cloud-hosted Magento przekazuje odpowiedzialność za infrastrukturę Twojemu zespołowi: przypinanie wersji PHP, konfiguracja Redis, klastry Elasticsearch i rozszerzenia wypełniające luki w podstawowej funkcjonalności. Typowy sklep na Magento posiada od 20 do 60 zainstalowanych rozszerzeń, z naszego doświadczenia w audytowaniu sklepów przed migracją wynika, że 30-40% z nich nie ma bezpośredniego odpowiednika w VTEX, co oznacza, że porównanie TCO musi uwzględniać koszt odbudowania tej logiki, a nie tylko przełączenia platformy. Zarządzanie tym przejściem infrastruktury bez przerwy w działaniu to samo w sobie wyzwanie, zespoły migrujące przy równoczesnym prowadzeniu sprzedaży powinny przed finalizacją planu przełączenia zapoznać się ze sprawdzonymi podejściami do utrzymania ciągłości działania podczas migracji.

VTEX IO, chmurowa platforma developerska VTEX, to miejsce, w którym ta odbudowa następuje. VTEX IO działa na własnościowym frameworku (oparty na TypeScript, React na frontendzie) i zastępuje model rozszerzeń/modułów aplikacjami wdrażanymi na własnej infrastrukturze VTEX, bez oddzielnego kontraktu CDN, bez orkiestracji kontenerów. Dla zespołów potrzebujących w pełni oddzielonego frontendu VTEX FastStore to headlessowy framework storefront: warstwa oparta na Next.js, połączona z commerce API VTEX, zbudowana jako zestaw narzędzi Jamstack specjalnie z myślą o osiąganiu wskaźników Core Web Vitals, których szablony Magento Legacy rzadko spełniają od razu po instalacji.

Praktyczny kompromis: VTEX IO przyspiesza iteracje storefront, ale wymaga nauczenia się specyficznego dla platformy łańcucha narzędzi. Zespoły obeznane z React i GraphQL adaptują się szybko; zespoły z głęboką wiedzą o PHP i rozszerzeniach Magento stają przed bardziej stromą ścieżką przejścia. Naszym zdaniem eliminacja narzutu infrastrukturalnego uzasadnia koszt przekwalifikowania dla większości sprzedawców mid-marketowych, szczególnie tych zagrożonych sierpniową bramą wsparcia Adobe Commerce 2026.

Co faktycznie migruje: obsługiwane encje, ograniczenia i kroki ręczne

Nie wszystkie dane Magento mają czystą ścieżkę do VTEX: wiedza o tym, które encje migrują przez API, które wymagają transformacji, a które ręcznej obsługi, to pierwszy krok w precyzyjnym zwymiarowaniu projektu.

Luka w zestawach atrybutów to najbardziej niedoceniany problem mapowania. Zestawy atrybutów w Magento to płaskie, konfigurowalne kolekcje atrybutów EAV. VTEX organizuje odpowiadające im metadane jako Specyfikacje pogrupowane w Grupy Specyfikacji, przypisane na poziomie kategorii, to strukturalnie inny model. Z naszego doświadczenia przy określaniu zakresu migracji dla merchantów z segmentu mid-market wynika, że każdy zestaw atrybutów Magento wymaga ręcznego zmapowania na Grupę Specyfikacji VTEX, zanim będzie można utworzyć choćby jeden rekord encji SKU.

Historia zamówień wymaga osobnej decyzji: potraktuj ją jako problem integralności danych i raportowania, a nie migrację OMS. Zalecamy wyeksportowanie rekordów zamówień z Magento do archiwum tylko do odczytu, hurtowni danych lub warstwy BI, i udostępnienie ich przez narzędzia obsługi klienta, a nie importowanie do aktywnego grafu zamówień VTEX, który jest zaprojektowany wyłącznie do bieżących danych transakcyjnych.

VTEX Catalog API, ingestion: sekwencja Kategoria → Marka → Produkt → SKU

VTEX Catalog API wymusza ścisłą kolejność wstawiania danych od rodzica do dziecka: musisz najpierw utworzyć Kategorię, potem Markę, następnie Produkt, a dopiero na końcu SKU. Do utworzenia produktu wymagane są prawidłowe pola CategoryId i BrandId, API nie obsługuje rozwiązywania odroczonych referencji (VTEX Developers, Managing products).

Sekwencja odpowiada trzem odrębnym wywołaniom endpointów na developers.vtex.com:

1. `POST /api/catalog/pvt/category`, najpierw zbuduj drzewo kategorii; VTEX używa identyfikatorów całkowitoliczbowych, nie slug-ów, więc całą hierarchię zestawów atrybutów Magento trzeba przed zapisem jakiegokolwiek rekordu produktu przemapować na identyfikatory kategorii VTEX.
2. `POST /api/catalog/pvt/brand`, marki to w VTEX płaska lista, bez zagnieżdżania; atrybuty producenta z Magento trafiają tu bez komplikacji.
3. `POST /api/catalog/pvt/product`, wymaga brandId i categoryId uzyskanych w dwóch poprzednich krokach.
4. `POST /api/catalog/pvt/product/{productId}/sku`, tworzenie SKU odwołuje się do nadrzędnego productId.

Pośrednicząca warstwa transformacji danych jest niezbędna. Model zestawów atrybutów Magento, gdzie zestaw atrybutów dla odzieży zawiera specyfikacje rozmiaru i koloru, których nie ma zestaw dla sprzętu, nie ma bezpośredniego odpowiednika w strukturze arkuszy specyfikacji VTEX. Warstwa pośrednicząca musi przetłumaczyć każdy zestaw atrybutów Magento na Grupy Specyfikacji i Pola VTEX, zanim ładunek produktu będzie prawidłowy.

Z naszego doświadczenia przy migracji merchantów z segmentu mid-market wynika, że tłumaczenie zestawów atrybutów to etap, na którym importy katalogu zatrzymują się na produkcji. Zespoły, które przed uruchomieniem pełnego importu produktów weryfikują kompletność grup specyfikacji na koncie stagingowym, znacząco obniżają wskaźnik błędów w partiach. Pełną hierarchię encji VTEX Catalog API, w tym arkusze specyfikacji i załączniki SKU, omawiamy w naszym przewodniku po integracji PIM–VTEX.

Migracja historii zamówień: wzorzec archiwum tylko do odczytu

Migracja archiwum historii zamówień do VTEX OMS działa jako wzorzec raportowania tylko do odczytu, a nie jako aktywny import transakcyjny, zrozumienie tej różnicy pozwala uniknąć kosztownej przebudowy architektury w połowie projektu.

VTEX OMS traktuje każdy rekord zamówienia jako aktywną encję w swoim automacie stanów realizacji. Wstrzyknięcie historycznych zamówień z Magento do tego aktywnego strumienia wywołałoby zdarzenia workflow, przeliczenia stanów magazynowych i hooki powiadomień dla danych, które zostały już zrealizowane. Integralność potoku OMS zależy od tego, by zamówienia trafiały do systemu przez standardowy checkout lub API do tworzenia zamówień, nie przez masowy import tylnym wejściem.

Wzorzec, który stosujemy przy migracjach Magento Enterprise, to równoległe archiwum: eksportujemy historię zamówień z Magento do warstwy tylko do odczytu (dedykowanej bazy danych lub hurtowni danych), a następnie udostępniamy ją uwierzytelnionym klientom przez niestandardową aplikację VTEX IO lub lekki proxy API. Klienci widzą pełną historię zamówień przez spójny interfejs sklepu; VTEX OMS nigdy jej nie dotyka.

W warstwie dostępu dla klientów niestandardowa aplikacja odpytuje archiwum po customerId, renderuje minione zamówienia z datą, pozycjami i statusem, a następnie prezentuje je obok natywnych zamówień VTEX na ujednoliconej stronie historii zamówień. Kluczem łączącym jest zazwyczaj adres e-mail, walidowany w odniesieniu do rekordów zaimportowanych przez VTEX Customer Data, co zapewnia czystość dopasowania tożsamości.

Strategia przekierowań SEO: eksport slug-ów, budowa mapy i przesyłanie do GSC

Mapowanie przekierowań 301 to krok najbardziej krytyczny dla ruchu w każdej migracji do VTEX, a struktura URL Magento tworzy specyficzne rozbieżności, których generyczne narzędzia do przekierowań nie wychwycą automatycznie.

Magento przechowuje klucze URL niezależnie na poziomie produktu i kategorii, generując wzorce takie jak `/category-name/product-name.html` dla PDP i `/category-name.html` dla PLP. VTEX korzysta z innej konfiguracji bindingów: URL produktów wywodzą się z drzewa działów/kategorii zdefiniowanego w Catalog API i zazwyczaj przyjmują postać `/department/category/product-name/p`. Sufiks .html znika całkowicie. Ta strukturalna różnica sprawia, że proste znajdź-i-zamień nie zadziała, przed przełączeniem potrzebujesz eksportu slug-ów pojedynczo.

Sekwencja, którą stosujemy w projektach migracji z Magento do VTEX:

1. Eksportuj klucze URL z Magento przez złączenia eav_attribute + catalog_product_entity_varchar lub przez Magento REST API (`/V1/products?fields=sku,custom_attributes`). Pobierz sligi PDP i PLP w jednym przebiegu, mieszanie ich na późniejszym etapie wydłuża QA o wiele godzin.
2. Mapuj docelowe URL-e w VTEX, porównując wyeksportowane sligi z drzewem działów i kategorii w VTEX po imporcie. VTEX generuje kanoniczne URL-e dopiero po uruchomieniu drzewa produktów, dlatego ten krok możesz zwalidować dopiero gdy dane katalogu znajdą się na miejscu.
3. Załaduj mapę przekierowań do swojego CDN lub warstwy reverse proxy (Nginx, Cloudflare Rules albo natywna aplikacja Rewriter w VTEX IO). Rewriter sprawdza się przy pojedynczych nadpisaniach URL w mniejszych mapach; przy dużych migracjach z tysiącami reguł przekierowań obsługa na poziomie CDN pozwala uniknąć narzutu latencji związanego z kierowaniem każdego żądania przez aplikację IO.
4. Zwaliduj próbkę, minimum 5% URL-i o wysokim ruchu, przed przełączeniem DNS. Sprawdź zarówno kod odpowiedzi (301, nie 302), jak i poprawność docelowego URL.
5. Prześlij zaktualizowaną mapę witryny do Google Search Console w ciągu 24 godzin od przełączenia. Ponowne przesłanie mapy witryny w GSC sygnalizuje indeksowi, by ponownie przeszedł nową strukturę URL; bez tego na stronach objętych migracją możesz spodziewać się wahań pozycji przez dwa do czterech tygodni.

Schemat, który obserwujemy regularnie: sklepy Magento Enterprise, które korzystały z niestandardowych przepisań URL przez tabelę url_rewrite, niosą ze sobą łańcuchy przekierowań, strona PDP reorganizowana w połowie cyklu życia może wymagać trzech lub czterech skoków przed rozwiązaniem adresu. Wyeksportuj i wyczyść te łańcuchy przed zbudowaniem mapy VTEX, w przeciwnym razie wbudujesz je w nową konfigurację przekierowań i po migracji zwiększysz latencję ładowania strony.

Ogólne zasady mapowania przekierowań, w tym sposób priorytetyzowania URL-i według poziomu ruchu organicznego oraz synchronizowania walidacji przekierowań z etapowym przełączaniem, znajdziesz w naszym przewodniku po modernizacji sklepów internetowych.

Audyt niestandardowych rozszerzeń: Tworzenie rejestru luk funkcjonalnych przed startem

Audyt niestandardowych rozszerzeń Magento to pierwsza konkretna analiza, której potrzebuje Twoja migracja do VTEX, bez niej ryzyko scope'u pozostaje niewidoczne aż do momentu przełączenia.

Na podstawie doświadczeń z migracją sklepów Magento i Magento Enterprise segmentu mid-market wiemy, że typowa instalacja zawiera od 20 do 60 rozszerzeń. Mniej więcej 30-40% z nich nie ma bezpośredniego odpowiednika w VTEX, nie dlatego, że VTEX tej funkcjonalności nie posiada, ale dlatego że leży ona w innej warstwie architektury: często jest wbudowana w rdzeń platformy lub obsługiwana przez aplikacje VTEX IO zamiast modułów zewnętrznych.

Każdy wynik audytu strukturyzujemy jako rejestr luk z czterema kolumnami:

Cztery możliwe działania to: natywna funkcja VTEX (bez developmentu), aplikacja VTEX IO (z marketplace lub własna aplikacja IO), przebudowa (tworzenie od podstaw) i wycofanie (funkcjonalność, której utrzymanie nie jest już uzasadnione). Rozszerzenia trafiające do kolumny przebudowy odpowiadają za większość odchyleń budżetowych przy migracji, zidentyfikuj je zanim zatwierdzisz zakres, a nie po pierwszym przeglądzie sprintu.

W praktyce kolumna przebudowy ujawnia przewidywalne kategorie. Niestandardowe konektory ERP oparte na SOAP, zbudowane dla starszych systemów Oracle ATG lub przestarzałych systemów zarządzania zamówieniami, rzadko dają się czysto odwzorować na model API-first oparty na REST w VTEX i niemal zawsze wymagają przebudowy middleware. Kolejny powtarzający się przykład to moduły inwentaryzacji wielomagazynowej: rozszerzenia Magento obsługujące logikę split-fulfillment często powielają funkcje, które VTEX obsługuje natywnie przez swój framework logistyczny, co oznacza, że rozszerzenie nadaje się do wycofania, a nie przebudowy, ale zespoły odkrywają to dopiero podczas audytu.

Trzecia powszechna kategoria to workflow wycen B2B zbudowane jako niestandardowe rozszerzenia Magento, które powstały zanim VTEX wprowadził natywny pakiet B2B. W typowym audycie migracji z Magento do VTEX same te rozszerzenia odpowiadają za od jednej do trzech pozycji w kolumnie przebudowy, z których każda niesie szacunek od czterech do ośmiu tygodni developmentu. Zidentyfikowanie wszystkich trzech kategorii przed planowaniem sprintów to klucz do utrzymania migracji z Magento do VTEX w harmonogramie i budżecie.

Sekwencjonowanie migracji i realistyczny harmonogram projektów Magento–VTEX

Migracja z Magento do VTEX trwa od 10 do 20 tygodni end-to-end dla sklepu mid-market, a harmonogram zależy bardziej od liczby luk rozszerzeniowych niż od wolumenu katalogu.

Sklepy z mniej niż 15 niezamapowanymi lukami rozszerzeniowymi zwykle mieszczą się w przedziale 10-13 tygodni. Sklepy z 25 lub więcej lukami, częste w instalacjach Magento Enterprise, które organicznie rosły przez pięć lub sześć lat, regularnie przekraczają 18 tygodni, gdy uwzględni się prace nad transformacją danych w middleware.

Ten schemat powtarza się w projektach migracji z Magento do VTEX o podobnym stopniu złożoności. Praca z transformacją danych katalogu wprowadza własną warstwę złożoności, która nakłada się na te presje harmonogramowe, niezgodności atrybutów produktów i luki w taksonomii wymagają starannej remediacji przed importem.

Archiwum historii zamówień zasługuje na osobną linię w planowaniu. VTEX nie wczytuje historycznych zamówień jako aktywnych rekordów transakcyjnych; z naszego doświadczenia wynika, że zespoły próbujące wymusić pełny import historii zamówień do VTEX OMS w trakcie migracji tracą od dwóch do czterech tygodni na debugowanie niezgodności encji. Od początku traktujemy to jako migrację raportową tylko do odczytu: eksportujemy archiwum, walidujemy integralność danych, ładujemy je do warstwy BI i trzymamy poza przepływem zarządzania zamówieniami w VTEX. Zespoły migrujące z platform o złożonych, przestarzałych schematach zamówień, w tym Oracle ATG i podobnych enterprise'owych systemów e-commerce, napotykają tu zwielokrotniony wysiłek remediacji, ponieważ struktury historycznych danych zamówień rzadko mapują się czysto na encje VTEX bez pośredniego kroku transformacji.

Jeśli Twój sklep działa na Adobe Commerce 2.4.5, sierpniowy termin zakończenia rozszerzonego wsparcia w 2026 roku to twarda granica, a nie miękka presja (Adobe Commerce Software Lifecycle Policy). Rozszerzone wsparcie dla Adobe Commerce 2.4.5 kończy się 11 sierpnia 2026 roku, ten termin skraca fazę równoległego działania systemów, dlatego planuj maksymalnie 12 tygodni, nie 15 (Adobe Commerce - Experience League).

Jeśli Twój zespół porównuje VTEX z migracją na Shopify lub BigCommerce na etapie planowania, logika sekwencjonowania opisana tutaj dotyczy wyłącznie VTEX. Ogólny framework stopniowego przełączania, którego używamy na różnych platformach, znajdziesz w naszym przewodniku po modernizacji starszych platform e-commerce.

Listy kontrolne przed migracją i po przełączeniu

Traktuj obie listy kontrolne jako kryteria bramkowe, żaden etap nie może ruszyć do przodu, dopóki nie zaznaczysz każdego punktu.

Przed migracją: audyt źródłowy i konfiguracja środowiska VTEX

• [ ] Audyt rozszerzeń zakończony, skataloguj wszystkie rozszerzenia Magento (typowy sklep ma ich 20-60); oznacz te 30-40%, które nie mają bezpośredniego odpowiednika w VTEX, jako wymagające niestandardowego wdrożenia lub usunięcia
• [ ] Eksport slugów URL z Magento, wyeksportuj pełną strukturę URL (kategorie, produkty, strony CMS), aby opracować mapowanie przekierowań 301; zweryfikuj wzorce przed budowaniem reguł przekierowań
• [ ] Hierarchia encji katalogu zmapowana, potwierdź kolejność Kategoria → Marka → Produkt → SKU wymaganą przez VTEX Catalog API przed rozpoczęciem jakiegokolwiek importu (zob. mechanika VTEX Catalog API)
• [ ] Eksport danych klientów zweryfikowany, wyeksportuj rekordy klientów w formacie zgodnym z importem VTEX Customer Data; sprawdź mapowanie pól PII oraz zgodność z RODO i PCI DSS przed transferem
• [ ] Decyzja o archiwizacji historii zamówień podjęta, potwierdź, że zamówienia migrują jako archiwum tylko do odczytu, a nie jako aktywne dane OMS; określ docelowe miejsce raportowania (hurtownia danych, narzędzie BI lub niestandardowa aplikacja VTEX)
• [ ] Okno zgodności z PCI DSS potwierdzone, jeśli nadal korzystasz z Magento 2.4.5 lub 2.4.6, pamiętaj, że rozszerzone wsparcie kończy się 11 sierpnia 2026 r.; nieaktualne oprogramowanie w środowiskach przetwarzających dane posiadaczy kart stwarza natychmiastowe ryzyko w zakresie PCI DSS
• [ ] Workspace VTEX IO skonfigurowany, środowiska deweloperskie i stagingowe utworzone; pipeline CI/CD podłączony
• [ ] Wzorce migracji z Shopify, BigCommerce lub Volusion przejrzane (jeśli dotyczy), jeśli sklep był wcześniej migrowany z innej platformy, przenieś istniejące łańcuchy przekierowań zamiast budować je od nowa

Po migracji: bramki QA przed przekazaniem ruchu

• [ ] Mapa przekierowań 301 aktywna i przetestowana, sprawdź wyrywkowo 50 najczęściej odwiedzanych URL z Magento względem tras w VTEX; zero błędów 404 na stronach z przychodzącymi linkami
• [ ] Przesłanie mapy witryny do Google Search Console, prześlij zaktualizowaną mapę XML w ciągu 24 godzin od przełączenia DNS; monitoruj błędy indeksowania przez 72 godziny po uruchomieniu
• [ ] Liczba encji VTEX Catalog API uzgodniona, liczba produktów, SKU i kategorii w VTEX odpowiada eksportowanym danym z Magento; oznacz rozbieżności przed odebraniem dostępu do odczytu Magento
• [ ] Import VTEX Customer Data zweryfikowany, sprawdź wyrywkowo 50-100 rekordów klientów; potwierdź poprawność logowania, zapisanych adresów i widoczności historii zamówień
• [ ] Przepływ płatności i checkout przetestowany end-to-end, przeprowadź prawdziwą transakcję w środowisku produkcyjnym przed pełnym przełączeniem ruchu
• [ ] Ponowna atestacja PCI DSS zaplanowana, potwierdź, że nowe środowisko VTEX jest objęte zakresem kolejnej oceny QSA; formalnie usuń infrastrukturę Magento ze środowiska przetwarzającego dane posiadaczy kart
• [ ] Archiwum historii zamówień dostępne, potwierdź, że dane zamówień tylko do odczytu są dostępne dla zespołu obsługi klienta przed wycofaniem Magento

Najczęściej zadawane pytania

Gotowy, by określić zakres migracji z Magento do VTEX?

Niestandardowy audyt rozszerzeń Magento to właściwy punkt wyjścia każdej migracji do VTEX: zanim zaczniesz pracować nad importem katalogu, danymi klientów czy zakresem budowy storefront w VTEX IO, potrzebujesz przejrzystego rejestru luk pokazującego, które rozszerzenia Twojego sklepu nie mają bezpośredniego odpowiednika w VTEX i które wymagają niestandardowego pomostu. Z naszego doświadczenia wynika, że to właśnie ten audyt kształtuje wszystkie kolejne decyzje dotyczące kolejności działań.

Jeśli Twój zespół korzysta z Adobe Commerce 2.4.5, a termin zakończenia wsparcia w sierpniu 2026 r. zbliża się nieuchronnie, albo rozważasz VTEX w porównaniu z Shopify, BigCommerce lub Volusion, pomożemy Ci określić, czego naprawdę wymaga czysta migracja: katalog, archiwum historii zamówień, mapowanie przekierowań 301 i wszystko inne. Porozmawiaj z naszym zespołem, by zweryfikować dane migracyjne i harmonogram.