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

31 luglio 2026. Questa è la data in cui SAP smette di distribuire patch di sicurezza, aggiornamenti di compliance e supporto alla piattaforma per SAP Commerce on-premise (SAP Help Portal, 2026). Non è una dismissione graduale. Non è un rallentamento progressivo. È un cutoff netto della manutenzione.

Se state leggendo questo articolo nell’aprile 2026, avete quattro mesi. È stretto ma non impossibile — abbiamo migrato Franke in 90 giorni e abbiamo vinto un SAP Quality Award per questo. Ma quel progetto aveva una preparazione aggressiva. Se non avete ancora iniziato, leggete ogni parola di questa checklist.

TL;DR: La manutenzione mainstream di SAP Hybris (Commerce) on-prem termina il 31 luglio 2026. Dopo: niente patch di sicurezza, niente aggiornamenti di compliance, niente supporto Java, niente supporto con SLA. Oltre 3.200 aziende utilizzano SAP Commerce (6sense, 2025). La migrazione a SAP Commerce Cloud richiede tipicamente 6-12 mesi, ma i progetti fast-track possono completarsi in 4-6 mesi. Questo articolo è la checklist completa: 24 punti in 4 fasi, stime dei costi per scenario e una valutazione onesta di cosa succede se non fate nulla. Avviate il vostro assessment ora.

Cosa succede esattamente il 31 luglio 2026

Siamo precisi su cosa cambia — e cosa no. «End of Life» viene usato in modo generico. Il termine corretto è End of Mainstream Maintenance (EoMM), e ha conseguenze specifiche.

Cosa si ferma immediatamente:

• Patch di sicurezza. Niente più aggiornamenti di sicurezza regolari. La vostra piattaforma commerce — quella che elabora dati di pagamento dei clienti — girerà su software non aggiornato. Ogni mese dopo l’EoMM aumenta la vostra superficie d’attacco.
• Aggiornamenti di compliance legale e fiscale. Modifiche IVA, aggiornamenti normativi fiscali, modifiche alla conformità PCI-DSS — SAP non distribuirà più aggiornamenti per questi. Siete soli.
• Aggiornamenti librerie di terze parti. Quando una dipendenza riceve una CVE, SAP non la aggiornerà nella vostra release on-prem. Dovrete fare un fork o accettare la vulnerabilità.
• Supporto versioni Java VM. Le nuove versioni JDK non saranno certificate. Con il tempo, il vostro application server girerà su un runtime Java obsoleto e non supportato.
• Miglioramenti alla piattaforma. Niente nuove funzionalità, niente ottimizzazioni delle prestazioni, niente miglioramenti API. Il prodotto è congelato.

Cosa continua — a un prezzo:

• Supporto specifico per il cliente (CSS). SAP continuerà a fornire supporto, ma passa dalle condizioni SLA mainstream ad accordi specifici per il cliente. Costosi — tipicamente 2-4x il costo della manutenzione mainstream — e senza tempi di risposta garantiti per le patch.
• Accesso alle SAP Notes esistenti. Potrete ancora consultare la knowledge base. Ma fix per nuovi problemi potrebbero non esistere.

Non è teoria. L’83% dei progetti di migrazione dati fallisce o supera il budget (Bloor Group, 2023). Le aziende che hanno successo sono quelle che iniziano presto e pianificano bene.

Una nota sulla terminologia: vedrete «SAP Hybris», «SAP Commerce» e «SAP Commerce Cloud» usati in contesti diversi. SAP Hybris era il nome del brand originale acquisito nel 2013. È stato rinominato in SAP Commerce (il prodotto on-prem) e SAP Commerce Cloud (il prodotto cloud gestito). Quando si parla di «Hybris end of life», ci si riferisce alla versione on-prem — SAP Commerce on-premise versione 2205 è l’ultimo release supportato. SAP Commerce Cloud (il prodotto cloud-hosted) continua a ricevere aggiornamenti trimestrali ed è la destinazione di migrazione target.

Per un’analisi dettagliata di cosa si ferma e cosa continua, leggete la nostra guida alla preparazione EoMM.

Il framework decisionale per la migrazione

Prima di entrare nella checklist, dovete rispondere a una domanda: restare con SAP o cambiare?

Siamo un partner SAP. Abbiamo un interesse commerciale a tenervi su SAP. Quindi siamo onesti su quando ciascun percorso ha senso.

