SAP Hybris End of Life: la checklist completa per la migrazione 2026

Il 31 luglio 2026 è terminata la manutenzione mainstream di SAP Commerce on-premise (SAP Help Portal). La release 2205 è stata l’ultima release on-premise. Chi la utilizza ancora oggi dipende dalla manutenzione specifica per il cliente, senza patch di sicurezza regolari né aggiornamenti normativi.

Abbiamo pubblicato questa checklist ad aprile, quando mancavano quattro mesi. La scadenza è passata, la checklist no: descrive ancora l’ordine in cui portiamo le installazioni Hybris su SAP Commerce Cloud. L’ho aggiornata per la situazione dopo luglio e vi ho riunito ciò che prima trattavamo in tre articoli separati: cosa passa da Hybris, il piano per fasi e il lavoro dopo il go-live.

In sintesi: SAP Commerce on-premise (ex SAP Hybris) è uscito dalla manutenzione mainstream il 31 luglio 2026; da allora esiste solo la manutenzione specifica per il cliente. La destinazione per la maggior parte dei clienti è SAP Commerce Cloud: lo stesso nucleo di Hybris, ma gestito da SAP e aggiornato in modo continuo. Questa checklist copre 26 passi in quattro fasi, tempi tipici (da 3 a 18 mesi secondo il perimetro), costi indicativi, la tutela della SEO e le prime settimane dopo il go-live. Se siete ancora on-premise, iniziate dall’assessment: vi dice per quanto tempo resterete esposti.

Che cos’era SAP Hybris?

SAP Hybris era la piattaforma di e-commerce acquisita da SAP nel 2013. SAP l’ha poi rinominata SAP Commerce per il prodotto on-premise e SAP Commerce Cloud per la versione gestita da SAP; dalla release 2211 viene fornita solo come SAP Commerce Cloud. Chi oggi dice «Hybris» intende quasi sempre un’installazione on-premise di SAP Commerce, ed è proprio quella la cui manutenzione mainstream è terminata il 31 luglio 2026.

Cosa è cambiato il 31 luglio 2026

«End of life» è l’espressione che si cerca. Il termine corretto è End of Mainstream Maintenance (EoMM), e ha conseguenze precise.

Cosa è venuto meno:

• Patch di sicurezza regolari. La vostra piattaforma di commercio, che tratta dati di clienti e di pagamento, non riceve più aggiornamenti di sicurezza di routine.
• Aggiornamenti legali e fiscali. Modifiche dell’IVA e altri adeguamenti normativi non vengono più forniti come manutenzione standard.
• Aggiornamenti delle librerie di terze parti. Se una dipendenza inclusa riceve una CVE, la correzione non arriva più come cosa ovvia nella vostra release on-premise.
• Certificazione del runtime Java. Le nuove versioni del JDK non vengono certificate per la 2205; il runtime invecchia con la piattaforma.
• Sviluppo del prodotto. Nessuna nuova funzionalità, nessun lavoro sulle prestazioni, nessuna nuova API. Il prodotto on-premise è congelato.

Cosa continua, a pagamento:

• Manutenzione specifica per il cliente. SAP offre supporto con accordi individuali. Condizioni e prezzi dipendono dal vostro contratto: fateveli confermare per iscritto dal team SAP che vi segue.
• SAP Note esistenti. La knowledge base resta consultabile, ma le correzioni per problemi nuovi potrebbero non esistere.

Cosa significa in pratica dopo luglio e quali misure transitorie hanno senso lo spieghiamo in Il supporto on-premise di SAP Commerce è terminato: e adesso?. Questo articolo riguarda la via d’uscita.

Hybris, SAP Commerce, Commerce Cloud: cosa è rimasto e cosa è cambiato

Prima una nota sui nomi. SAP ha acquisito Hybris nel 2013 e l’ha poi rinominato: SAP Commerce per il prodotto on-premise, SAP Commerce Cloud per la versione gestita da SAP. «Hybris end of life» si riferisce quindi alla versione on-premise. Dalla release 2211 SAP Commerce viene fornito solo come SAP Commerce Cloud, ed è questa la destinazione della migrazione.

Il malinteso più frequente che sentiamo: «Commerce Cloud è un prodotto completamente nuovo». Non lo è. Il motore è lo stesso; è cambiato il modo in cui viene gestito.

