Come migrare da Magento a Shopify Plus: dati, moduli e trappole

Una migrazione da Magento non è una migrazione qualunque. Il metodo generale, quello che vale per qualsiasi piattaforma di partenza, è lo stesso: si mappano i contenuti, si censiscono le funzioni, si decide cosa si porta e cosa cade. Ma quando l'origine è Magento o Adobe Commerce ci sono strutture che non hanno un corrispettivo dall'altra parte, e sono proprio quelle a far saltare i progetti.

Questo articolo parla solo di ciò che è specifico di Magento. Il metodo generale, con il censimento dei servizi e la mappatura dell'architettura, lo trovi nella guida su come si organizza una migrazione ecommerce, e non lo ripetiamo qui. Qui si entra nelle entità, nei moduli e nelle trappole di quella piattaforma, una per una.

Il momento in cui il progetto si decide non è il giorno del lancio: è la settimana in cui qualcuno apre il database di Magento e si accorge di cosa c'è dentro davvero.

Perché una migrazione da Magento non somiglia a nessun'altra

Magento è nato per essere estensibile all'infinito, e le aziende hanno preso quella promessa alla lettera. Il risultato, dopo dieci anni, è quasi sempre lo stesso: un modello dati con centinaia di attributi, decine di moduli di fornitori diversi, regole di prezzo stratificate, e nessuno in azienda che sappia ancora dire a cosa serviva la metà di quella roba.

Il modello dati di Magento si chiama EAV, entity-attribute-value: significa che un prodotto non ha un numero fisso di campi, ma tanti quanti gliene sono stati creati, raggruppati in attribute set diversi per tipo di prodotto. È la ragione della sua flessibilità, ed è anche la ragione per cui non esiste una traduzione automatica verso il modello di Shopify, che è più rigido per scelta.

Da qui nasce il vero lavoro. Migrare da Magento non è esportare e importare: è decidere, entità per entità, cosa quella struttura significava per il business e come lo si ottiene su una piattaforma costruita in un altro modo. Le pagine che seguono sono la mappa di quelle decisioni.

Il modello dei dati: cosa non si traduce uno a uno

Attributi, attribute set e il muro delle tre opzioni

È la trappola numero uno, e quasi nessuno la nomina in fase di preventivo. Su Magento un prodotto configurabile può avere un numero arbitrario di attributi configurabili: taglia, colore, materiale, vestibilità, lunghezza, finitura. Su Shopify le opzioni per prodotto sono al massimo tre. Il limite delle varianti è stato alzato a 2.048 nell'ottobre 2025, contro le cento storiche, ma il tetto delle tre opzioni non si è mosso.

Tradotto: un catalogo Magento con quattro o cinque attributi configurabili non entra nel modello nativo di Shopify. Le strade sono tre, e vanno scelte prima di scrivere una riga di import. Si accorpano le opzioni, e allora la scelta ricade sulla struttura del catalogo. Si spezza il prodotto in più prodotti collegati fra loro, e allora cambia l'architettura delle schede e con essa la SEO. Oppure si porta la variabile eccedente fuori dalle opzioni, con un'app di configurazione o con proprietà di riga: e allora cambia il modo in cui l'ordine arriva al gestionale.

Tutti gli attributi che non sono configurabili, invece, atterrano nei metafield. Non c'è una regola automatica: gli attributi che descrivono il prodotto diventano metafield, quelli che servivano solo a pilotare la layered navigation vanno riconsiderati insieme ai filtri, e quelli che non usa più nessuno vanno buttati. Su un catalogo Magento maturo, la quota di attributi da buttare è quasi sempre superiore a quella che l'azienda immagina.

Un vincolo minore ma insidioso: Shopify tiene al massimo 250 file multimediali per prodotto. Su cataloghi fashion con molte varianti fotografate singolarmente, quel tetto si tocca.

Categorie e collezioni

Le categorie di Magento sono un albero, con l'anagrafica del prodotto che dichiara a quali nodi appartiene. Le collection di Shopify sono liste, manuali o automatiche in base a condizioni sul prodotto. Non c'è una gerarchia nativa: il menu la simula, ma il sistema non la conosce.

La conseguenza operativa è che una tassonomia Magento a quattro o cinque livelli va ripensata, non trasferita. Le collection automatiche coprono bene i casi in cui l'appartenenza deriva da un attributo, ed è la scelta giusta ogni volta che il criterio è esprimibile come regola. Dove la gerarchia era usata per governare le regole di prezzo o le promozioni, invece, la logica si sposta altrove, e va riprogettata.

Clienti e gruppi clienti

