Salesforce Commerce Cloud e Shopify Plus a confronto, funzione per funzione (2026)

Salesforce Commerce Cloud è la piattaforma su cui gira una parte consistente del fashion e del lusso europeo, ed è quella da cui, negli ultimi due anni, ci arrivano più richieste di replatforming. Chi la usa non l'ha scelta male: l'ha scelta quando era la risposta giusta, e adesso si chiede se lo sia ancora.

Questo articolo mette a confronto Salesforce Commerce Cloud e Shopify Plus nel 2026, funzione per funzione e senza tabelle: cosa succede sull'una e cosa succede sull'altra quando devi fare la stessa cosa. È un confronto fra due prodotti SaaS enterprise, non fra un SaaS e un open source, e questo cambia i termini della domanda. Non si discute di chi ti dà accesso al codice: si discute di chi ti fa arrivare prima in produzione, e di chi mantiene in piedi ciò che hai costruito.

Una premessa sui nomi, perché generano confusione. La piattaforma nasce come Demandware ed entra in Salesforce nel 2016. Nella documentazione più recente Salesforce l'ha rinominata Agentforce Commerce, e B2C Commerce è diventato Agentforce Commerce for B2C. È lo stesso prodotto. Qui lo chiamiamo Commerce Cloud, o SFCC, che è il nome con cui il mercato continua a cercarlo.

Seconda premessa, e vale la pena farla perché l'equivoco è quotidiano: Commerce Cloud non è il CRM. Salesforce è il CRM che ha definito uno standard, ed è un prodotto diverso, con un altro modello di licenza e un'altra storia. Una parte del valore di Commerce Cloud sta proprio nel fatto di stare nella stessa casa del CRM, e ci torniamo alla fine.

La ricerca

Su Commerce Cloud la ricerca è un motore della piattaforma. Gli attributi ricercabili e le regole di rilevanza si governano da Business Manager, che è il back office, e sopra ci sta Einstein, la parte di intelligenza artificiale che ordina i risultati e produce raccomandazioni. Nel 2026 Salesforce ha acquisito Cimulate e ne ha fatto Agentic Commerce Search, una ricerca che lavora sull'intento invece che sulle parole chiave, e che oggi è la punta di diamante del prodotto. Salesforce dichiara aumenti di conversione e di aggiunte al carrello a doppia cifra: sono numeri suoi, e come tali vanno letti.

Su Shopify la ricerca nativa passa dall'app Search and Discovery, che è gratuita e copre bene i cataloghi normali: sinonimi, ridirezionamenti, spinta manuale dei prodotti. Sopra una certa complessità, però, chi fa sul serio non usa il motore nativo di nessuna delle due piattaforme: usa un servizio esterno. Algolia, Klevu, Constructor. Ed è esattamente qui che nasce il primo fatto rilevante per chi sta valutando un cambio.

Algolia ha una cartridge per Commerce Cloud e un'app per Shopify. Sono lo stesso servizio, con lo stesso indice e le stesse regole di merchandising, montato in due modi diversi. Se la ricerca del tuo negozio la fa Algolia, la migrazione se la porta: cambia il collante, non il motore. Se invece la fa Einstein, quella si perde, perché Einstein esiste solo dentro Salesforce, e va sostituita. È una domanda da fare il primo giorno di analisi, non al terzo mese.

I filtri, e la coda lunga che nessuno conta

Questa è la sezione più importante di tutto l'articolo, e quasi nessuno la scrive. Non parla di comodità per chi naviga: parla di traffico organico che esiste oggi e che può sparire.

Su Commerce Cloud i filtri si chiamano search refinement, si definiscono per categoria dentro Business Manager, e producono di default URL a parametri del tipo prefn1, prefv1, prefn2, prefv2. Fin qui niente di speciale. Il punto è che SFCC permette di mapparli dentro il percorso della URL invece che nei parametri: la stessa pagina filtrata, da indirizzo con il punto interrogativo, diventa un indirizzo pulito, con il marchio e il colore dentro il path. Sono pagine navigabili, e sono pagine indicizzabili.