Cosa è rimasto:

• Il type system (i tipi di item si definiscono ancora in XML)
• Il meccanismo delle extension e Spring come contenitore dei servizi
• Il backend Java e i moduli commerce: catalogo, carrello, checkout, prezzi, gestione ordini

Cosa è cambiato:

• Esercizio. SAP predispone, scala, aggiorna e monitora l’infrastruttura. I team che prima dedicavano metà del tempo ai server possono lavorare sullo shop.
• Aggiornamenti. Invece di grandi upgrade ogni pochi anni, SAP rilascia aggiornamenti continui. Le nuove funzionalità arrivano disattivate e le attivate quando il vostro team è pronto. Il rovescio: gli aggiornamenti non si possono più rinviare per anni. Cosa significa in concreto lo mostra il framework update 2211-jdk21 con Java 21 e Spring 6.
• Deployment. Build e deployment passano dal Cloud Portal invece che da script propri.
• Storefront. Il frontend consigliato è il SAP Composable Storefront headless (in precedenza Spartacus), che comunica con il backend tramite le API REST OCC. SAP ha dichiarato deprecati i template Accelerator basati su JSP con la release 2205 e, secondo il piano pubblicato, li rimuove da Commerce Cloud a settembre 2027 (SAP KBA 3263872).

Per il vostro team significa: le competenze Java e sul type system restano utili. Da imparare ci sono il modello di deployment cloud, il Cloud Portal e, se usate ancora Accelerator, un frontend Angular. È formazione, non riqualificazione.

Il quadro decisionale per la migrazione

Prima della checklist, una domanda richiede una risposta: restare su SAP o cambiare?

Siamo partner SAP e quindi abbiamo un interesse commerciale a che restiate. Ecco quando ha senso ciascuna strada.

Restate su SAP Commerce Cloud se:

• Usate un ERP SAP (S/4HANA o ECC) e dipendete da un’integrazione ERP profonda: prezzi, disponibilità, ordini, condizioni specifiche per cliente. Se quell’ERP è ancora ECC, nello stesso piano rientra anche la sua fine della manutenzione di SAP ECC nel 2027.
• Il vostro modello B2B usa funzioni specifiche di SAP: prezzi complessi, contratti, cataloghi per cliente, workflow di approvazione.
• Il vostro team ha competenze SAP Commerce. Passare a una piattaforma completamente diversa costa mesi.
• Dovete muovervi in fretta. Commerce Cloud conserva modello dati, logica di business e molte personalizzazioni; un cambio completo di piattaforma no.

Valutate un cambio se:

• Non avete un ERP SAP, oppure l’integrazione è un semplice invio di ordini.
• Il vostro storefront è puro B2C con catalogo, carrello e checkout standard.
• Il vostro team non ha competenze SAP e non intende costruirle.
• Puntate comunque a un’architettura interamente composable. Richiede molto più tempo di una migrazione a Commerce Cloud; la nostra analisi sul composable commerce nel B2B spiega quando conviene.

Per la maggior parte dei clienti on-premise SAP Commerce Cloud è la risposta pragmatica: rischio minimo, esecuzione più rapida, investimenti esistenti preservati. Pragmatico però non significa automatico: prendete la decisione in modo consapevole. Una panoramica della piattaforma di oggi è sulla nostra pagina SAP Commerce Cloud.

La checklist completa per la migrazione

Ventisei punti in quattro fasi. È la checklist che usiamo con i nostri clienti.

Fase 1: assessment (settimane 1-4)

È la fase che più spesso viene affrettata. Tutto il resto dipende da essa.

1. Inventariare ogni personalizzazione. Esportate un elenco completo di extension personalizzate, script ImpEx, personalizzazioni HAC e API di piattaforma modificate. Classificate ogni voce: ancora necessaria, sostituibile con funzionalità standard di Commerce Cloud oppure obsoleta. Nei nostri audit una parte considerevole ricade di solito nelle ultime due categorie; perché conti lo spiegano i 5 errori nella migrazione.

2. Trovare le modifiche al core. Il codice che modifica classi consegnate da SAP invece di usare le extension, o che aggira il type system e accede direttamente al database, va ristrutturato prima della migrazione. Sono proprio questi punti a far saltare i tempi: trovateli per primi.