Restate su SAP Commerce Cloud se:

• Utilizzate SAP ERP (S/4HANA, ECC) e dipendete da un’integrazione profonda ERP-commerce. I connettori nativi fanno risparmiare 200-400 ore di lavoro di integrazione custom.
• Il vostro modello B2B commerce utilizza funzionalità specifiche SAP — pricing complesso, gestione contratti, cataloghi specifici per cliente, workflow di approvazione. Il B2B Accelerator di Commerce Cloud gestisce tutto questo nativamente.
• Il vostro team ha competenze SAP Commerce. Un reskilling completo su una piattaforma completamente diversa aggiunge 3-6 mesi e costi significativi.
• Dovete muovervi rapidamente. La migrazione a Commerce Cloud preserva il vostro data model, la business logic e molte personalizzazioni — un re-platform completo no.

Considerate di lasciare SAP se:

• Non avete SAP ERP, o l’integrazione ERP è minima (semplice feed ordini). Senza un’integrazione backend profonda, il premium SAP non si ripaga.
• Il vostro storefront è puramente B2C con catalogo standard, carrello e flussi checkout. Shopify Plus o uno stack composable potrebbe essere più semplice e meno costoso.
• Il vostro team non ha competenze SAP e non volete acquisirle. Trovare sviluppatori SAP Commerce diventa più difficile ogni anno.
• Volete passare a un’architettura composable o headless nel lungo termine — ma attenzione, ci vogliono 9-15 mesi, non 4 (leggete la nostra analisi sul composable commerce).

Per la maggior parte dei clienti SAP Commerce on-prem, la risposta pragmatica è SAP Commerce Cloud. È il percorso con il rischio più basso, l’esecuzione più rapida e quello che preserva il vostro investimento esistente. Detto questo, «pragmatico» non significa «automatico» — questa deve essere una decisione attiva, non un default.

Esplorate la nostra pagina soluzione SAP Commerce Cloud per una panoramica completa delle funzionalità attuali della piattaforma.

La checklist completa per la migrazione

Ventiquattro punti in quattro fasi. Questa è la checklist che utilizziamo con i nostri clienti di migrazione. Stampatela, attaccatela al muro, tracciate ogni punto.

Fase 1: Assessment (Settimane 1-4)

La fase che la maggior parte delle aziende affretta o salta completamente. Non fatelo. Tutto ciò che viene dopo dipende dall’esecuzione corretta di questa fase.

1. Inventariate ogni personalizzazione. Esportate un elenco completo di custom extension, script ImpEx, moduli HAC personalizzati e API della piattaforma modificate. Classificate ciascuna come: ancora necessaria, sostituibile con funzionalità native di Commerce Cloud, oppure obsoleta. Nella nostra esperienza, il 25-35% delle personalizzazioni è eliminabile (consultate il nostro articolo sui 5 errori di migrazione).

2. Mappate tutte le integrazioni. Documentate ogni sistema con cui la vostra piattaforma commerce comunica: ERP, PIM, CRM, gateway di pagamento, provider di spedizione, motore fiscale, sistema loyalty, marketing automation. Per ogni integrazione registrate: protocollo (API, IDoc, file-based), volume dati, frequenza e il team responsabile.

3. Catalogate i vostri storefront. Quanti siti? Quante lingue? Quanti cataloghi prodotto? I setup multi-country con pricing separato, regole fiscali e logica di fulfilment aggiungono complessità significativa. Una migrazione single-storefront, single-country è un progetto fondamentalmente diverso da un deployment a 12 paesi e 6 lingue.

4. Misurate il volume dei dati. Contate: prodotti (incluse varianti), categorie, clienti, ordini (storico), pagine di contenuto, media asset. Questo determina la vostra strategia di migrazione dati e la timeline. Una piattaforma con 50.000 SKU si migra in modo molto diverso da una con 5 milioni.

5. Valutate il vostro footprint SEO. Estraete l’inventario URL completo dalla Google Search Console. Quante pagine indicizzate? Qual è il valore del traffico organico? I siti ad alto valore SEO necessitano di una strategia redirect dettagliata. Perdere ranking durante la migrazione può costare più della migrazione stessa.

