← Inapoi la blog

Guides

Migrare Shopify la Magento în 2026: Ghidul în 6 Faze

18 august 2026 - de Alexandru-Manuel Carabus

Te gândești să treci de la Shopify la Magento? Iată secvența reală în 6 faze, cu termene oneste, ce se strică pe parcurs și cele două riscuri pe care aproape niciun ghid nu le menționează înainte să aloci buget și o dată de lansare.

Ilustrație geometrică abstractă cu șase platforme ascendente în nuanțe de bleumarin, teal și albastru deschis, reprezentând o secvență de migrare în etape, cu o platformă ușor decalată sugerând un pas cu risc mai mare.

Dacă ai căutat "migrare shopify la magento", probabil ai trecut deja de etapa de comparat platformele. Ai citit deja de ce Magento se potrivește mai bine decât Shopify pentru direcția în care merge afacerea ta, fie că vorbim de complexitate B2B, complexitate de catalog sau nevoia de a deține stack-ul propriu. Acum vrei să știi ce se întâmplă concret între decizie și lansare.

Răspunsul onest: nu este un proiect de weekend și nu este un plugin. O migrare Shopify la Magento este un proiect de inginerie real, cu buget real, termen real și moduri reale în care poate merge prost. Uneltele de migrare a datelor îți mută produsele și comenzile în câteva zile. Nu îți mută automat checkout-ul, funcționalitatea aplicațiilor, echitatea SEO sau încrederea clienților. Toate acestea trebuie reconstruite, deliberat, de oameni care au mai făcut asta.

Acesta este ghidul pe care l-am parcurge cu un client înainte să semneze ceva, nu versiunea de marketing. Acoperă secvența în șase faze oneste, ce se strică atunci când o fază este sărită și două riscuri care apar în aproape niciun ghid de migrare, dar pe care le-am văzut mușcând comercianți reali.

Două termene, nu unul

Fiecare estimare de migrare pe care o găsești online amestecă două proiecte foarte diferite, și de aici pornesc bugetele greșite. Separă-le de la început.

Migrarea datelor în sine (produse, clienți, istoricul comenzilor, mutate din modelul de date Shopify în cel Magento) durează între 1 și 8 săptămâni, în funcție de mărimea catalogului și de cât de curate sunt deja datele. Un catalog ordonat de 1.000 de SKU-uri cu atribute sănătoase este o chestiune de zile odată ce destinația este construită. Un catalog dezordonat de 40.000 de SKU-uri cu ani de etichetare inconsistentă este o chestiune de săptămâni, iar munca de curățare, nu transferul în sine, este ce consumă timpul.

Un replatforming complet, adică un frontend Hyvä nou, un checkout reconstruit, fiecare integrare reconectată și testată, este o altă ordine de mărime: realist, 3 până la 5 luni pentru un magazin mid-market, și 6 până la 9 luni dacă rulezi logică B2B, integrare ERP sau mai multe canale de vânzare. Dacă o ofertă pentru un replatforming complet vine semnificativ sub aceste cifre, întreabă ce se sare. Pentru partea de cost analizată mai în detaliu, articolul nostru despre costul total Shopify Plus în 2026 arată unde se duc banii de fapt pe ambele platforme.

Cele șase faze

Faza 1: Descoperire și audit de date. Înainte să se miște ceva, cineva trebuie să se uite efectiv la catalogul tău, la baza de clienți, la istoricul comenzilor și la lista de integrări, și să găsească dezordinea. Aceasta este faza pe care orice migrare grăbită o sare, și este cel mai bun predictor pentru cum va merge restul proiectului. Inconsistențele de atribute, SKU-urile duplicate, metafield-urile orfane, toate ies la suprafață aici sau ies la suprafață mai scump mai târziu, de obicei cu o săptămână înainte de lansare.

Faza 2: Mediul Magento, seturile de atribute și categoriile, construite primele. Acesta este pasul pe care majoritatea ghidurilor non-tehnice de migrare îl îngroapă sau îl omit complet, și nu este opțional. Modelul de produs Magento (EAV, entity-attribute-value) are nevoie ca seturile de atribute, categoriile și grupurile de clienți să fie definite și construite înainte ca un singur produs să fie importat, nu după. Importă date într-o structură goală și se vor mapa greșit în tăcere: atributele ajung în locul greșit, categoriile nu se aliniază corect, și nimeni nu observă până când un client reclamă că un filtru nu funcționează. Construirea formei de destinație întâi este mai lentă la început și economisește săptămâni de curățare mai târziu.

Faza 3: Migrarea datelor. Cu structura pusă la punct, produsele, clienții și istoricul comenzilor se mută. Produsele și datele structurate se mapează relativ curat. Două lucruri nu se mapează: parolele clienților și starea completă a comenzilor.