3. Mappare tutte le integrazioni. ERP, PIM, CRM, pagamenti, spedizioni, fiscalità, loyalty, marketing automation. Per ciascuna: protocollo (API, IDoc, trasferimento file, connessione diretta al database), volume dati, frequenza, responsabile. Scambi di file e connessioni dirette al database non funzionano in Commerce Cloud, ed è il punto che più spesso porta al classico «come abbiamo fatto a non accorgercene?».

4. Verificare le extension di terze parti. Chiarite con il fornitore la compatibilità con Commerce Cloud di ogni add-on ed extension di terze parti e testatela in una sandbox cloud. Alcune esistono in versione cloud, altre vanno sostituite.

5. Censire gli storefront. Numero di siti, lingue, cataloghi. Configurazioni multi-paese con prezzi, regole fiscali e logistiche proprie sono un progetto diverso da un singolo storefront.

6. Profilare i dati. Contate prodotti (con varianti), categorie, clienti, ordini storici, pagine di contenuto e media. Verificate nel contempo la qualità: duplicati, riferimenti orfani, formati incoerenti, dati che nessuno tocca da anni. Pulite nel sistema di origine; i dati sporchi non vanno portati in un ambiente nuovo.

7. Registrare i valori di riferimento. Tempi di risposta, throughput, tasso di conversione, tassi di errore. Senza questi numeri, dopo il go-live nessuno può dimostrare se la nuova piattaforma va meglio o peggio.

8. Valutare l’impronta SEO. Estraete l’inventario completo degli URL da Google Search Console. Quante pagine sono indicizzate e quanto traffico organico portano? I siti con alto valore SEO hanno bisogno di una strategia di redirect dettagliata.

9. Documentare crittografia e credenziali. Se usate la Transparent Attribute Encryption con chiavi proprie, documentate tutti gli attributi cifrati e pianificatene il passaggio alla gestione delle chiavi di Commerce Cloud.

10. Chiarire licenze e contratto. Cosa prevede il vostro contratto attuale per il periodo dopo l’EoMM e com’è un abbonamento Commerce Cloud per i vostri volumi? Le trattative richiedono settimane: avviatele in parallelo.

Fase 2: architettura e pianificazione (settimane 5-10)

11. Scegliere l’approccio per lo storefront. Tre opzioni:

• SAP Composable Storefront: il frontend consigliato da SAP. Headless, disaccoppiato dal backend, rilasciabile in modo indipendente. La scelta giusta per un investimento strategico; la nostra guida alla migrazione da Accelerator al Composable Storefront descrive i passi.
• Portare con sé lo storefront Accelerator: la via più rapida per lasciare l’on-premise, perché il codice dello storefront resta. I template però sono deprecati dalla 2205 e ne è prevista la rimozione a settembre 2027: è quindi una soluzione ponte con una data di scadenza fissa.
• Un frontend headless proprio: React, Next.js o Vue sulle API di Commerce Cloud. Massima libertà, ma il frontend è interamente a vostro carico. Confrontiamo le opzioni in Composable Storefront vs React/Next.js.

12. Progettare l’architettura di destinazione. Ambienti Commerce Cloud, architettura di integrazione (SAP Integration Suite o API dirette), strategia CDN e caching, monitoraggio e alerting.

13. Pianificare la rielaborazione delle integrazioni. In Commerce Cloud tutto passa da API o da SAP Integration Suite. Ogni integrazione ha bisogno di un proprio piano di migrazione; calcolate da tre a cinque giorni per integrazione per analisi e riprogettazione.

14. Definire la strategia di migrazione dei dati. Big bang (caricamento completo in un’unica finestra di cutover) oppure iterativa (caricamenti progressivi con sincronizzazione delta). Oltre il milione di prodotti consigliamo caricamenti iterativi con almeno tre prove. I metodi disponibili sono descritti nel nostro articolo sulle tecniche di caricamento in SAP Commerce Cloud.

15. Pianificare ambienti, CI/CD e ripristino. Almeno sviluppo, staging e produzione; i progetti più grandi aggiungono un ambiente di test delle integrazioni. Predisponete pipeline automatizzate di build, test e deployment dal primo giorno. Definite gli obiettivi di recovery point e recovery time e testate il ripristino prima del go-live.