Su Magento un cliente appartiene a un customer group, e il customer group pilota prezzi, promozioni, tasse e visibilità del catalogo. È il meccanismo che regge quasi tutti i B2B costruiti su quella piattaforma, e anche molti listini riservati sul B2C.

Su Shopify il concetto non esiste come tale. Il B2B ha un impianto proprio, fatto di company, location e cataloghi con listini dedicati, mentre sul B2C le segmentazioni si ottengono con i tag cliente e con le regole di sconto. È un modello diverso, e in molti casi più pulito, ma non è una traduzione: è una riprogettazione. Il momento in cui conviene affrontarla è la discovery, non l'import.

Ordini e storico

Qui sta il malinteso che genera più discussioni a progetto avviato. Un ordine su Magento è un oggetto vivo, con i suoi stati, le sue fatture, le sue spedizioni, le sue note a mano accumulate negli anni. Su Shopify lo storico si importa, ma arriva come dato storico: gli ordini migrati non tornano dentro il ciclo di vita della nuova piattaforma, non si rifatturano, non si rispediscono.

Non è un limite tecnico da aggirare, è una scelta di architettura da fare consapevolmente. La domanda da porsi non è quanti anni di ordini si riesce a portare, ma a cosa serve lo storico: se serve al cliente per rivedere i suoi acquisti nell'area riservata, la migrazione basta; se serve all'assistenza per gestire resi e garanzie su ordini vecchi, allora quel processo va tenuto dov'è o portato nel gestionale, che è il posto in cui doveva stare fin dall'inizio.

Sugli stati d'ordine custom, poi, la regola è secca: gli stati che qualcuno aveva aggiunto a Magento per governare un flusso interno non esistono su Shopify. Vanno riportati a tag, a flussi di Flow o al gestionale. È un lavoro di analisi, non di import.

Contenuti: CMS page, CMS block e Page Builder

Le pagine CMS di Magento si portano senza drammi. I CMS block, quei frammenti riutilizzabili che negli anni sono finiti dentro categorie, home page e schede prodotto, sono un'altra storia: su Shopify il concetto corrispondente si costruisce con le section riutilizzabili e con i metaobject, e la mappatura va fatta a mano, blocco per blocco.

Chi ha usato Page Builder deve mettere in conto una riscrittura. Il contenuto prodotto da Page Builder è markup con una struttura propria: si può estrarre, ma non si può reimpiantare. Su Shopify quel contenuto va ricostruito con le section del tema, e l'occasione giusta per farlo è mentre si ridisegna il tema, non dopo.

URL rewrite e redirect

Magento tiene le URL in una tabella di rewrite che, su uno store con anni di vita, contiene tipicamente decine di migliaia di righe: le URL correnti, quelle vecchie che redirigono alle nuove, e i residui di ogni cambio di categoria fatto da chiunque, anni fa. È il patrimonio SEO dell'azienda, ed è anche il posto in cui si nasconde il caos.

Su Shopify la struttura delle URL è fissa, con i suoi prefissi per prodotti, collezioni e pagine, e i redirect si caricano come elenco. Il lavoro, quindi, non è tecnico: è di selezione. Bisogna capire quali di quelle decine di migliaia di URL portano ancora traffico e link, e mandare in redirect quelle. Le altre non vanno portate: allungano l'elenco e non servono a nulla.

Il punto che merita più attenzione è la coda lunga generata dalla layered navigation. Su Magento i filtri producono indirizzi navigabili e, se non governati, indicizzabili; su Shopify i filtri restano parametri sulla stessa collezione, che i temi ufficiali canonicalizzano verso la collezione base, quindi non nascono come pagine di atterraggio autonome. Se quelle pagine portavano traffico, quel traffico non si sposta con un redirect: va ricostruito con collection dedicate. È il capitolo più delicato di tutta la migrazione, va affrontato prima di scegliere la struttura del catalogo e non dopo, e come si governa la SEO in una migrazione lo abbiamo scritto per esteso.

La struttura multi-store: website, store, store view

Magento ha tre livelli, e chi ha più mercati o più marchi li ha usati tutti: il website, che porta con sé il proprio scope dei prezzi e il proprio pool di clienti; lo store, con il suo albero di categorie; la store view, con la sua lingua e la sua valuta. Tutto in una sola installazione.

Su Shopify quella gerarchia si scompone su due strumenti diversi, e la scelta fra i due è una decisione di architettura con conseguenze economiche. Shopify Markets copre lingue, valute, prezzi e cataloghi per paese dentro un solo negozio, ed è la scelta giusta per un marchio che vende in più mercati. Gli expansion store, invece, sono negozi separati: il contratto Plus ne include nove oltre a quello principale, e ogni negozio ulteriore costa 300 dollari al mese secondo il listino pubblicato da Shopify.

