La nostra strategia per lasciare Shopify: valutare le alternative e-commerce headless
Shopify svolge molto bene il proprio lavoro. Il checkout ha un buon tasso di conversione, l’ecosistema di app è ampio e l’affidabilità operativa è eccellente. Per un commerciante che vuole vendere prodotti senza costruire un’infrastruttura, la proposta di valore è difficile da contestare. È bene dirlo chiaramente prima di spiegare perché abbiamo chiuso il nostro negozio sulla piattaforma: la decisione non dipendeva da un’inadeguatezza assoluta di Shopify, ma dalla scarsa compatibilità con le esigenze operative specifiche che avevamo accumulato.
La maggior parte dei racconti sull’abbandono di Shopify si concentra sulle commissioni di transazione, sui limiti dei temi o sul desiderio di avere una vetrina personalizzata. Sono motivi reali, ma non quelli determinanti. Il problema più profondo è che Shopify è ottimizzato per un particolare tipo di commerciante, con volumi elevati, un catalogo standardizzato e vendite dirette ai consumatori. I suoi vincoli diventano un ostacolo quando le esigenze si discostano da questo profilo.
Cosa Shopify ha fatto bene
Il checkout è la parte più solida della proposta di valore di Shopify. Anni di ottimizzazione su milioni di negozi hanno prodotto un flusso di acquisto che converte, gestisce bene i casi limite e integra metodi di pagamento per diversi mercati senza richiedere integrazioni personalizzate. Costruire da zero un checkout comparabile richiede un progetto di diversi mesi e un notevole carico di manutenzione continua.
Anche la gestione operativa, dagli ordini all’evasione, dai resi agli strumenti per l’assistenza clienti, è matura. L’interfaccia di amministrazione impone scelte precise, ma riflette una reale conoscenza del funzionamento dei flussi di lavoro dell’e-commerce su larga scala. Per i team che devono formare personale non tecnico alla gestione degli ordini, l’esperienza d’uso di Shopify è nettamente più semplice di quella di qualsiasi alternativa headless attualmente disponibile.
L’ecosistema di app, nonostante la reputazione di avere costi nascosti, risolve problemi reali. Piattaforme di recensioni, fatturazione degli abbonamenti, programmi fedeltà e analisi avanzate funzionano perché Shopify ha standardizzato i webhook, i modelli di dati e l’autenticazione su cui si basano le app di terze parti. In un’architettura headless, ciascuna di queste integrazioni va sviluppata su misura o acquistata da fornitori che potrebbero non supportare nativamente la piattaforma scelta.
I vincoli diventati bloccanti
I limiti dell’internazionalizzazione (i18n) sono stati il primo ostacolo. Il supporto multilingue di Shopify, pur essendo molto migliorato rispetto agli inizi, continua a trattare i mercati non anglofoni come secondari. Gestire contenuti in una dozzina di lingue dall’interfaccia di amministrazione è oneroso, e le difficoltà aumentano con le dimensioni del catalogo. Le app di traduzione aiutano, ma aggiungono costi e complessità di sincronizzazione che una soluzione nativa eliminerebbe.
Con il tempo, il controllo e la proprietà dei dati sono diventati il problema più importante. Tutti i dati operativi rilevanti, dallo storico degli ordini alle anagrafiche clienti e al catalogo prodotti, risiedono nel database di Shopify e sono accessibili tramite un’API controllata da Shopify. I limiti di frequenza delle richieste, le politiche di conservazione dei dati e i formati di esportazione sono stabiliti da Shopify, non dal commerciante. Per i team che devono eseguire analisi sui propri dati operativi, è un vincolo strutturale, non un’opzione di configurazione.
La complessità del modello di determinazione dei prezzi è stata il terzo vincolo. Prodotti con molte varianti, prezzi personalizzati per segmento di clientela e flussi basati su preventivi per clienti aziendali si scontrano con i limiti delle varianti di Shopify (100 per prodotto fino a quando Shopify ha portato il limite a 2.048 nell’ottobre 2025) e le sue strutture di prezzo, richiedendo soluzioni alternative sempre più contorte. La conseguente complessità dei template Liquid diventa un onere di manutenzione che cresce male con l’ampliamento del catalogo.
La valutazione: Medusa v2, Saleor, Commerce.js
La valutazione si è basata su quattro criteri: controllo e proprietà dei dati (controllo completo del database, nessun limite API imposto dal fornitore), profondità del supporto i18n (supporto nativo per più valute, lingue e prezzi regionali), esperienza di sviluppo (qualità della documentazione, supporto TypeScript, flusso di sviluppo locale) e maturità operativa (installazioni in produzione, modalità di guasto note, dimensioni della community).
Medusa v2 ha ottenuto i risultati migliori per l’esperienza di sviluppo. La riscrittura della v2 migliora notevolmente l’architettura originale: il sistema di moduli è ben progettato, i tipi TypeScript sono completi e lo sviluppo locale è rapido. La documentazione è migliorata molto e mostra l’attenzione del team all’esperienza degli sviluppatori. Il limite è la maturità operativa: la v2 è relativamente recente (Medusa 2.0 è stata rilasciata nell’ottobre 2024) e i casi di utilizzo in produzione sono meno numerosi e diversificati rispetto alle piattaforme più consolidate. I team che passano a Medusa sono, a tutti gli effetti, tra i primi ad adottarla.
Saleor è la più collaudata delle tre, con una base più ampia di installazioni in produzione e un’API GraphQL ben progettata. L’architettura multicanale, che distingue i «canali» per mercati, vetrine o segmenti di clientela diversi, gestisce la complessità di prezzi e cataloghi che ci ha allontanati da Shopify con maggiore eleganza rispetto alle alternative. La maturità operativa è la più elevata delle tre piattaforme valutate. Il compromesso è una curva di apprendimento più ripida e un’API centrata su GraphQL che richiede un investimento negli strumenti prima di poter lavorare in modo produttivo.
Commerce.js occupa una posizione diversa: è un’API headless, non una piattaforma e-commerce completa, progettata per essere combinata con altri servizi anziché usata come soluzione completa. È una scelta adatta ai team con solide risorse di sviluppo che vogliono un controllo dettagliato su ogni componente. Per chi vuole ridurre gli oneri operativi di Shopify senza introdurre un carico di sviluppo equivalente sotto un’altra forma, probabilmente non è la soluzione giusta. Essendo un’API ospitata, inoltre, non offre il pieno controllo sul database, il nostro primo criterio. A ottobre 2026, Chec, l’azienda dietro Commerce.js, ha archiviato la propria organizzazione GitHub (nell’ottobre 2024): verifica quindi lo stato attuale del servizio prima di prenderlo in considerazione.
Il percorso di migrazione
Il costo più sottovalutato in una migrazione di piattaforma è quello dei dati, non del codice. Trasferire catalogo prodotti, anagrafiche clienti e storico degli ordini da Shopify a una nuova piattaforma richiede script di estrazione personalizzati, trasformazioni dei dati per adattarli allo schema di destinazione e una gestione attenta dei casi limite. Prodotti con più di 100 varianti, clienti con storici degli indirizzi complessi e ordini evasi parzialmente rappresentano una piccola quota dei record, ma assorbono gran parte del tempo di sviluppo della migrazione.
La transizione operativa, il periodo in cui gli ordini devono passare attraverso entrambi i sistemi mentre si convalida la migrazione, richiede una pianificazione attenta per evitare evasioni duplicate o comunicazioni ripetute ai clienti. È la fase in cui la maggior parte delle migrazioni incontra problemi non previsti, perché i casi limite rilevanti sono specifici del catalogo e dello storico degli ordini del commerciante, non dell’e-commerce in generale.
La lezione di questa valutazione e dell’osservazione di decisioni simili è che la scelta della piattaforma conta meno della qualità della pianificazione della migrazione. Medusa e Saleor sono entrambe in grado di supportare attività e-commerce in produzione, come lo era Commerce.js al momento della nostra valutazione. I team che riescono nelle migrazioni headless investono nella comprensione delle differenze tra i modelli di dati prima di iniziare la migrazione, non durante.
Approfondimenti correlati
- Un sito in decine di lingue: i18n pratico per l’e-commerce — le esigenze i18n che le piattaforme headless gestiscono meglio degli strumenti nativi di Shopify.
- Costruire un’infrastruttura dati pronta per la produzione per i venditori Amazon — controllo e proprietà dei dati come principio fondamentale nelle attività e-commerce e i modelli infrastrutturali che ne derivano.
- Interventi SEO che fanno la differenza: URL canonici, sitemap e slash finali — le considerazioni SEO da affrontare quando si cambiano contemporaneamente piattaforma e struttura degli URL.