Migrare da Salesforce Commerce Cloud a Shopify: cosa si porta, cosa cade, quanto dura

Questa pagina non è scritta per Google. La query “migrare da Salesforce Commerce Cloud a Shopify”, in Italia, ha volume di ricerca praticamente nullo: nessuno la digita. Chi affronta questo problema non lo cerca su un motore di ricerca, lo discute in una sala riunioni, e in quella sala ci sono un direttore ecommerce, un CTO e un responsabile IT che hanno già sentito troppe promesse.

È scritta per loro, e per chi gli sta seduto di fronte. Precisione tecnica, nessun entusiasmo, e soprattutto nessuna sottovalutazione: una migrazione da Commerce Cloud non è una migrazione da un CMS, è lo smontaggio di una piattaforma enterprise su cui, in genere, sono stati spesi anni e milioni.

Se sei ancora nella fase in cui la domanda è “conviene” e non “come”, il posto giusto è il confronto fra Salesforce Commerce Cloud e Shopify Plus, che mette le due piattaforme una accanto all'altra funzione per funzione. Qui diamo per scontato che la decisione sia presa, o quasi, e parliamo solo di come si esegue.

La regola che governa tutto: censire prima, spostare dopo

Il metodo generale di una migrazione, cioè la mappatura dei contenuti, l'architettura, il censimento delle funzioni e dei servizi, l'abbiamo scritto a parte e non lo ripetiamo. Quello che cambia, quando si parte da Commerce Cloud, è che il censimento non si fa sul sito: si fa sul cartridge path.

Il cartridge path è la lista, separata da due punti, delle cartridge montate su quel sito, nell'ordine in cui vengono lette. È il manifesto di tutto ciò che quel negozio è diventato negli anni. Aprilo, stampalo e mettilo sul tavolo: quella lista è il preventivo. Ogni riga è una domanda a cui rispondere, e sono sempre le stesse tre. Si porta identico? Ha un corrispettivo diverso? Oppure non esiste, su Shopify, e va rifatto da zero?

Cosa si porta identico

È la parte che nessuno si aspetta, e che di solito è più grande di quanto il cliente creda. Tutto ciò che nel tuo negozio Commerce Cloud è già un servizio esterno, e non codice dentro la piattaforma, si porta dietro.

La ricerca, se la fa Algolia o un motore equivalente. Algolia ha una cartridge per Commerce Cloud e un'app per Shopify: è lo stesso servizio, lo stesso indice, le stesse regole di merchandising, montato in un modo diverso. Cambia il collante, non il motore, e il team che lo governa continua a lavorare come prima.

Il PIM, se ce l'hai, e il DAM. Sono a monte della piattaforma per definizione: cambia il connettore in uscita, non il sistema. Idem per l'ERP, che nella quasi totalità dei casi non parla direttamente con l'ecommerce ma con un middleware o con un hub dati: si riscrive il tratto finale, non l'integrazione.

E poi la roba che vive nel browser e non nella piattaforma: analytics, tag manager, consent, A/B testing, chat, recensioni, marketing automation. Si rimontano, non si riprogettano. È lavoro di collegamento, ed è lavoro che si stima bene.

Sui dati puri, infine, la buona notizia è quasi banale: prodotti, categorie, clienti, ordini storici e contenuti si esportano. Commerce Cloud ha strumenti di importazione ed esportazione seri e un'API di amministrazione, e Shopify ha un'API di amministrazione altrettanto seria. Il trasferimento dei dati, in una migrazione da SFCC, non è quasi mai il problema. Il problema è quello che i dati significavano.

Cosa cade, e non si converte

Qui bisogna essere brutali, perché è il punto in cui i progetti si rompono. Non esiste un convertitore, non esiste uno strumento, non esiste un ponte. Il codice di Commerce Cloud non va da nessuna parte.

I template sono in ISML, che è un'estensione proprietaria dell'HTML di Commerce Cloud e non esiste fuori da lì. Non si converte in Liquid: si riscrive. I controller e i model, che sono JavaScript eseguito sul server dentro l'applicazione, non hanno un posto dove atterrare su Shopify, perché su Shopify non c'è un server tuo dove eseguire codice dentro la richiesta della pagina. Gli hook, i job schedulati, le pagine di Page Designer, le estensioni di Business Manager: tutto questo è architettura di Commerce Cloud, e finisce lì.

