SAP Commerce on-premise dopo il 31 luglio 2026: cosa è cambiato e le vostre quattro opzioni

La mainstream maintenance di SAP Commerce on-premise, la piattaforma che molti team chiamano ancora Hybris, è terminata il 31 luglio 2026 (SAP Help Portal). La release 2205 è stata l’ultima on-premise e SAP non ne ha pianificate altre. Questo articolo è la nostra guida aggiornata per chi ci lavora ancora: cosa è cambiato, quale supporto rimane e come si confrontano le opzioni realistiche.

Il 1° agosto non si è rotto nulla. Gli shop sono rimasti online e gli ordini hanno continuato ad arrivare, ed è proprio per questo che questa fase viene sottovalutata. Il costo del restare non si presenta come un’interruzione del servizio. Si presenta come vulnerabilità aperte, come lavoro di compliance che ora ricade sul vostro team e come una migrazione sempre più difficile da staffare, trimestre dopo trimestre.

In sintesi: dal 31 luglio 2026 SAP Commerce on-premise (release 2205) è in manutenzione specifica per cliente: i problemi noti vengono ancora risolti, ma non arrivano più support package, adeguamenti normativi né aggiornamenti delle librerie, e i problemi nuovi possono comportare costi aggiuntivi. Le opzioni sono quattro: continuare per un periodo limitato, usare consapevolmente la manutenzione specifica per cliente come ponte, migrare a SAP Commerce Cloud (oppure, se usate S/4HANA Public Cloud, alla nuova ERP Edition) o lasciare SAP. Per la maggior parte degli shop B2B integrati con SAP, la migrazione all’interno dello stack SAP preserva l’integrazione ERP ed è la soluzione meno costosa nel totale. Parlate con noi della vostra situazione.

Cosa è cambiato il 1° agosto 2026

“End of Mainstream Maintenance” è un termine SAP preciso. Dal 1° agosto 2026, per SAP Commerce on-premise:

• Niente più support package né patch di sicurezza. Quando emergerà la prossima vulnerabilità nella piattaforma o in una libreria inclusa (Spring, Solr, componenti Apache), SAP non rilascerà un fix per la 2205. Il sistema che gestisce gli account clienti e tocca i flussi di pagamento accumula da ora questioni aperte.
• Niente adeguamenti fiscali e normativi. Variazioni delle aliquote IVA, regole di fatturazione e adeguamenti legati alla privacy diventano sviluppo interno, moltiplicato per il numero di paesi in cui vendete.
• Niente aggiornamenti delle librerie di terze parti né nuove versioni di Java. SAP non testa né certifica più nuove release della JVM per l’on-premise. Il runtime di oggi invecchia così com’è.
• Niente aggiornamenti di tecnologia o di interfacce. Quando i partner di pagamento, logistica ed ERP cambiano le loro API, mantenere funzionanti le integrazioni è compito vostro.
• Nessuna nuova funzionalità di storefront. SAP Composable Storefront (in precedenza Spartacus) e le nuove capacità come il merchandising basato sull’IA vengono sviluppati per SAP Commerce Cloud (SAP Help Portal).

Le FAQ di SAP sulla fine della mainstream maintenance sono il riferimento per i dettagli specifici del prodotto; consultatele prima di fissare un budget.

Cosa copre ancora la manutenzione specifica per cliente

Al termine della mainstream maintenance, le release SAP passano automaticamente alla manutenzione specifica per cliente. Secondo la definizione di SAP (SAP Support, customer-specific maintenance):

• prosegue nell’ambito del contratto di supporto esistente; non serve un contratto separato;
• la risoluzione riguarda i problemi noti; la soluzione di problemi nuovi può essere a pagamento;
• non ci sono adeguamenti normativi, nuovi support package né aggiornamenti tecnologici garantiti, come nuove versioni di database, sistema operativo o Java.

In altre parole, mantenete un canale di supporto, ma non un prodotto manutenuto. Come ponte durante una migrazione è utile. Come soluzione permanente no, ed è per questo che non parliamo più di “supporto esteso” per la strada on-premise: non si estende nulla, il servizio si restringe.

Dove si nascondono i costi del restare

La fattura della licenza è la parte visibile. La maggior parte del costo dell’on-premise dopo l’EoMM sta in voci che raramente finiscono nello stesso foglio di calcolo:

Voce di costo	On-premise dopo l’EoMM	SAP Commerce Cloud
Infrastruttura (produzione, staging, sviluppo, disaster recovery)	Hosting, rete e disponibilità sono a vostro carico	Inclusa nell’abbonamento
Patch di sicurezza	Il vostro team sviluppa e testa i fix, oppure accetta il rischio	Fornite da SAP con gli aggiornamenti di piattaforma
Aggiornamenti fiscali, normativi e Java	Sviluppo interno	Forniti da SAP
Esercizio	Personale dedicato alla piattaforma	Ridotto, concentrato sulla logica di business
Competenze specialistiche	Un bacino di sviluppatori on-premise in calo	Un bacino più ampio su Commerce Cloud
Backlog funzionale	Ogni nuova capacità è un progetto a sé	Release regolari della piattaforma