Hash-urile de parolă Shopify nu pot fi transferate unu-la-unu în Magento. Autentificarea Magento folosește propriul format de hash în mai multe părți, și nu există o cale suportată prin care să copiezi pur și simplu un șir de hash străin și acesta să valideze. Varianta onestă implicită este un reset de parolă forțat la prima autentificare, comunicat clar și, ideal, îndulcit cu un stimulent, nu impus clienților ca o surpriză. Un pod de autentificare legacy personalizat este posibil tehnic, dar este dezvoltare la comandă cu un istoric propriu de eșecuri, nu o funcție ambalată pe care orice unealtă de migrare o oferă.

Istoricul comenzilor "migrează" în sensul că valorile câmpurilor se transferă, dar structura mai plată a comenzilor Shopify nu se mapează unu-la-unu pe lanțul mai granular al Magento, comandă-factură-livrare-notă de credit. Așteaptă-te la o înregistrare de comandă recreată cu starea finală, nu la o istorie redată fidel.

Dacă tragi datele singur, nu printr-o unealtă de migrare, planifică în jurul a două limite dure: Shopify limitează exporturile CSV la aproximativ 9.000 de rânduri per fișier, iar un query de export în bloc prin GraphQL are o fereastră de execuție de 10 zile înainte ca Shopify să îl marcheze eșuat. Niciuna nu este un blocaj total, dar o extragere naivă a întregului catalog poate pur și simplu eșua pe un magazin mare fără un design de query care respectă aceste limite.

Faza 4: Construirea frontend-ului pe Hyvä. Aici magazinul devine din nou efectiv un magazin, nu doar o bază de date. Hyvä este complet gratuit și open source din 10 noiembrie 2025, ceea ce schimbă semnificativ economia acestei faze: licența de aproximativ 1.000 EUR per magazin care făcea parte din orice ofertă Hyvä a dispărut. Checkout, Commerce și nivelurile Enterprise B2B de la Hyvä rămân opțiuni plătite, deci această fază este mai ieftină decât acum un an, nu gratuită. Analiza noastră mai detaliată despre ce înseamnă această schimbare pentru un build Magento este în Hyvä devine open source în 2026.

Un lucru pe care această fază nu îl poate evita: checkout.liquid, stratul de personalizare din spatele majorității checkout-urilor Shopify Plus la comandă, a fost retras de Shopify în două termene în 2024 și 2025. Nu există cod de portat de acolo. Orice făcea checkout-ul tău Shopify personalizat trebuie respecificat ca logică de business și reconstruit de la zero pe Magento, indiferent de unealta de migrare care a mutat datele.

Faza 5: Integrări și QA. Procesatorii de plată, curierii, logica de taxe, email-ul, analytics-ul, loialitatea, abonamentele, orice rulează ca aplicație Shopify trebuie reevaluat individual. Unele au echivalente directe pe Magento. Altele nu există ca extensii Magento ambalate deloc și necesită dezvoltare la comandă. Această fază este și locul unde testezi fluxul de reset al parolei, harta de redirect-uri și fiecare traseu de checkout de la un capăt la altul, nu o singură dată, ci repetat, pentru că aceasta este faza cel mai des comprimată sub presiunea datei de lansare.

Faza 6: Trecere în etape, cu Shopify ca fallback în paralel. Nu apeși un buton într-o vineri și speri. Modelul mai sigur este o trecere în etape: lansezi noul magazin pentru un segment cu risc scăzut, ții magazinul Shopify vechi în funcțiune ca fallback, și sincronizezi comenzile și stocul bidirecțional cât timp confirmi stabilitatea, înainte să extinzi și, în cele din urmă, să dezactivezi Shopify. O variantă mai simplă și mai ieftină este să ții Shopify în funcțiune doar în citire timp de două până la patru săptămâni după lansare, ca referință de urgență, sincronizând doar activitatea cea mai recentă înapoi în Magento odată ce ești sigur. Oricum ai proceda, construiește capacitatea de a redirecționa traficul înapoi dacă ceva se strică. Aceasta este faza unde "a mers pe staging" este testată contra clienților reali și traficului real.

Ce se strică atunci când e făcut prost

Șase lucruri revin în fiecare post-mortem de migrare pe care l-am citit sau l-am trăit, și toate șase sunt evitabile cu fazele de mai sus, făcute în ordine.

Migrarea parolelor tratată ca o idee ulterioară, nu ca un flux de reset planificat și comunicat, generează tichete de suport și încredere pierdută din prima săptămână. O hartă de redirect-uri 301 tratată ca opțională, nu ca un exercițiu manual și exhaustiv de export și pereche pentru fiecare URL de produs, colecție, pagină și blog, te costă clasamentele de căutare construite în ani; așteaptă-te la fluctuații de clasament în timpul re-crawl-ului Google chiar și când e făcut bine, dar o hartă incompletă transformă fluctuația într-o scădere reală. Funcționalitatea aplicațiilor Shopify presupusă că "va merge la fel" pe Magento fără verificare prealabilă lasă goluri care ies la suprafață doar când un client se lovește de ele. Imaginile și datele de atribute ale produselor dispar sau se dezaliniază când maparea câmpurilor e grăbită, nu validată contra structurii de destinație construite în Faza 2. Nostalgia după checkout.liquid, așteptarea ca ceva din vechea logică de checkout să se transfere, irosește timp mai bine cheltuit reconstruind-o corect din prima. Iar tracking-ul de evenimente ecommerce GA4 nu se transferă deloc între platforme; trebuie reconstruit și validat pe Magento de la zero, ideal rulat în paralel cu vechiul tracking timp de o lună sau două înainte să ai încredere în cifrele noi pentru raportare.