La documentazione ufficiale fissa anche i limiti: si possono abilitare al massimo trenta URL search refinement, e al massimo cinque per singola categoria. E c'è un dettaglio che vale più di mille parole. Salesforce ha costruito un'intera macchina di snapshot e di redirect dedicata a quelle URL, per governarne i cambiamenti nel tempo. Quella macchina esiste per una sola ragione: sono pagine indicizzate, e valgono abbastanza da meritare un redirect quando cambiano.

Su Shopify il comportamento è un altro. I filtri passano dall'app Search and Discovery e producono URL a parametri sulla stessa collezione, e i temi ufficiali impostano il canonical verso la collezione base: non diventano pagine di atterraggio autonome per impostazione predefinita. Ci sono poi due vincoli documentati da conoscere. I filtri non compaiono sulle collezioni sopra i cinquemila prodotti, il che obbliga a spezzare le collezioni grandi. E dal 16 marzo 2026 gli URL dei filtri usano identificatori stabili al posto dei valori testuali, con Shopify che dichiara nel proprio changelog che gli indirizzi filtrati creati in precedenza continuano a funzionare. La lezione, però, resta: la forma di quegli indirizzi la decide la piattaforma, e cambia quando decide la piattaforma.

La conseguenza è semplice e costosa. Se il tuo sito Commerce Cloud ha centinaia di pagine filtrate indicizzate, e riceve traffico su ricerche lunghe del tipo marchio più colore più categoria, quel traffico non si trasferisce da solo. Va ricostruito, e su Shopify si ricostruisce con collezioni dedicate, anche automatiche. È una voce di lavoro: va censita prima e va messa a preventivo, e come si fa, riga per riga, è il capitolo centrale della nostra guida alla migrazione SEO. Sulla SEO di Shopify in generale, e sui miti che ci girano attorno, abbiamo scritto un pezzo a parte.

Il catalogo

Commerce Cloud lavora con prodotti master e attributi di variazione, e non ti mette limiti pratici su quanti assi di variazione puoi combinare. I prezzi stanno nei price book, che sono listini veri e propri, e la licenza ne conta il numero: si passa dai dieci price book dell'edizione base ai tremilacinquecento delle edizioni superiori. È un modello pensato per cataloghi grandi e per assortimenti che cambiano per paese, per stagione e per canale.

Su Shopify il limite di varianti per prodotto è stato alzato a 2.048, quando prima erano cento, e questo ha chiuso una discussione che durava da anni. Quello che non è cambiato è il tetto delle tre opzioni per prodotto, e restano 250 file media per prodotto. È la trappola numero uno di ogni migrazione che arriva da una piattaforma a modello di attributi aperto, e va detta subito.

Nel fashion il conto si fa in fretta: taglia, colore, vestibilità e lunghezza fanno quattro opzioni, e con tre non ci stai. Non è un muro, è un lavoro di modellazione. Si rimappa una delle dimensioni sui metacampi, oppure si separano i prodotti, oppure si accetta una gerarchia diversa in catalogo. Ma è lavoro, e chi non lo mette a preventivo lo scopre in collaudo.

Il checkout

Su Commerce Cloud il checkout è codice tuo. Nell'architettura SFRA è una catena di controller e di template, e la riscrivi riga per riga: passaggi in più, passaggi in meno, campi personalizzati, logiche di pagamento e di spedizione che fanno esattamente quello che vuoi. È il massimo della libertà, e ha il prezzo di ogni libertà: quel codice è tuo, e va ricollaudato a ogni rilascio della piattaforma.

Su Shopify il checkout non si riscrive. Si estende, e si estende in due modi: con le estensioni dell'interfaccia, che aggiungono blocchi e campi nei punti previsti, e con le Shopify Functions, che eseguono la logica di sconto, di spedizione e di pagamento dentro l'infrastruttura di Shopify. Il vecchio checkout.liquid, che era comunque riservato a Shopify Plus, è ormai dismesso, e gli Shopify Scripts si sono fermati il 30 giugno 2026: le logiche che ci giravano vanno riscritte come Functions.