Non inseriamo di proposito cifre in CHF generiche in questa tabella: dipendono dalla vostra installazione, dal numero di storefront e da quanta parte dell’esercizio gestite internamente. In un assessment la compiliamo con i vostri numeri. La nostra guida a prezzi e TCO di SAP Commerce Cloud spiega come è strutturato l’abbonamento.

Due costi meritano una menzione a parte. Le competenze: sempre meno sviluppatori vogliono lavorare su una piattaforma non più manutenuta, e se una sola persona detiene la conoscenza critica delle vostre personalizzazioni, questo è un rischio aziendale. Il costo opportunità: ogni funzione richiesta dal business (un nuovo checkout, un frontend PWA, il self-service B2B) diventa uno sviluppo su misura su una piattaforma congelata.

Opzione 1: continuare e assumersi il rischio

È l’opzione di default, perché non richiede alcuna decisione, ed è l’unica il cui costo cresce ogni mese.

Per un piccolo shop B2B con poche modifiche e una rete ben protetta, continuare per qualche mese mentre si prepara la migrazione può essere un rischio calcolato e difendibile. Continuare senza un piano di migrazione è un incidente rimandato. L’esposizione si accumula: ogni vulnerabilità non corretta resta aperta, il lavoro di compliance passa al vostro team e la vostra posizione verso revisori e assicurazioni peggiora. “Gestiamo pagamenti su un software che non è più manutenuto” è una frase che prima o poi il vostro CISO dovrà pronunciare.

Sceglietela solo come ponte esplicito e limitato nel tempo, con una valutazione del rischio approvata, mentre una delle altre opzioni è già avviata.

Opzione 2: la manutenzione specifica per cliente come ponte pianificato

Nella pratica questa opzione procede in parallelo alla prima: in manutenzione specifica per cliente ci siete comunque, che l’abbiate scelto o no. La differenza sta nell’usarla in modo consapevole. Vi offre un canale di supporto per i problemi noti e un fornitore che potete ancora chiamare. Non vi offre nuove funzionalità, patch di sicurezza né una roadmap.

Ha senso in uno scenario: un’installazione grande e complessa che non può migrare entro 12 mesi (blocco normativo, M&A, un programma ERP parallelo) e ha bisogno di un ponte documentato. Se è il vostro caso, chiarite subito con SAP come verrebbero gestiti e fatturati i problemi nuovi nel vostro contratto, non dopo il primo incidente, e mettete la fine del ponte sulla stessa slide della data di avvio della migrazione.

Opzione 3: migrare a SAP Commerce Cloud

È la strada naturale, e quella in cui il vostro investimento sopravvive: modello dati, logica di business, buona parte delle personalizzazioni e soprattutto l’integrazione ERP vengono portati con sé. È anche l’opzione che conosciamo meglio, quindi valutate il nostro punto di vista di conseguenza e verificatelo sulle referenze.

• Franke: abbiamo preso in carico una piattaforma commerce legacy in stallo e portato in produzione SAP Commerce Cloud in 90 giorni. Il lancio commerce ha ricevuto lo SAP Quality Award per “Rapid Time to Value” e gli ordini manuali sono diminuiti di circa il 75%. Il playbook dei 90 giorni descrive il metodo.
• ANWR Group: una piattaforma headless B2B/B2C su SAP Commerce Cloud che gestisce oltre 5 milioni di SKU, con una sincronizzazione dei dati di prodotto più veloce dell’80%.
• Distrelec: da un’installazione SAP Commerce monolitica a un’architettura headless, con un time-to-market ridotto del 70% e un tasso di conversione più alto del 15%.

Tempi realistici: da 6 a 12 mesi per una migrazione tipica, da 4 a 6 mesi per un fast-track disciplinato, 90 giorni all’estremo più rapido con una preparazione completa.

Se migrate, preparatevi così. La maggior parte dei tempi e dei costi di una migrazione si decide prima che si sposti la prima riga di codice:

1. Verificate ogni personalizzazione. Classificatela come ancora necessaria, sostituibile con una funzione standard oppure obsoleta. Caching personalizzato, script di scalabilità e pipeline di deployment sono tipici workaround on-premise che Commerce Cloud gestisce nativamente.
2. Mappate ogni integrazione. ERP, PIM, CRM, pagamenti, logistica: è qui che si nascondono le sorprese.
3. Analizzate i dati per tempo. Anni di duplicati, riferimenti orfani e strutture di catalogo incoerenti non migliorano con un trasloco.
4. Fate pulizia prima di migrare. Rimuovete le extension inutilizzate, esternalizzate la configurazione scritta nel codice, dismettete le integrazioni morte ed eliminate i vecchi dati di test.
5. Procedete per iterazioni. Prima la piattaforma di base, poi storefront e mercati uno alla volta, invece di un unico fine settimana big bang.