6. Valutate la readiness del team. I vostri sviluppatori conoscono SAP Commerce Cloud? Hanno lavorato con il Composable Storefront (Spartacus) o il SAP Commerce Cloud Accelerator? Se no, includete tempo per la formazione. I pattern di deployment cloud (Kubernetes, pipeline CI/CD, gestione degli ambienti) differiscono significativamente dalle operazioni on-prem.

7. Verificate la posizione contrattuale. Controllate i termini del vostro attuale contratto SAP Commerce. Capite cosa succede all’EoMM con il vostro specifico accordo — alcuni contratti passano automaticamente a CSS, altri richiedono un opt-in esplicito. Parlate con il vostro account executive SAP presto. Le negoziazioni di licenza richiedono settimane, e non volete sorprese contrattuali durante la migrazione.

Fase 2: Architettura e pianificazione (Settimane 5-10)

7. Scegliete il vostro approccio storefront. Tre opzioni:

• Composable Storefront (Spartacus/Angular): Il frontend moderno raccomandato da SAP. Headless, disaccoppiato dal backend. Ideale per nuovi sviluppi e team a proprio agio con Angular. Consente release frontend indipendenti.
• Commerce Cloud Accelerator: Lo storefront tradizionale basato su JSP, migrato nel cloud. Percorso più rapido per chi vuole preservare il codice storefront esistente. Meno moderno, ma collaudato.
• Frontend headless custom: Il vostro React/Next.js/Vue frontend che consuma le API di Commerce Cloud. Massima flessibilità, ma siete completamente responsabili del frontend.

Per la maggior parte delle migrazioni sotto pressione temporale, l’approccio Accelerator è il più rapido. Come investimento strategico, il Composable Storefront è la scelta giusta. Analizziamo i trade-off in dettaglio nella nostra analisi sul composable commerce.

8. Progettate l’architettura target. Documentate l’architettura cloud: ambienti Commerce Cloud (dev, staging, production), architettura di integrazione (SAP Integration Suite vs API dirette), strategia CDN ed edge caching, e setup monitoring/alerting.

9. Pianificate il rework delle integrazioni. Le integrazioni on-prem spesso usano connessioni dirette al database, file drop o middleware on-prem. In Commerce Cloud, tutto passa attraverso API o SAP Integration Suite. Ogni integrazione necessita di un piano di migrazione. Budget: 3-5 giorni per integrazione per analisi e redesign.

10. Definite la strategia di migrazione dati. Decidete: migrazione big-bang (caricamento completo dei dati in una finestra di cutover) o migrazione iterativa (caricamento progressivo con delta sync). Per piattaforme con oltre 1 milione di prodotti, raccomandiamo fortemente la migrazione iterativa con almeno tre prove prima del go-live.

11. Create il piano di migrazione SEO. Mappate ogni URL on-prem sul suo equivalente Commerce Cloud. Pianificate redirect 301 per tutti gli URL che cambiano. Impostate un benchmark pre-migrazione nella Google Search Console. Dettagli nella sezione SEO sotto.

12. Definite la strategia degli ambienti. Commerce Cloud fornisce ambienti di development, staging e production. Impostate le pipeline CI/CD presto. Automatizzate i deployment dal primo giorno — deployment manuali in questa fase sono un segnale d’allarme.

13. Congelate lo scope. Mettetelo per iscritto. Fatelo firmare. La causa principale dei ritardi nelle migrazioni è lo scope creep — «già che ci siamo, potremmo anche…» No. Prima migrare, poi migliorare. Questa disciplina ci ha fatto risparmiare 4 settimane nel progetto Franke.

Fase 3: Sviluppo e migrazione (Settimane 11-30)

14. Configurate gli ambienti Commerce Cloud. Provisionate e configurate tutti gli ambienti. Verificate che le build pipeline funzionino. Validate che potete deployare, testare e promuovere codice attraverso l’intera pipeline prima di scrivere business logic.

15. Ricostruite o migrate lo storefront. Con l’Accelerator, portate i template JSP e gli asset frontend. Con il Composable Storefront, costruite il nuovo frontend dalle API Commerce Cloud. In entrambi i casi, iniziate con homepage, pagine categoria e pagine dettaglio prodotto — i template con il traffico più alto.

16. Rielaborate le integrazioni. Migrate ogni integrazione all’architettura cloud progettata nella Fase 2. Testate con dati reali, non mock. I test di integrazione sono il punto in cui emerge il 60% dei bug di migrazione (Standish Group, 2020). Testate presto. Testate spesso.