Va detto senza infingimenti: chi arriva da Commerce Cloud, la prima volta che sente dire che il checkout non lo può riscrivere, si irrigidisce. È una reazione legittima. La risposta onesta è che su Shopify quel checkout non lo tocchi, ma non lo mantieni nemmeno, e converte perché lo ottimizza qualcun altro su un volume di transazioni che nessun singolo brand vedrà mai. Il perimetro di ciò che puoi cambiare è più stretto. Il perimetro di ciò che devi mantenere è molto più stretto.

Il B2B

Su Commerce Cloud il B2B è un'edizione che compri. Salesforce pubblica due pacchetti, Commerce Cloud B2B Growth e Commerce Cloud B2B Advanced: il primo porta sei storefront e una gestione ordini ridotta, il secondo dieci storefront e la gestione ordini completa. Entrambi hanno lo stesso modello di prezzo, cioè una percentuale sul fatturato, e su entrambi la pagina prezzi dice contattare il commerciale.

C'è un punto della documentazione ufficiale che vale la pena leggere con attenzione, perché nel B2B cambia il conto. La percentuale si applica al fatturato che passa dallo storefront Commerce Cloud. Gli ordini che arrivano da altri canali, cioè dal telefono, dagli agenti, dall'EDI o da un sistema terzo, non rientrano in quel calcolo, ma non sono nemmeno gestiti: per gestirli serve acquistare Salesforce Order Management a parte. Nel B2B, dove metà degli ordini nasce fuori dal sito, è una domanda da fare per iscritto prima di firmare.

Su Shopify il B2B è una funzione che accendi. Dal 2 aprile 2026 sui piani Basic, Grow e Advanced sono compresi senza costi aggiuntivi i profili azienda, le condizioni di pagamento, i prezzi a volume, le carte salvate e fino a tre cataloghi B2B attivi. Restano esclusive di Plus i cataloghi illimitati, l'assegnazione diretta del catalogo a un'azienda o a una singola sede, i pagamenti parziali e gli acconti. Non è un modulo, non è una licenza separata, non è un'app: è dentro.

Il crinale è questo, e vale la pena dirlo bene. Se il tuo B2B è un negozio, cioè clienti aziendali che si autenticano, vedono il loro listino e ordinano, Shopify lo fa nativamente e ti costa il canone. Se il tuo B2B è un processo di vendita, con preventivi negoziati, approvazioni, agenti che lavorano nel CRM e l'ordine che nasce da un'opportunità, allora stare dentro Salesforce ha un valore reale, e non è marketing: è codice che non devi scrivere.

I mercati e le lingue

Qui le due piattaforme ragionano in modo strutturalmente diverso, e capire la differenza evita un errore di valutazione grosso.

Commerce Cloud conta i siti. La licenza ti dà un numero di siti e un numero di listini: cinque siti e dieci price book nell'edizione di ingresso, cento siti e tremilacinquecento price book nelle due edizioni superiori. Un sito per paese, o un sito per marchio, tutti dentro la stessa licenza e lo stesso back office. Su carta è un numero enorme, e su un gruppo multi-marca sembra chiudere il discorso.

Shopify conta i negozi, ma i mercati non sono negozi. Uno store Shopify contiene più mercati, e ogni mercato ha la propria valuta, la propria lingua, il proprio dominio o sottocartella, il proprio catalogo e i propri prezzi, e anche personalizzazioni del tema. Puoi escludere prodotti da un mercato, e quei prodotti spariscono dalla vetrina, dalla ricerca e dal carrello per chi naviga in quel contesto. Non è un negozio in più: è configurazione dentro il negozio che hai.

È il punto che quasi tutti sbagliano quando confrontano i due numeri. La quasi totalità dei siti di una installazione Commerce Cloud sono mercati, non marchi: stesso brand, stesso assortimento di base, valuta, lingua, dominio e listino diversi. Su Shopify quelli non consumano store, consumano mercati. Il conteggio degli store serve solo quando i brand sono davvero distinti, con assortimenti e identità diverse.