Ne parliamo in dettaglio nei cinque errori più comuni nella migrazione SAP Commerce e nella checklist passo per passo per la migrazione da SAP Hybris.

La prospettiva della ERP Edition. Un’obiezione frequente degli shop on-premise di medie dimensioni era che la Commerce Cloud completa fosse dimensionata e prezzata per le grandi aziende. SAP Commerce Cloud, ERP Edition, annunciata a maggio 2026, cambia questo calcolo per le aziende su SAP S/4HANA Public Cloud: uno strato di commerce B2B preconfezionato, utilizzato tramite schermate native dell’ERP, con SAP che si fa carico di gran parte dell’integrazione (DSAG impulsant, in tedesco). Spadoom è uno dei primi partner pilota, con un cliente B2B svizzero di medie dimensioni; spieghiamo cosa cambia la ERP Edition per le PMI qui. Se il vostro ERP è ancora ECC, la decisione sul commerce e quella sull’ERP vanno prese insieme, e il nostro assessment di readiness S/4HANA è il primo passo sensato. La guida a Commerce Cloud e S/4HANA Public Cloud nel B2B mostra come si combinano.

Opzione 4: replatforming fuori da SAP

Lasciare SAP Commerce è un’opzione legittima e, per alcune aziende, quella giusta. Se le vostre esigenze di commerce si sono semplificate a ciò che Shopify Plus offre di serie, oppure la vostra strategia architetturale è davvero composable e avete l’organizzazione di sviluppo per gestirla, un replatforming merita una valutazione seria. La nostra analisi su quando il composable commerce ha senso nel B2B ne esamina i criteri.

Quantificate le voci che le presentazioni di replatforming tendono a omettere:

• Ricostruzione dell’integrazione ERP. Prezzi, verifica di disponibilità, controllo del credito, orchestrazione degli ordini e dati anagrafici sono la parte più preziosa e meno visibile della vostra piattaforma attuale. Con un replatforming li ricostruite, di solito tramite un middleware che diventa un progetto a sé.
• Profondità B2B. Prezzi contrattuali, punch-out, workflow di approvazione e strutture di account multilivello sono maturi in SAP Commerce e altrove spesso sono add-on o sviluppi su misura.
• Il lavoro sui dati non si riduce. I dati di catalogo, clienti e ordini vanno comunque migrati; il filone dell’integrazione si aggiunge.
• Tempi. I progetti di replatforming per un’installazione integrata con SAP durano in genere da 6 a 12 mesi o più, la stessa finestra di una migrazione da SAP a SAP, ma senza nulla che venga portato con sé.

Se usate SAP ERP e avete requisiti B2B reali, il costo totale di possesso favorisce di solito la permanenza nello stack SAP. Altrimenti, fate la valutazione e chiedete a ogni fornitore le voci relative all’integrazione, non solo il confronto delle licenze.

I tempi a confronto

Strada	Tempo per tornare a uno stato manutenuto	Esposizione nel frattempo	Cosa avete alla fine
Continuare	Mai	Cresce senza limiti	La stessa piattaforma, più vecchia
Manutenzione specifica per cliente come ponte	Immediato, ma con copertura ridotta	Problemi noti coperti, quelli nuovi forse a pagamento	Un canale di supporto, nessuna roadmap
Migrazione a Commerce Cloud o ERP Edition	Da 3 a 12 mesi	Limitata alla durata del progetto	Una piattaforma manutenuta e in evoluzione; investimento preservato
Replatforming fuori da SAP	Da 6 a 12 mesi o più	Limitata al progetto, di solito più lunga	Una nuova piattaforma, integrazioni ricostruite, una nuova curva di apprendimento

Tre strade su quattro comportano mesi su una piattaforma che non riceve più patch. Questa esposizione è iniziata il 1° agosto, che abbiate deciso qualcosa o no. Ciò che potete ancora controllare è quanto dura.

Cosa faremmo al vostro posto

Prima settimana: una valutazione del rischio di due pagine sull’installazione attuale, con versioni, perimetro delle personalizzazioni, inventario delle integrazioni e obblighi di compliance. Primo mese: una decisione tra manutenzione specifica per cliente come ponte, migrazione e replatforming, con offerte reali sul tavolo invece di stime indicative. L’ordine conta, perché la disponibilità dei partner di implementazione diminuisce man mano che le aziende rimaste in attesa si muovono tutte insieme. Se state ancora confrontando i partner, la nostra panoramica dei partner SAP Commerce Cloud in Svizzera indica cosa verificare.

Svolgiamo questo assessment come incarico a perimetro fisso. Il supporto è terminato, le opzioni no. Adesso hanno solo un orologio.

Richiedete un assessment di migrazione, approfondite sulla nostra pagina della soluzione SAP Commerce Cloud o partite dalla pagina decisionale on-premise.