La regola che sorprende chi arriva da Magento riguarda i marchi: il contratto Plus copre un brand, e più marchi sotto la stessa azienda richiedono contratti separati. Un gruppo che su Magento teneva tre marchi dentro una sola installazione, su Shopify avrà tre contratti. È un dato che va nel calcolo del costo totale, non nella nota a piè di pagina.

I moduli che non hanno un corrispettivo

Il censimento dei moduli è il momento più utile di tutta la discovery, e quasi sempre il più imbarazzante. Su uno store Magento maturo si trovano tre categorie di estensioni: quelle che fanno qualcosa che Shopify fa già di suo, quelle che hanno un'app corrispondente sullo store, e quelle che non hanno un corrispettivo e vanno sviluppate o abbandonate. La prima categoria è di gran lunga la più numerosa, ed è la ragione per cui una migrazione ben fatta consegna un sistema più leggero di quello di partenza.

Le famiglie che tipicamente non trovano corrispettivo sono poche e sempre le stesse. I moduli per i feed prodotto, che su Magento generavano i file per i comparatori e per i canali pubblicitari, su Shopify non servono nella stessa forma: il feed passa da un canale di vendita che sincronizza direttamente con la piattaforma di destinazione. Chi aveva costruito feed su misura, con regole di mappatura sofisticate, deve rifare quel lavoro dentro le regole del canale o con un'app.

Poi ci sono le regole di prezzo. Le catalog price rule e le cart price rule di Magento sono un motore a regole con condizioni annidate, e su uno store vissuto ce ne sono spesso decine, molte delle quali scadute e mai cancellate. Su Shopify una parte diventa sconto nativo, un'altra parte diventa Shopify Functions, cioè logica di sconto scritta a codice ed eseguita dentro il checkout. La domanda giusta durante il censimento non è come replico questa regola, ma questa regola serve ancora.

Infine le integrazioni con il gestionale. Un connettore ERP scritto per Magento non si riusa: parla con il modello dati di Magento. Il flusso, però, si riprogetta con gli stessi contratti di dato, ed è esattamente il punto in cui un partner che quelle integrazioni le ha già fatte decine di volte vale il suo prezzo, perché conosce i casi limite prima che si presentino.

Le trappole tipiche di Magento

Sono ricorrenti, e chi ha già fatto questo percorso le riconosce al primo sguardo sul database.

Gli attributi fantasma. Su ogni Magento maturo esistono attributi creati per un progetto morto anni fa, popolati a metà, che nessuno usa e nessuno cancella. Portarli dentro i metafield significa portare il disordine da una parte all'altra. Vanno contati, e vanno buttati.

Le anagrafiche sporche. Clienti duplicati, indirizzi senza provincia, partite IVA nel campo sbagliato, gruppi assegnati a mano da qualcuno che non lavora più in azienda. L'import non pulisce niente: se i dati entrano sporchi, escono sporchi, ma con l'aggravante che adesso sono sporchi su una piattaforma nuova, e la colpa sembra della piattaforma.

Gli SKU incoerenti. Su Magento nulla impedisce a un configurabile e ai suoi semplici di seguire logiche di codifica diverse. Su Shopify lo SKU è la chiave con cui il gestionale riconosce la variante: se la codifica è incoerente, il connettore lo scopre in produzione, che è il momento peggiore.

Il custom nel core. Le personalizzazioni scritte direttamente dentro i moduli invece che in moduli propri sono la ragione per cui molti store Magento sono rimasti fermi a versioni vecchie: aggiornare significava rompere. In una migrazione quel codice non si porta, ma va letto, perché è lì che spesso è finita la logica di business che nessuno ha mai documentato.

Gli indexer e la cache. Non è un problema di migrazione, è un problema di aspettative: chi arriva da Magento è abituato a un sistema in cui il catalogo va reindicizzato e la cache va scaldata. Su Shopify quel lavoro non c'è, e la conseguenza pratica è che una parte delle procedure interne del team, e delle persone che le eseguivano, non serve più. Vale la pena dirlo prima, non dopo.

Cosa fare prima di toccare un dato

L'ordine delle operazioni non è negoziabile, e in una migrazione da Magento è il seguente. Prima si conta: quanti prodotti, quanti attributi per attribute set, quanti sono davvero usati, quanti configurabili hanno più di tre attributi, quante regole di prezzo sono attive, quante URL portano ancora traffico. Sono numeri che si estraggono dal database e da Search Console in mezza giornata, e cambiano il perimetro del progetto.