16. Impostare la governance e bloccare il perimetro. Un comitato di guida settimanale con potere decisionale, un registro delle decisioni, demo di sprint ogni due settimane e un product owner lato cliente che decide sul perimetro. Poi mettete il perimetro per iscritto e fatelo approvare. La causa principale dei ritardi è «già che ci siamo, aggiungiamo anche…». Prima si migra, poi si evolve.

Fase 3: realizzazione e migrazione (settimane 11-30)

17. Predisporre gli ambienti Commerce Cloud. Attivate tutti gli ambienti, verificate le pipeline di build ed eseguite un deployment lungo tutta la catena prima di scrivere logica di business.

18. Ricostruire o migrare lo storefront. Iniziate dai template con più traffico: home page, pagine di categoria, pagine prodotto, checkout.

19. Rielaborare le integrazioni. Testate ogni integrazione con dati reali, non con mock. È nei test di integrazione che emerge la maggior parte dei difetti di migrazione: testate presto e spesso.

20. Eseguire migrazioni di prova dei dati. Almeno due esecuzioni complete prima del cutover reale. Misurate durata, accuratezza e tasso di errore e correggete i problemi tra un’esecuzione e l’altra.

21. Implementare SEO e prestazioni. Mettete in produzione mappa dei redirect, URL canonici, sitemap XML e robots.txt ed eseguite un crawl dell’ambiente di staging. Ottimizzate caching CDN e tempi di risposta delle API; fissate valori obiettivo per tempi di caricamento e Core Web Vitals.

Fase 4: test e go-live (settimane 31-38)

22. Test di accettazione con il business. Utenti di business, non sviluppatori, testano ricerca, navigazione, carrello, checkout, pagamento, resi e workflow B2B, in ogni storefront, lingua e segmento di clientela.

23. Test di carico su larga scala. Simulate i giorni di picco. Commerce Cloud scala automaticamente; il vostro codice e le vostre integrazioni non necessariamente.

24. Validare la migrazione SEO. Confrontate gli inventari degli URL, verificate ogni redirect, validate i dati strutturati con il Rich Results Test di Google.

25. Provare ed eseguire il cutover. Scrivete un runbook che chiunque nel team possa eseguire: congelare i contenuti, migrazione delta finale, switch del DNS, verifica di tutte le integrazioni, 48 ore di monitoraggio. Provatelo almeno una volta e documentate il rollback, compreso il modo in cui gli ordini effettuati dopo lo switch tornano nel vecchio sistema se doveste tornare indietro.

26. Monitorare dopo il go-live. Almeno due settimane di monitoraggio ravvicinato: tassi di errore, conversione rispetto al valore di riferimento, indicizzazione, errori di integrazione, ticket di supporto. Impostate allarmi per gli scostamenti.

Il go-live non è il traguardo

Il traffico reale di produzione mostra colli di bottiglia che nessun test ha trovato. Pianificate fin dall’inizio le settimane dopo il go-live:

• Uno sprint di ottimizzazione. Da quattro a sei settimane per caching, query lente, tempi di risposta delle API e rendering del frontend.
• Formazione. Il vostro team deve saper gestire Commerce Cloud, curare i contenuti e circoscrivere i problemi in autonomia. Formate per gradi: prima l’esercizio, poi la configurazione, poi lo sviluppo.
• Un backlog per ciò che è stato rinviato. Quanto è uscito dal perimetro durante la migrazione va in un backlog con priorità, non nel dimenticatoio. Rivedetelo regolarmente invece di costruire tutto insieme.
• Un ritmo di aggiornamento. Commerce Cloud si aspetta che adottiate gli aggiornamenti con regolarità. Pianificate finestre fisse.

Calcolatore dei tempi

Non tutte le migrazioni sono uguali. Questi fattori determinano i tempi:

Come leggere questi numeri a settembre 2026: da adesso ogni mese conta, perché ogni mese passa in manutenzione specifica. I progetti fast-track possono andare live entro fine anno o all’inizio del 2027. I progetti standard arrivano nel corso del 2027, e quelli complessi conviene suddividerli in ondate, così i primi mercati lasciano presto la piattaforma on-premise. L’estremo più rapido dell’intervallo è descritto nel nostro playbook dei 90 giorni.

Stime dei costi per scenario

Ce lo chiedono in ogni primo colloquio, quindi ecco valori indicativi dai nostri progetti invece di un vago «dipende»:

Fast-track (uno storefront, poche integrazioni): da 300’000 a 500’000 USD. Presuppone un perimetro mirato, competenze SAP nel team e la disponibilità a rinviare le personalizzazioni non essenziali.

Mid-market (due o tre storefront, complessità media): da 500’000 a 800’000 USD. Qui ricade la maggior parte dei nostri progetti di migrazione: assessment, realizzazione, migrazione dei dati, rielaborazione delle integrazioni, test di prestazione e supporto al go-live.

Enterprise (cinque o più storefront, B2B complesso, più paesi): da 800’000 a oltre 2 milioni di USD. L’intervallo è ampio perché un’attività B2B in dodici paesi con prezzi propri e integrazione ERP profonda è un progetto diverso da cinque storefront B2C con checkout standard.

Sono costi di migrazione una tantum. Esclusi: licenze Commerce Cloud (annuali, in funzione dei volumi), licenze di terze parti (PIM, ricerca, CMS), impegno interno ed evoluzioni successive. Prevedete una riserva del 15-20 per cento per la qualità dei dati e le sorprese nelle integrazioni. Il lato licenze è dettagliato nella nostra guida ai costi di Commerce Cloud.

Quanto costa aspettare: la manutenzione specifica per il cliente ha un prezzo individuale ed è di norma ben superiore a quanto pagavate per la manutenzione mainstream, senza nuove funzionalità né patch regolari. Confrontate quella cifra con il budget di migrazione prima di decidere di aspettare un altro anno.

Migrazione SEO: non perdere il posizionamento

Abbiamo visto migrazioni tecnicamente pulite perdere una parte consistente del traffico organico perché nessuno aveva pianificato il passaggio SEO. Per molti shop la ricerca organica è uno dei canali di fatturato più importanti.

Prima della migrazione:

1. Registrare tutto come riferimento. URL indicizzati, clic, impressioni e posizioni medie delle query principali da Search Console, ogni settimana, perché serve l’andamento e non un’istantanea.
2. Eseguire il crawl del sito attuale. Con Screaming Frog o Sitebulb: inventario completo degli URL, link interni, canonical, dati strutturati.
3. Mappare ogni URL. URL vecchio, URL nuovo, tipo di redirect (quasi sempre 301).

Durante la migrazione:

4. Costruire presto i redirect, in parallelo alla nuova piattaforma, e testarli in staging.
5. Preservare i metadati. Titoli, descrizioni, struttura dei titoli e dati strutturati devono essere trasferiti.
6. Tenere pronta la sitemap XML e inviarla subito dopo lo switch del DNS.

Dopo la migrazione:

7. Monitorare ogni giorno per quattro settimane: tasso di indicizzazione, errori 404, traffico organico rispetto al riferimento, posizioni delle 50 query principali.
8. Correggere i problemi in giornata. Nelle prime settimane Google rivaluta l’intero sito.

Cosa abbiamo imparato dal lancio di Franke

Per Franke abbiamo portato in produzione la piattaforma SAP Commerce Cloud in 90 giorni; il dato si riferisce al lancio commerce. Il punto di partenza era una vecchia piattaforma trascurata, realizzata da un partner precedente. L’abbiamo sostituita con un’architettura headless per B2B e B2C, integrata in modo pulito con S/4HANA e C4C, e oggi collega oltre dieci canali globali. Il progetto ha ricevuto lo SAP Quality Award per «Rapid Time to Value». I dettagli sono nella storia di successo di Franke.

Tre lezioni valgono per ogni migrazione:

• Prima l’audit, poi la migrazione. Ogni personalizzazione che risulta obsoleta è codice che non dovete migrare, testare e mantenere.
• Filoni di lavoro in parallelo. Piattaforma, dati, integrazioni e frontend in parallelo con coordinamento quotidiano, non uno dopo l’altro.
• Rilasci iterativi. Deployment in cloud presto, anche incompleto, e avanzamenti mostrati agli stakeholder ogni settimana.

Il rischio di restare on-premise

Da agosto non fare nulla non è più un piano, ma uno stato. Ecco cosa comporta:

Sicurezza. La piattaforma tratta dati personali e di pagamento senza patch di sicurezza regolari. È difficilmente conciliabile con i requisiti di PCI-DSS, del GDPR e della nLPD svizzera, e in un audit «non abbiamo migrato in tempo» non è un argomento.