17. Eseguite la migrazione dati (prove). Almeno due migrazioni di prova complete prima del cutover reale. Misurate: tempo totale, accuratezza dei dati e tasso di errore. Risolvete i problemi tra le prove. Ogni prova dovrebbe essere più rapida e pulita della precedente.

18. Implementate le modifiche SEO. Deployate la mappa redirect. Configurate gli URL canonici. Impostate la XML sitemap. Verificate robots.txt. Testate con uno strumento di crawling (Screaming Frog, Sitebulb) contro l’ambiente di staging.

19. Ottimizzate le prestazioni. Commerce Cloud ha caratteristiche di performance diverse dall’on-prem. CDN caching, tempi di risposta API e comportamento cold-start richiedono tutti test e tuning. Impostate metriche target: tempo di caricamento pagina sotto i 3 secondi, Time to Interactive sotto i 5 secondi, Core Web Vitals superati.

Fase 4: Testing e go-live (Settimane 31-38)

20. Eseguite UAT completo. User Acceptance Testing con utenti business reali, non solo sviluppatori. Coprite: navigazione prodotti, ricerca, carrello, checkout, pagamento, conferma ordine, resi, workflow B2B (se applicabile). Testate in ogni storefront, ogni lingua, ogni segmento cliente.

21. Test di performance sotto carico. Load test con pattern di traffico realistici. Simulate il traffico dei giorni di picco (Black Friday, picchi stagionali). Commerce Cloud scala automaticamente, ma il vostro codice custom e le integrazioni potrebbero non farlo. Identificate i colli di bottiglia prima che vi trovino in produzione.

22. Validate la migrazione SEO. Confrontate l’inventario URL di staging con quello di produzione. Verificate che ogni redirect funzioni. Controllate che la sitemap sia completa. Testate i dati strutturati (JSON-LD) con il Rich Results Test di Google.

23. Eseguite il cutover. Il piano di cutover deve essere provato almeno una volta. Passaggi chiave: bloccare le modifiche di contenuto sulla vecchia piattaforma, eseguire la migrazione dati delta finale, switchare il DNS, verificare tutte le integrazioni, monitorare i tassi di errore per 48 ore. Tenete un piano di rollback documentato e testato.

24. Monitoring post-go-live. Monitorate per minimo 2 settimane: tassi di errore, conversion rate rispetto alla baseline pre-migrazione, tasso di indicizzazione dei motori di ricerca, tassi di errore delle integrazioni e volume dei ticket di supporto clienti. Impostate alert per qualsiasi deviazione dalla baseline.

Calcolatore della timeline

Non tutte le migrazioni sono uguali. Ecco cosa determina la timeline:

Leggendo questi numeri ad aprile 2026: Se siete nella categoria fast-track, potete ancora rispettare la scadenza di luglio con un’esecuzione aggressiva. Complessità standard? Mancherete la scadenza ma potrete essere live entro il Q4 2026 — il che significa 3-5 mesi di supporto specifico per il cliente. Complesso? Avreste dovuto iniziare 12 mesi fa. Il meglio che potete fare ora è iniziare immediatamente e minimizzare il tempo nella zona di pericolo.

Stime dei costi per scenario

Ce lo chiedono in ogni prima conversazione. Ecco range onesti dal nostro portfolio progetti:

Fast-track (singolo storefront, integrazioni limitate): 300.000-500.000 USD. Presuppone scope focalizzato, competenze SAP esistenti nel team e disponibilità a rimandare le personalizzazioni non essenziali al post-migrazione. Pensatelo come un platform lift con scope controllato.

Mid-market (2-3 storefront, complessità moderata): 500.000-800.000 USD. La maggior parte dei nostri progetti di migrazione ricade qui. Il budget include assessment, sviluppo, migrazione dati, rework integrazioni, performance testing e supporto go-live. Non include la licenza Commerce Cloud — quello è un costo annuale separato.

Enterprise (5+ storefront, B2B complesso, multi-country): 800.000-2 milioni USD+. Il range è ampio perché la complessità enterprise varia enormemente. Un’operazione B2B in 12 paesi con motori di pricing custom, workflow di approvazione e integrazione ERP profonda è un progetto fondamentalmente diverso da un’operazione B2C con 5 storefront e checkout standard.

Questi sono costi di migrazione — il progetto una tantum per passare dall’on-prem al cloud. La licenza SAP Commerce Cloud è annuale e dipende dal vostro GMV e volume ordini.