Două riscuri despre care aproape nimeni nu vorbește

Două riscuri apar în aproape niciun ghid de migrare, și ambele pot afecta un comerciant care presupune că tranziția este pur tehnică.

Primul: webhook-urile proprii de conformitate GDPR ale Shopify pun un ceas pe datele tale pe care nu îl controlezi complet. Odată ce dezinstalezi aplicații sau închizi un magazin, temporizatoarele automate de redactare pornesc: ștergerea datelor magazinului începe la 48 de ore după dezinstalarea unei aplicații, iar redactarea datelor clienților este onorată la 10 zile după cerere pentru clienți inactivi, sau amânată până la 6 luni pentru cei recent activi. Dacă datele istorice de comenzi sau clienți nu au fost exportate complet și verificate în Magento înainte să începi să închizi partea Shopify, acestea pot intra în coliziune cu un ceas de redactare care se declanșează după programul Shopify, nu al tău.

Al doilea: reputația expeditorului de email nu călătorește odată cu schimbarea platformei. Furnizorii de servicii de internet au încredere în infrastructura de trimitere, nu în brand, deci păstrarea aceluiași domeniu vizibil de trimitere pe parcursul migrării contează mai mult decât menționează majoritatea ghidurilor. Iar odată ce rulezi pe Magento, operațiunile de securitate devin în întregime responsabilitatea ta, nu o preocupare gestionată de platformă. Vulnerabilitatea SessionReaper (CVSS 9.1) a lovit aproximativ 81 la sută din magazinele Magento cu trafic de atac în șase săptămâni de la dezvăluire, la finalul lui 2025, și a afectat Adobe Commerce și Magento Open Source în rate similare, deci nu se rezolvă plătind o licență mai scumpă. Se rezolvă prin disciplină continuă de patching. Acoperim ce presupune concret asta în lecțiile din SessionReaper, și merită citit înainte să te angajezi la găzduire proprie.

Benzi de cost, onest

Nimeni nu publică o cifră unică de încredere pentru "cât costă asta", și oricine oferă o cifră înainte de a audita catalogul și integrările tale ghicește. Modul onest de a gândi despre asta este în săptămâni-echipă și benzi de GMV, nu o cifră în euro care pretinde că fiecare migrare are aceeași formă.

O migrare pură de date pentru un catalog curat, mic până la mediu, este o chestiune de câteva săptămâni-echipă. Un replatforming complet pe un frontend Hyvä se scalează în primul rând cu numărul de integrări, nu cu mărimea catalogului: un magazin simplu cu sub 10 extensii terțe este un proiect mai mic decât un magazin mid-market cu 25 sau mai multe, sau unul cu logică B2B. GMV contează și el, mai ales prin deciziile de găzduire și nivel de suport, nu prin munca de migrare în sine. Noi rulăm acest model ca Magento Open Source plus Hyvä plus un abonament de suport dedicat, deliberat nu nivelul licențiat Adobe Commerce, ceea ce este o structură de cost semnificativ diferită, bine de înțeles înainte să compari oferte. Această distincție este acoperită în analiza noastră a costului total Shopify Plus, iar orice muncă de dezvoltare pe care o estimăm este facturată orar sub un SLA contractual, cu tariful confirmat în scris după ce am văzut efectiv magazinul tău.

De unde continui

Dacă ești la câteva săptămâni de decizie, următorul pas cu cel mai mare impact nu este alegerea unei unelte de migrare. Este auditarea catalogului, integrărilor și cerințelor de checkout de către cineva care îți va spune onest dacă acesta este un proiect de 6 săptămâni sau unul de 6 luni, înainte să te angajezi la oricare. Pentru comercianții care vin specific de pe Shopify, ruta noastră Liquid Framework New Build există exact pentru acest tip de migrare; detaliile sunt la liquidlab.ro/ro/liquid-framework. Dacă vrei argumentul mai larg pentru de ce Magento se potrivește mai bine decât Shopify pentru unele afaceri și unde nu, pornește de la ghidul nostru onest Magento vs Shopify 2026.

Programează un apel gratuit de strategie cu LIQUIDLAB și trecem împreună prin catalogul, integrările și termenul tău specific înainte să cheltuiești un euro pe unelte.