E su quello, il vincolo Shopify c'è e non lo nascondiamo. Il contratto Plus comprende lo store principale e nove store di espansione; oltre, si pagano trecento dollari al mese per store. E vale un marchio per contratto: più marchi significa più contratti Plus. Su un gruppo con dodici brand veri, il conto va rifatto. Ci torniamo, perché è la sezione onesta di questo articolo, ed è anche quella dove si vede se chi ti sta parlando ragiona o sta vendendo.

La personalizzazione

Su Commerce Cloud si personalizza con le cartridge. Una cartridge è un pacchetto di codice, e l'ordine in cui le monti si chiama cartridge path: è una lista, e vince chi sta più a sinistra. La cartridge di base dello storefront è di proprietà di Salesforce e non si tocca; sopra ci metti le cartridge plugin, le cartridge LINK dei partner, come quelle dei sistemi di pagamento o delle recensioni, e le tue cartridge personalizzate, che sovrascrivono i pezzi che vuoi cambiare.

I template si scrivono in ISML, che è un'estensione proprietaria dell'HTML di Commerce Cloud. La logica sta nei controller, in JavaScript eseguito sul server, con i model, gli hook, i job schedulati e Page Designer per le pagine dei merchandiser. È profondo, ed è il motivo per cui i brand con requisiti fuori standard hanno scelto questa piattaforma: si può cambiare quasi tutto.

Su Shopify il nucleo non si tocca. Si estende con le app, che stanno sui server di chi le fa e non dentro il tuo tema; con le Functions, che eseguono la tua logica di business dentro l'infrastruttura di Shopify; con le estensioni del tema, i metacampi e i metaoggetti, che modellano i dati che il modello standard non prevede; e con Hydrogen e Oxygen quando serve davvero un front-end disaccoppiato.

La differenza vera non è quanto puoi personalizzare, perché le cose che servono a un negozio le fanno tutte e due. La differenza è chi tiene in piedi ciò che hai personalizzato. Su Commerce Cloud il codice è tuo, e resta tuo per sempre. Su Shopify una fetta larga di quel codice, in un progetto ben fatto, non esiste proprio: è un'app che qualcun altro aggiorna.

Il modello di costo

Salesforce non pubblica una sola cifra. Sulle pagine prezzi ufficiali, sia quella B2C sia quella B2B, ogni edizione riporta la stessa dicitura: contatta il commerciale. Quello che Salesforce pubblica è il modello, e il modello è chiaro. Prende una percentuale del Gross Merchandise Value, cioè del valore della merce venduta, in funzione delle capacità di commerce che ti servono. E definisce il GMV come il ricavo totale che passa dal sito, al netto di tasse e spedizione, calcolato soltanto sul fatturato che transita dallo storefront Commerce Cloud.

Le percentuali che si trovano in rete, l'uno, il due, il tre per cento, non vengono da Salesforce: vengono da agenzie e da siti di comparazione, e divergono fra loro. Non le usiamo, per lo stesso motivo per cui non usiamo le cifre di Adobe che girano in rete. Un numero che non ha una fonte ufficiale, in una trattativa enterprise, è un rischio, non un argomento. Si spiega il modello, e il modello basta.

Perché il modello, da solo, dice già la cosa importante: il costo della piattaforma cresce con il fatturato, per costruzione. Un trimestre buono alza la fattura di Salesforce. Non è un difetto nascosto, è la filosofia dichiarata, e viene presentata come successo condiviso: cresci tu, cresce chi ti dà la piattaforma.