Cosa non è incluso in queste stime: costi di licenza Commerce Cloud (annuali), licenze di strumenti di terze parti (PIM, ricerca, CMS se utilizzate provider esterni), tempo del team interno e qualsiasi lavoro di enhancement post-migrazione. Prevedete un buffer di contingenza del 15-20% per gli imprevisti — problemi di qualità dei dati, sorprese nelle integrazioni e chiarimenti di scope che inevitabilmente emergono durante la migrazione.

Accelerazione dei costi dopo la scadenza: I partner di migrazione — noi inclusi — registrano un picco della domanda. Ogni società di consulenza con competenze SAP Commerce è completamente prenotata fino al Q4 2026. Se iniziate a luglio, pagherete tariffe premium per urgenza premium. Iniziare ad aprile vi offre più opzioni e pricing migliore.

Il costo nascosto del non fare nulla: Il supporto specifico per il cliente dopo l’EoMM costa 2-4x la manutenzione mainstream. Per un’azienda che paga 200.000 USD/anno di manutenzione SAP, sono 400.000-800.000 USD all’anno solo per tenere tutto in funzione — senza miglioramenti, nuove funzionalità o patch di sicurezza garantite. Due anni di CSS costano più della maggior parte delle migrazioni.

Migrazione SEO: non perdete i vostri ranking

Questa sezione esiste perché abbiamo visto aziende eseguire migrazioni tecniche impeccabili e poi perdere il 40-60% del traffico organico perché nessuno aveva pianificato la transizione SEO. Il traffico organico rappresenta spesso il 30-50% del fatturato e-commerce. Fate i conti su cosa significa perderne la metà per il vostro business.

Prima della migrazione:

1. Baseline su tutto. Esportate dalla Google Search Console: tutti gli URL indicizzati, dati sui click, dati sulle impression, posizione media per le query principali. Registrate settimanalmente a partire da ora — vi serve la linea di tendenza, non un singolo snapshot.
2. Crawlate il sito attuale. Usate Screaming Frog o Sitebulb. Ottenete l’inventario URL completo, la struttura dei link interni, i canonical e i dati strutturati. Questo è il vostro documento di riferimento.
3. Mappate ogni URL. Create un foglio di calcolo: vecchio URL → nuovo URL → tipo di redirect (301 nella quasi totalità dei casi). Se la struttura URL cambia, questo foglio è critico.

Durante la migrazione:

4. Implementate i redirect presto. Non lasciate questo alla settimana del cutover. Costruite le regole di redirect mentre costruite la nuova piattaforma. Testate su staging.
5. Preservate i metadati. Titoli pagina, meta description, struttura heading e dati strutturati (JSON-LD, schema prodotto, schema breadcrumb) devono tutti essere trasferiti. Ricrearli da zero garantisce perdita di ranking.
6. Mantenete aggiornata la XML sitemap. La nuova sitemap deve essere pronta prima del go-live. Inviatela alla Search Console immediatamente dopo lo switch DNS.

Dopo la migrazione:

7. Monitorate quotidianamente per 4 settimane. Osservate: tasso di indicizzazione (quanto velocemente Google rileva i nuovi URL), tasso di errori 404 (redirect mancanti), traffico organico rispetto alla baseline e posizioni ranking per le 50 query principali.
8. Risolvete i problemi velocemente. Se la Search Console mostra un picco di 404 o un calo di copertura, risolvete lo stesso giorno. Non nel prossimo sprint. Lo stesso giorno. Le prime 2-4 settimane dopo la migrazione sono il periodo in cui Google ri-valuta l’intero sito.

E l’approccio Franke?

Abbiamo migrato Franke da SAP Hybris a SAP Commerce Cloud in 90 giorni. SAP ci ha assegnato un Quality Award. Il playbook completo è pubblicato qui: Da SAP Hybris a Commerce Cloud in 90 giorni.

La versione breve: 30 giorni di preparazione prima del kickoff, gestione dello scope senza compromessi (35% delle personalizzazioni eliminate), workstream paralleli e delivery iterativa. Non tutte le aziende possono fare 90 giorni — Franke aveva uno scope focalizzato e un team allineato. Ma la metodologia si applica a qualsiasi timeline.

Lezioni chiave dall’approccio Franke che valgono per ogni migrazione:

• Auditare prima di migrare. Abbiamo scoperto che il 35% delle personalizzazioni di Franke erano obsolete o sostituibili con funzionalità native di Commerce Cloud. Sono il 35% in meno di codice da migrare, testare e mantenere.
• Workstream paralleli. Non mettete in sequenza storefront, integrazioni e migrazione dati. Eseguiteli in parallelo con coordinamento quotidiano. Questo da solo può comprimere una timeline di 12 mesi in 8 mesi.
• Delivery iterativa, non big-bang. Deployate nel cloud presto, anche se incompleto. Ottenete feedback reale da infrastruttura reale. La delivery agile mostra un tasso di successo del 42% contro il 13% del waterfall (Standish Group, 2020).

Leggete il caso di successo completo di Franke per i risultati dettagliati.

La valutazione del rischio del «non fare nulla»

Alcune aziende guarderanno questa checklist e decideranno: ce ne occupiamo dopo luglio 2026. Ecco come si presenta quella scelta.

Rischio sicurezza. La piattaforma smette di ricevere patch di sicurezza. SAP Commerce elabora dati dei clienti, informazioni di pagamento e dati personali. Gestire una piattaforma commerce non aggiornata viola lo spirito — e probabilmente la lettera — di PCI-DSS, GDPR e della nDSG svizzera. In caso di audit, «non abbiamo fatto la migrazione in tempo» non è una difesa.

Rischio compliance. Le regole IVA cambiano. Le normative fiscali si evolvono. I requisiti di protezione dati si aggiornano. Senza che SAP distribuisca patch di compliance, dovete implementarle voi stessi. La maggior parte delle aziende non ha l’expertise per modificare in sicurezza i moduli core di compliance di SAP Commerce.

Escalation dei costi. Il supporto specifico per il cliente costa 2-4x la manutenzione mainstream. E il costo della migrazione non diminuisce nel tempo — aumenta. Gli sviluppatori con esperienza SAP Hybris on-prem diventano più rari. Le società di consulenza sono al completo. I prezzi salgono dopo la scadenza, non prima.

Fuga di talenti. Gli sviluppatori SAP Commerce si stanno spostando verso competenze cloud. Trovare qualcuno che voglia lavorare su una piattaforma on-prem end-of-life diventa più difficile ogni trimestre. Il vostro team esistente potrebbe trasferirsi ad aziende che utilizzano stack moderni.

Svantaggio competitivo. Mentre voi mantenete una piattaforma congelata, i concorrenti su Commerce Cloud ricevono nuove funzionalità, miglioramenti delle prestazioni e capacità AI ogni trimestre. Commerce Cloud rilascia 4 aggiornamenti principali all’anno. L’on-prem dopo l’EoMM ne rilascia zero.

Esposizione assicurativa e di audit. I fornitori di cyber insurance chiedono sempre più spesso lo stato di manutenzione della piattaforma. Gestire una piattaforma e-commerce non aggiornata con dati dei clienti può influire sulle condizioni di copertura o sui premi. Gli auditor esterni — che si tratti di SOC 2, ISO 27001 o PCI-DSS — segnaleranno una piattaforma commerce end-of-maintenance come finding materiale. Questo crea visibilità a livello di consiglio di amministrazione che probabilmente non desiderate.

Prossimi passi

Se avete letto fin qui, conoscete la situazione. Quattro mesi sono stretti ma praticabili per scenari fast-track. Per tutto il resto, iniziate ora e minimizzate la finestra di esposizione.

1. Prenotate una call di assessment. Conduciamo un assessment strutturato della migrazione in 2-3 settimane. Include: inventario personalizzazioni, mappa integrazioni, punteggio di complessità, stima della timeline e range di budget. Iniziate qui.
2. Leggete il materiale di supporto. La nostra guida alla preparazione EoMM copre in dettaglio cosa si ferma. Il playbook 90 giorni mostra come si presenta un’esecuzione rapida. L’analisi sul composable commerce tratta onestamente l’opzione «lasciare SAP».
3. Visitate la nostra pagina campagna on-prem per risorse dedicate e offerte di migrazione.
4. Non aspettate il Q3. Ogni settimana di ritardo riduce le vostre opzioni. La differenza tra iniziare ad aprile e iniziare a giugno è la differenza tra rispettare la scadenza e mancarla.

La scadenza non si sposta. La vostra preparazione sì. Parliamone.