Conformità. Regole fiscali e requisiti di protezione dei dati continuano a cambiare. Senza aggiornamenti SAP dovete implementarli voi, in moduli core che pochi team sanno modificare in sicurezza.

Costi. La manutenzione specifica costa più di quella mainstream, e le migrazioni non diventano più economiche: gli sviluppatori con esperienza on-premise sono sempre più rari.

Competenze. Gli sviluppatori vogliono lavorare su piattaforme attuali. Un sistema congelato rende più difficili assunzioni e fidelizzazione.

Assicurazioni e audit. Assicuratori cyber e revisori (SOC 2, ISO 27001, PCI-DSS) chiedono lo stato di manutenzione. Una piattaforma di commercio non più manutenuta finisce di solito come rilievo nel rapporto.

Prossimi passi

1. Prenotare un assessment. Il nostro assessment di migrazione strutturato dura due o tre settimane e fornisce inventario delle personalizzazioni, mappa delle integrazioni, valutazione della complessità, tempistica e budget. Richiedetelo qui.
2. Approfondire. Il supporto on-premise è terminato: e adesso? tratta le misure transitorie; il playbook dei 90 giorni mostra come si presenta un’esecuzione rapida.
3. Scegliere il partner con attenzione. La nostra panoramica dei migliori partner SAP Commerce Cloud in Svizzera elenca i criteri che decidono un progetto di migrazione. Se cambia anche il vostro ERP, forniamo il nucleo S/4HANA e l’intero stack CX con un solo team; vedete la panoramica per Cloud ERP e CRM.
4. Visitate la nostra pagina dedicata all’on-premise per altre risorse.

La scadenza è passata. Quanto dura la vostra finestra di esposizione dipende ancora da voi. Parlatene con noi.

Domande frequenti

Quando è terminata la manutenzione mainstream di SAP Hybris on-premise?

Il 31 luglio 2026. La release 2205 è stata l’ultima release on-premise di SAP Commerce, il prodotto un tempo chiamato SAP Hybris. Da allora SAP offre solo manutenzione specifica per il cliente: patch regolari e aggiornamenti normativi non arrivano più automaticamente.

Dopo luglio 2026 siamo ancora on-premise. Cosa facciamo adesso?

Chiarite prima la vostra situazione contrattuale con SAP, poi chiudete le lacune di sicurezza più esposte e avviate l’assessment per SAP Commerce Cloud. Un assessment di due o tre settimane fornisce inventario delle personalizzazioni, mappa delle integrazioni, tempistica e budget, così i mesi in manutenzione specifica restano il meno possibile.

Quanto dura una migrazione da Hybris a SAP Commerce Cloud?

Una migrazione fast-track con uno storefront e poche integrazioni richiede da tre a sei mesi; il playbook dei 90 giorni descrive l’estremo più rapido di questo intervallo. I progetti standard con due o tre storefront richiedono da sei a dodici mesi, i rollout complessi su più paesi da dodici a diciotto mesi.

SAP Commerce Cloud è lo stesso prodotto di SAP Hybris?

Il nucleo è lo stesso: type system, meccanismo delle extension, Spring e il backend Java provengono da Hybris. È cambiato tutto ciò che sta intorno: SAP gestisce l’infrastruttura, gli aggiornamenti arrivano in modo continuo, i deployment passano dal Cloud Portal e lo storefront consigliato è il SAP Composable Storefront headless.

Le nostre personalizzazioni Hybris funzioneranno in SAP Commerce Cloud?

Le extension che seguono il modello di SAP (tipi personalizzati, override di bean Spring, endpoint OCC) di solito migrano con piccole modifiche. Accessi diretti al database, modifiche al codice consegnato da SAP, integrazioni basate su file e script di infrastruttura propri vanno rielaborati. Il blocco di lavoro più grande è in genere lo storefront, soprattutto se usate ancora uno storefront Accelerator.

Quanto costa una migrazione da Hybris a Commerce Cloud?

Come valori indicativi dai nostri progetti: da 300’000 a 500’000 USD per una migrazione fast-track, da 500’000 a 800’000 USD per progetti mid-market con due o tre storefront e da 800’000 a oltre 2 milioni di USD per B2B complesso su più paesi. Licenze Commerce Cloud, strumenti di terze parti e impegno interno sono esclusi; prevedete una riserva del 15-20 per cento.