La conseguenza operativa è che una migrazione da Commerce Cloud non è una conversione, è una ricostruzione. E la buona notizia, se ce n'è una, è che questo è il momento migliore per smettere di portarsi dietro dieci anni di stratificazioni che nessuno ricorda più perché ci sono. Nella pratica, la metà delle cartridge attive di un sito enterprise serve a funzioni che su Shopify sono native, o che semplicemente non servono più.

Le cartridge, riga per riga

Prese le categorie di cartridge che si trovano nel novanta per cento delle installazioni, il destino è questo.

Le cartridge di pagamento, che sui progetti enterprise sono spesso tre o quattro fra gateway, wallet e pagamento dilazionato, cadono e vengono sostituite da integrazioni native. Su Shopify i sistemi di pagamento non sono codice tuo: si accendono. È la sostituzione più semplice del progetto, ed è anche quella che libera più manutenzione.

Le cartridge di spedizione e di corriere, con le loro tabelle di tariffe e le loro regole, si spostano su app o su Functions. Qui va guardato caso per caso: le tariffe calcolate in tempo reale e le regole di spedizione complesse sono uno dei pochi punti in cui il lavoro è vero, e va stimato invece che promesso.

Le cartridge di calcolo delle imposte, tipicamente collegate a un servizio fiscale esterno, si portano: il servizio resta, cambia il modo in cui ci si parla.

Le cartridge di integrazione con l'ERP e con il gestionale sono il capitolo più delicato, ed è quello dove si annidano i costi nascosti. Non cade l'integrazione: cade il pezzo di codice che, dentro Commerce Cloud, traduceva i dati dell'ERP nel modello della piattaforma. Quel pezzo va riscritto contro il modello di Shopify, e va riscritto sapendo che il modello di Shopify è diverso. È qui che si scoprono gli attributi che non esistono, gli stati d'ordine che non hanno corrispondenza e i campi che qualcuno, nel 2019, ha infilato in un attributo personalizzato invece che dove andava.

Le cartridge di Einstein, e in generale tutto ciò che è intelligenza artificiale nativa di Salesforce, cadono e non hanno corrispettivo diretto. Le raccomandazioni si rifanno con un'app o con il motore di ricerca esterno; la ricerca a intento, che oggi è il fiore all'occhiello di Salesforce, va ricomprata altrove. Non è un disastro, ed è un mercato con dieci fornitori validi, ma è una voce di costo ricorrente che va messa nel confronto fin dall'inizio, altrimenti il conto del risparmio non torna.

Le cartridge di recensioni, di fedeltà, di lista dei desideri, di chat e di notifiche si sostituiscono con app, quasi sempre dello stesso fornitore che già usi, e quasi sempre nel giro di poche ore. Non sono il problema.

Restano le cartridge davvero tue: quelle che qualcuno ha scritto per un requisito che nessun prodotto sul mercato copre. Un configuratore, una logica di prenotazione, una regola di assortimento che nessun'altra azienda ha. Quelle vanno guardate una a una, e per ognuna si sceglie fra tre strade: la si rifa come app privata, la si sposta su una Function, oppure ci si accorge che era un tampone a un limite della vecchia piattaforma e non serve più. Quest'ultimo caso, per esperienza, è più frequente di quanto chiunque sia disposto ad ammettere.

Le entità che non si traducono

I dati passano. I concetti, no. Sono quattro, e vanno affrontati in analisi, non in sviluppo.

Il primo sono i price book. Su Commerce Cloud un listino è un oggetto di prima classe, ne puoi avere a migliaia, e ci costruisci sopra gerarchie e priorità. Su Shopify i prezzi differenziati vivono nei cataloghi, agganciati ai mercati per il B2C e alle aziende per il B2B. Il modello copre la stragrande maggioranza dei casi reali, ma non è lo stesso modello, e chi ha costruito logiche di prezzo barocche su cinquanta listini deve accettare di semplificarle. Nella pratica è quasi sempre un bene, ma va concordato con chi quei listini li usa, non deciso a tavolino.