Ci sono però due cifre che Salesforce pubblica, e quelle si possono usare. La prima è il piano di supporto Premier, che costa il trenta per cento delle net license fees. È una percentuale su una percentuale del tuo fatturato, e cresce con lei. La seconda riguarda gli ambienti di sviluppo: i sandbox on demand si consumano a crediti, e i crediti sono una voce della licenza, un milione e duecentomila nell'edizione base, due milioni nelle superiori. Un sandbox di profilo medio brucia un credito al minuto quando è acceso, due il profilo grande, quattro l'extra large, e anche da spento continua a consumare zero virgola tre crediti al minuto finché non lo cancelli. Finiti i crediti, si va in eccedenza e si fattura.

Su Shopify un ambiente di sviluppo costa zero, non ha limite di numero e si crea in trenta secondi. Non è un dettaglio da sviluppatori: è la ragione per cui su Shopify si sperimenta e su Commerce Cloud si pianifica.

Dall'altra parte, il canone di Shopify Plus è un numero pubblicato: 2.300 dollari al mese sul contratto triennale, 2.500 sull'annuale, per configurazioni standard. Sopra certi volumi si passa a una commissione variabile sul fatturato, e lì Shopify non pubblica né la soglia né la percentuale: le cifre che girano vengono da blog di agenzie e non le usiamo nemmeno quelle. Con un gateway di pagamento esterno Shopify trattiene lo 0,20% per transazione, e questo invece è pubblicato. Il costo del progetto è un'altra cosa dal costo della licenza, e l'abbiamo scomposto qui.

La differenza strutturale, ridotta all'osso: su Commerce Cloud la piattaforma è una percentuale di quello che vendi, e il supporto è una percentuale della piattaforma. Su Shopify Plus il canone è un numero fisso fino a una certa soglia. Chi cresce molto, su Salesforce paga molto di più, ed è scritto nel contratto.

I tempi di rilascio

Questa è la sezione che in trattativa fa più male, e non perché sia polemica: perché è tutta scritta nella documentazione di Salesforce.

Commerce Cloud rilascia una versione maggiore ogni quattro o cinque settimane, e ne prevede nove o dieci all'anno. Le istanze si aggiornano automaticamente durante le finestre di manutenzione, e Salesforce dichiara di non poter indicare l'orario esatto in cui verrà aggiornata la singola istanza di un cliente. Durante la manutenzione della versione maggiore, la migrazione dello schema e il riavvio delle istanze di produzione producono un fermo dello storefront di quindici minuti o meno, e i job schedulati e le repliche vengono interrotti.

Rileggila. Fermo pianificato in produzione, dieci volte l'anno, in una finestra che non scegli tu. Su un sito che vende, questo è un numero di business, non un dettaglio operativo.

E c'è dell'altro, ed è il punto più costoso. Salesforce mette a disposizione una versione di anteprima sui sandbox e scrive, testualmente, di non testare il codice personalizzato dei clienti, invitando clienti e partner a verificare lì le proprie integrazioni. Tradotto in una voce di budget: il collaudo di regressione di tutto ciò che hai scritto è a carico tuo, nove o dieci volte l'anno. Su un progetto enterprise con quaranta cartridge attive, questa è una squadra che lavora tutto l'anno solo per stare fermi.

Su Shopify il nucleo si aggiorna in continuo, senza fermi e senza collaudi a carico tuo, per la semplice ragione che quel nucleo non è tuo. Ma sarebbe disonesto raccontarla come se Shopify non avesse scadenze: le ha, e sono forzate. Il vecchio checkout personalizzabile è stato dismesso, gli Shopify Scripts si sono fermati il 30 giugno 2026 e chi li usava ha dovuto riscrivere. La differenza non è che una piattaforma ha scadenze e l'altra no. È che su Shopify si aggiorna il modo in cui personalizzi, mentre su Commerce Cloud si ricollauda tutto quello che hai scritto, ogni cinque settimane.

Sul tempo di messa in produzione di una singola funzione il divario è evidente. Su Commerce Cloud si passa da una cartridge, da una versione di codice, da un caricamento sull'istanza e da un collaudo. Su Shopify, per una fetta larghissima di casi, si passa da un'app o da una Function, e si è online lo stesso giorno. C'è anche l'altro lato: quando serve qualcosa che nessuna app fa, su Commerce Cloud lo scrivi e basta, mentre su Shopify a volte devi trovare la strada. Ma è il caso raro, e va pesato per quello che è.