Poi si decide cosa non si porta. È la decisione che fa risparmiare più tempo e più soldi di qualunque altra, ed è anche l'unica che nessuno prende volentieri, perché ogni attributo e ogni modulo hanno un padrino dentro l'azienda. Serve qualcuno che dica no.

Solo a questo punto si mappa. E si mappa su un ambiente di prova, con un ciclo di verifica dato per dato, perché un import che non restituisce errori non è un import andato a buon fine: è solo un import che non ha restituito errori.

Chi è già passato da Magento a Shopify Plus

Il modo più rapido per togliere drammaticità a un replatforming è guardare chi l'ha già fatto, partendo dallo stesso punto.

Il Bisonte, marchio di pelletteria di lusso, è passato da Magento a Shopify Plus con un tema su misura allineato all'esperienza precedente e una integrazione dati completa. Ballerette ha lasciato Magento con un obiettivo dichiarato: una tecnologia stabile, facile da implementare e senza limiti di scalabilità. Quellogiusto, riferimento nel retail di calzature e accessori del Nordest, ha migrato da Magento per crescere in ottica omnichannel. TheDoubleF, l'ecommerce fashion luxury del gruppo Folli Follie, è passato da Magento a Shopify Plus. Dimensioni e settori diversi, lo stesso punto di partenza.

Il filo comune non è la voglia di cambiare: è che a un certo punto la complessità accumulata era diventata il costo principale del canale. Sulle ragioni per cui si arriva a quel punto abbiamo scritto un pezzo a parte, sulle spinte che portano a lasciare la piattaforma attuale; sulla scelta fra restare e cambiare, invece, il ragionamento sta nel pillar sul replatforming.

Domande frequenti sulla migrazione da Magento a Shopify Plus

Si può portare tutto il catalogo Magento su Shopify?

I prodotti sì, la struttura non sempre. Il vincolo che si incontra prima è quello delle tre opzioni per prodotto: un configurabile Magento con quattro o più attributi configurabili va riprogettato, accorpando le opzioni, spezzando il prodotto o portando la variabile in eccesso fuori dal modello nativo. La decisione va presa in analisi, prima dell'import.

Lo storico ordini si porta?

Si importa, ma arriva come dato storico: gli ordini migrati restano consultabili e non rientrano nel ciclo di vita della nuova piattaforma. Prima di decidere quanti anni portare conviene chiedersi a cosa serve lo storico, perché se serve per gestire resi e garanzie il posto giusto è il gestionale.

Cosa succede alle URL e ai filtri?

Le URL si rimappano con un elenco di redirect, selezionando quelle che portano ancora traffico e link. La coda lunga generata dalla layered navigation è il punto critico: su Magento i filtri producono indirizzi indicizzabili, su Shopify restano parametri canonicalizzati sulla collezione base e non diventano pagine autonome, quindi quel traffico va ricostruito con collection dedicate invece che redirezionato.

Serve rifare le integrazioni con il gestionale?

Sì. Un connettore scritto per Magento parla con il modello dati di Magento e non si riusa. Si riprogetta il flusso, mantenendo gli stessi contratti di dato: prodotti, giacenze, ordini, anagrafiche. È la parte più delicata del progetto ed è quella in cui l'esperienza di chi lo ha già fatto pesa di più.

Quanto costa migrare da Magento?

Dipende dal perimetro, e il perimetro si scopre contando quello che c'è dentro il Magento attuale, non guardando il sito: quanti attributi, quanti configurabili oltre le tre opzioni, quante regole di prezzo attive, quante URL con traffico. Un preventivo fatto senza quei numeri è un numero, non una stima.

In sintesi

Migrare da Magento non è un problema di strumenti: gli strumenti di import esistono e funzionano. È un problema di traduzione fra due modelli che non si corrispondono. Gli attributi configurabili si scontrano con il tetto delle tre opzioni, i customer group non hanno un equivalente, le regole di prezzo diventano altro, i CMS block vanno ricostruiti, la layered navigation sparisce e con lei una coda di traffico che va ripresa altrove.

Ognuna di queste è una decisione, non un'operazione. Prese in analisi costano tempo di analisi; prese durante l'import costano il progetto. La differenza fra una migrazione che funziona e una che si impantana sta quasi sempre in quante di queste decisioni sono state prese prima di toccare il primo dato.

Se non è ancora chiaro quale versione di Magento si sta lasciando, e cambia più di quanto sembri, il quadro sta nell'articolo sulle differenze fra Magento Open Source, Magento Commerce e Adobe Commerce.