Il secondo sono gli attributi di variazione. Commerce Cloud non ti pone limiti pratici su quanti assi combini. Shopify porta le varianti fino a 2.048 per prodotto, che bastano, ma tiene fermo il tetto di tre opzioni per prodotto. Nel fashion, dove taglia, colore, vestibilità e lunghezza fanno quattro, questo è il primo scoglio vero del progetto. Si risolve rimappando una dimensione sui metacampi, o separando i prodotti, o rivedendo la gerarchia del catalogo. Si risolve, ma va fatto prima di importare un milione di SKU, non dopo.

Il terzo sono i customer group e le promozioni che ci girano sopra. Su Shopify il concetto si spezza in due: i segmenti di clienti per il marketing, e i mercati o i cataloghi per il prezzo. Le regole di promozione complesse, quelle che su Commerce Cloud vivevano nel motore delle campagne, si riscrivono come Functions. È un lavoro conosciuto e stimabile, ma è lavoro.

Il quarto sono i siti. Ogni sito di Commerce Cloud è un'entità con il proprio catalogo, il proprio listino e la propria configurazione. Su Shopify quasi tutti quei siti non sono negozi: sono mercati dentro un negozio solo, con la propria valuta, lingua, dominio, catalogo e prezzi. La regola pratica è semplice, e va applicata in analisi: se cambia solo il paese, è un mercato; se cambia il marchio, è uno store. Sbagliare questa distinzione è il modo più rapido per moltiplicare inutilmente il costo di gestione del dopo.

Le URL, i refinement e i redirect

È il capitolo che fa perdere fatturato, ed è anche quello che quasi nessun preventivo contiene. Va letto con attenzione.

Le URL di prodotto e di categoria si mappano e si redirigono. È lavoro noioso, va fatto uno a uno e non a blocchi verso la home, ma è lavoro noto: si esporta la mappa completa dal vecchio sito, si costruisce la corrispondenza, si caricano i redirect. Chi lo fa bene non perde niente.

Il problema sta altrove, e sta nei refinement. Commerce Cloud permette di mappare i filtri dentro il percorso della URL invece che nei parametri: la pagina filtrata per marchio e colore, dentro una categoria, diventa un indirizzo pulito e indicizzabile. Salesforce consente di abilitarne fino a trenta, con un massimo di cinque per categoria, e ha costruito un intero sistema di snapshot e redirect dedicato a quelle URL, che esiste per una ragione sola: sono pagine indicizzate che portano traffico.

Su Shopify quelle pagine non esistono nella stessa forma. I filtri producono URL a parametri sulla stessa collezione, e i temi ufficiali le canonicalizzano verso la collezione base: non diventano pagine di atterraggio autonome per impostazione predefinita. Ci sono poi due vincoli documentati: i filtri non compaiono sulle collezioni sopra i cinquemila prodotti, e dal 16 marzo 2026 gli URL dei filtri usano identificatori stabili al posto dei valori testuali.

Quindi: quella coda lunga non si trasferisce da sola, e non si salva con un redirect. Va ricostruita, e si ricostruisce con collezioni dedicate, anche automatiche, che riproducano le combinazioni che oggi portano traffico. Non tutte, però, e qui sta il metodo. Si esporta dalla Search Console la lista delle pagine filtrate che ricevono impression e clic reali, si ordina per valore, si tiene la parte che conta e si costruiscono quelle collezioni, con la loro URL, il loro titolo e il loro testo. Le altre si lasciano andare, perché non valevano niente nemmeno prima. È il capitolo più sottovalutato di tutte le migrazioni, e lo abbiamo aperto per intero nella guida alla migrazione SEO verso Shopify.

Se salti questo passaggio, il traffico organico cala dopo il lancio, e cala in un modo che nessuno riesce a spiegare guardando le pagine principali, perché le pagine principali stanno benissimo. È il modo più comune in cui una migrazione tecnicamente riuscita viene ricordata come un fallimento.

I dati, e l'ordine in cui si spostano

L'ordine non è negoziabile, perché ogni passo dipende dal precedente.

Prima il modello di prodotto, cioè la decisione su come si mappano attributi, opzioni e varianti. Solo dopo il catalogo, con prodotti, categorie e media. Poi i listini e i mercati. Poi i clienti, con le loro anagrafiche e i loro indirizzi, tenendo presente che le password non si migrano mai: si fa ripristinare la password al primo accesso, ed è il momento in cui si perde una fetta di utenti registrati inattivi, cosa che va detta prima e non dopo. Poi gli ordini storici, che servono al servizio clienti e alla contabilità e che si importano in blocco. Infine i contenuti.