L'ecosistema

Su Commerce Cloud le integrazioni arrivano come cartridge LINK: sono codice, e una volta installate nel tuo cartridge path diventano codice tuo da mantenere. Se il fornitore rilascia un aggiornamento, lo integri tu. Se una versione maggiore della piattaforma rompe qualcosa, lo sistemi tu. Su Shopify le app girano sui server di chi le sviluppa, si aggiornano da sole e non stanno dentro il tuo tema: quando Shopify cambia qualcosa, è il fornitore dell'app a doversi adeguare, e in genere lo fa prima che tu te ne accorga.

Non è una questione di quante integrazioni esistono. È una questione di chi ha il cerino in mano quando si rompe qualcosa alle undici di sera del Black Friday.

E c'è il capitolo competenze, che in Italia pesa più che altrove. Uno sviluppatore Commerce Cloud è una figura rara e cara, e le agenzie che la sanno fare davvero si contano. Uno sviluppatore Shopify si trova, e si sostituisce. Non è un giudizio sulla qualità delle persone: è un fatto di mercato del lavoro, ed è un rischio di continuità che va messo nella colonna dei costi anche se non compare in nessuna fattura.

Quando Salesforce Commerce Cloud resta la scelta giusta

Un confronto che non ha una sezione come questa non è un confronto, è una brochure. Ci sono situazioni in cui restare su Commerce Cloud è la decisione corretta, e ce ne sono almeno tre.

La prima è quando il commercio vive dentro Salesforce. Se hai Sales Cloud, Service Cloud, Marketing Cloud e Data Cloud in produzione, se l'assistenza lavora sul ticket vedendo l'ordine, se la campagna parte dal segmento costruito sui dati del CRM, allora stare nella stessa casa non è uno slogan: è integrazione che non devi costruire e non devi mantenere. Chi ti dice il contrario ti sta vendendo qualcosa.

La seconda è quando hai appena investito. Se hai finito da poco una migrazione a Storefront Next, il conto di un cambio non torna quest'anno, e non tornerebbe nemmeno se Shopify fosse gratis. Il costo di un replatforming non è la licenza: è il progetto e sono i dodici mesi in cui l'azienda guarda dentro invece che fuori.

La terza è il multi-sito spinto, ed è quella su cui va fatta la conversazione seria. Cento siti e tremilacinquecento listini stanno dentro una licenza Commerce Cloud. Su Shopify Plus gli store di espansione compresi sono nove, poi si pagano trecento dollari al mese l'uno, e vale un marchio per contratto. Su un gruppo con dodici marchi veri, il conto della licenza può girare a favore di Salesforce, ed è giusto dirlo.

Detto questo, va anche ridimensionato, perché nella pratica è un piccolo compromesso, e i compromessi si risolvono con l'architettura, non con il conteggio degli store. Il primo passaggio è distinguere i mercati dai marchi: nella quasi totalità dei casi che abbiamo visto, i siti di una installazione Commerce Cloud sono paesi, non brand, e su Shopify i paesi non consumano store. Il secondo è progettare il livello sotto: un catalogo unico che vive nel PIM, un ERP che parla con un hub dati invece che con dieci negozi, una libreria di tema condivisa fra gli store, e componenti pubblicate una volta e riusate. Fatta così, la moltiplicazione degli store non diventa moltiplicazione del lavoro, e resta una voce di canone.

È un problema di progettazione, ed è esattamente il tipo di problema che si risolve in fase di analisi. Non è un muro. Ma va guardato prima, non dopo la firma.

Un'ultima cosa, e vale la pena scriverla perché in giro si legge il contrario. Salesforce non sta abbandonando Commerce Cloud. Storefront Next, il nuovo storefront su stack React moderno, è in disponibilità generale da giugno 2026, e Salesforce dichiara che gli storefront esistenti, SiteGenesis, SFRA e PWA Kit, restano pienamente supportati e senza una data di fine vita. Chi ti racconta Commerce Cloud come una piattaforma morente sta vendendo, non analizzando, e al primo interlocutore competente perde credibilità.

La domanda giusta

La domanda giusta non è quale piattaforma sia più potente. Commerce Cloud lo è, e su alcune cose lo è di molto. La domanda giusta è quante generazioni di front-end hai già pagato.

SiteGenesis, poi SFRA, poi PWA Kit e Composable Storefront, adesso Storefront Next. Quattro architetture di front-end in una decina d'anni, e nessuna di quelle transizioni è stata un aggiornamento: sono stati progetti, con un budget, una squadra e un collaudo. Nel frattempo la licenza continua a costare una percentuale di quello che vendi, e il supporto una percentuale della licenza. Non è una piattaforma che muore. È una piattaforma che ti fa rifare il front-end ogni volta che cambia idea, e che ti presenta il conto due volte: quando lo rifai e quando cresci.

Su Shopify Plus lo scambio è esplicito: rinunci a un pezzo di controllo, e in cambio smetti di pagare la manutenzione di quel controllo. Il canone è un numero, il nucleo lo tiene in piedi qualcun altro, e il lavoro dell'agenzia si sposta dal tenere accesa la piattaforma al far vendere il negozio. Se questo scambio convenga o no dipende da dove sei, e la decisione viene prima della piattaforma: quando conviene fare un replatforming, e quando invece non conviene affatto, è la domanda da cui partire.

Se invece la decisione è già presa e serve il come, abbiamo messo per iscritto cosa si porta e cosa cade migrando da Commerce Cloud a Shopify: le cartridge senza corrispettivo, i dati, le URL e i tempi.

Domande frequenti

Salesforce Commerce Cloud e Salesforce CRM sono la stessa cosa?

No. Commerce Cloud è la piattaforma di commercio elettronico, nata come Demandware, ed è un prodotto separato con un proprio modello di licenza. Il CRM è un'altra famiglia di prodotti, Sales Cloud e Service Cloud in testa. Girano nella stessa casa e si integrano nativamente, ma si comprano e si pagano a parte.

Quanto costa Salesforce Commerce Cloud?

Salesforce non lo pubblica. Le pagine prezzi ufficiali riportano contatta il commerciale su tutte le edizioni. Quello che è pubblicato è il modello: una percentuale del valore della merce venduta, calcolato al netto di tasse e spedizione e solo sul fatturato che passa dallo storefront. A questo si aggiunge, se lo prendi, il piano di supporto Premier al trenta per cento delle license fee. Le percentuali che si leggono in rete non hanno fonte ufficiale, e in una trattativa non vanno usate.

Migrando su Shopify si perde il posizionamento?

Non le pagine principali, se i redirect si fanno bene e l'architettura dell'informazione non cambia. Il rischio vero sta nelle pagine filtrate: su Commerce Cloud i refinement possono diventare indirizzi indicizzabili dentro il percorso della URL, mentre su Shopify i filtri restano parametri canonicalizzati sulla collezione base. Quella coda lunga va ricostruita con collezioni dedicate, e va pianificata prima del lancio, non dopo.

Commerce Cloud sta per essere dismesso?

No, e chi lo dice sbaglia. Salesforce ha portato Storefront Next in disponibilità generale nel giugno 2026 e dichiara che SiteGenesis, SFRA e PWA Kit restano supportati senza una data di fine vita. La questione non è la sopravvivenza della piattaforma: è quante volte hai già rifatto il front-end e quante volte lo rifarai.

Shopify Plus regge un catalogo enterprise?

Sì, con un vincolo da conoscere. Le varianti per prodotto arrivano a 2.048, e per la stragrande maggioranza dei cataloghi bastano. Il vincolo è il tetto delle tre opzioni per prodotto: se il tuo modello ne usa quattro, e nel fashion capita, va rimodellato in analisi. È lavoro, non un impedimento.