Un avvertimento che vale la pena scrivere. Il catalogo non si migra come sta: si migra come dovrebbe essere. Dieci anni su una piattaforma enterprise lasciano attributi doppi, valori scritti in tre modi diversi, categorie fantasma e prodotti che nessuno vende dal 2021. Se importi la sporcizia, ti porti la sporcizia, e questa volta te la porti su una piattaforma nuova dove non avrai nemmeno la scusa del sistema vecchio. La bonifica del catalogo è parte del progetto, non un extra.

I tempi

Chiunque ti dia una durata senza aver visto il cartridge path sta tirando a indovinare, e noi non lo facciamo. Quello che possiamo dire è da cosa dipende, che è più utile di un numero finto.

Le fasi sono cinque, e in una migrazione da Commerce Cloud pesano in modo molto diverso dal solito. L'analisi è lunga, molto più lunga della media, perché il censimento delle cartridge e la mappatura delle entità sono il progetto. La costruzione del tema e delle funzioni è nella norma. Le integrazioni sono la variabile grossa, ed è lì che si decide se il progetto dura sei mesi o dodici. La migrazione dei dati è breve, se l'analisi è stata fatta bene, e interminabile se non lo è stata. Il collaudo e il lancio dipendono da quante lingue e quanti paesi vanno online insieme.

Le tre domande che spostano davvero la durata sono queste, e vanno poste al primo incontro. Quante cartridge personalizzate hai davvero in produzione, e quante di quelle servono ancora a qualcuno. Chi parla con l'ERP oggi, e attraverso cosa. Quanti paesi e quante lingue devono andare online insieme, e quanti possono aspettare la seconda ondata.

Sul lancio, una raccomandazione che vale per tutte le migrazioni enterprise ma qui doppiamente: non si va online con tutto insieme. Si sceglie un paese, possibilmente non il primo per fatturato, si va in produzione, si guardano i numeri per quattro settimane, e poi si aprono gli altri. Chi accende dodici paesi lo stesso giovedì sta scegliendo di scoprire i problemi tutti insieme, nel momento peggiore.

E una nota di realismo sulla licenza vecchia. I contratti Salesforce sono annuali o pluriennali, e non si spengono a metà. Nel periodo di sovrapposizione paghi due piattaforme: è un costo certo, va messo nel piano finanziario dal primo giorno, e va negoziato con il rinnovo alla mano invece che subito.

Chi fa cosa

Una migrazione da Commerce Cloud richiede due competenze che raramente stanno nella stessa testa: qualcuno che sappia leggere il vecchio, cioè che capisca cosa fa una cartridge guardandola, e qualcuno che sappia costruire il nuovo. La prima serve in analisi e non serve più dopo; la seconda serve dal secondo mese in poi. Su come è fatta una squadra di progetto, con fasi, ruoli, livelli di servizio e clausole di contratto, abbiamo scritto altrove.

Quello che resta al cliente, e non può essere delegato, è la decisione sul catalogo. Nessun partner esterno può dirti quale delle tue quattro opzioni di prodotto è sacrificabile, quali dei tuoi cinquanta listini servono ancora e quali dei tuoi mercati sono paesi e quali sono marchi. Quelle sono decisioni di business travestite da decisioni tecniche, e vanno prese da chi vende, non da chi sviluppa.

Il riassunto, per chi deve decidere

Da Commerce Cloud a Shopify i dati si portano, i servizi esterni si portano, e il codice no. Non esiste conversione: esiste ricostruzione, e la ricostruzione si dimensiona leggendo il cartridge path, non il sito.

I tre punti in cui i progetti si rompono sono sempre gli stessi: il tetto delle tre opzioni di prodotto, scoperto tardi; le integrazioni con l'ERP, sottostimate; e le pagine filtrate indicizzate, dimenticate. Se li affronti in analisi, il resto è mestiere. Se li affronti in collaudo, il progetto slitta e la colpa se la prendono tutti tranne chi non ha fatto l'analisi.

E se la decisione non è ancora presa, vale la pena tornare un passo indietro: prima della piattaforma di arrivo viene la domanda se cambiare, e ci sono casi in cui la risposta è no. È una risposta che diamo anche noi, quando è quella giusta.