Da SAP Hybris a Commerce Cloud in 90 giorni: un playbook di migrazione

Novanta giorni dal kickoff al go-live sono pochi per un progetto SAP Commerce. La maggior parte delle aziende prevede da otto a dodici mesi per passare da SAP Hybris a SAP Commerce Cloud, e per piattaforme grandi e molto personalizzate è il piano giusto. Per una piattaforma di medie dimensioni, con un team preparato e un perimetro bloccato, 90 giorni sono realizzabili. Questo articolo descrive il metodo che usiamo: cosa succede prima che parta il conteggio, cosa consegna ogni sprint e cosa lasciamo fuori di proposito.

Il ritmo lo conosciamo dal nostro lavoro. Per Franke abbiamo portato in produzione la piattaforma SAP Commerce Cloud in 90 giorni; il dato si riferisce al lancio commerce, parte di una collaborazione più lunga in cui abbiamo sostituito una vecchia piattaforma con un’architettura headless. Il progetto ha ricevuto lo SAP Quality Award per «Rapid Time to Value» (storia di successo di Franke).

In sintesi: una piattaforma SAP Hybris di medie dimensioni può arrivare su SAP Commerce Cloud in 90 giorni se prima ci sono 30 giorni di preparazione: audit della piattaforma, profilazione dei dati, ambienti, allineamento del team. Seguono tre sprint: piattaforma di base e primo caricamento dati (giorni 1-21), integrazioni e frontend (giorni 22-50), prestazioni, test di accettazione, prova generale e go-live (giorni 51-90). A reggere il tutto sono disciplina sul perimetro, filoni di lavoro paralleli e demo settimanali. Da quando la manutenzione mainstream dell’on-premise è terminata il 31 luglio 2026, lo stesso piano è la via d’uscita più rapida.

Preferite un partner a una guida fai-da-te? Spadoom è SAP Gold Partner per Cloud ERP e Customer Experience e realizza progetti SAP Commerce Cloud in Svizzera, Germania, Austria e Italia, sia con la Cloud Edition sia con la ERP Edition per S/4HANA Public Cloud. Richiedete un colloquio di scoping.

Perché 90 giorni sono realizzabili?

Nella nostra esperienza, i tempi lunghi di migrazione sono gonfiati più dagli sprechi che dalla complessità. Una migrazione in 90 giorni non taglia gli angoli; elimina tre cose che consumano tempo senza creare valore.

La paralisi da analisi. I team passano mesi a documentare requisiti che esistono già nel sistema in funzione. La piattaforma attuale è la migliore specifica che avete: leggetela invece di riscriverla.

La replica uno a uno di personalizzazioni che non servono a nessuno. Un workaround del 2017 non va portato sulla nuova piattaforma solo perché esiste sulla vecchia.

Fasi sequenziali con ritardi nei passaggi di consegne. Ogni approvazione, passaggio e cambio di contesto tra team costa giorni, spesso una settimana.

Tolte queste tre cose, il lavoro vero (migrazione dei dati, configurazione della piattaforma, ricollegamento delle integrazioni, test) rientra in 90 giorni per una piattaforma commerce di medie dimensioni. Per quelle più grandi lo stesso metodo accorcia comunque il progetto, ma non a 90 giorni; la nostra checklist di migrazione mostra gli intervalli tipici per scenario.

Cosa succede prima che parta il conteggio? (settimane da -4 a 0)

Il conteggio dei 90 giorni parte con il kickoff. I 30 giorni precedenti decidono se il progetto sarà uno sprint sotto controllo o una corsa affannosa.

Audit della piattaforma (settimane da -4 a -3)

Mappiamo tutto ciò che c’è nell’istanza SAP Hybris attuale:

• Extension personalizzate: contarle, classificarle (ancora necessarie, sostituibili, obsolete) e stimare l’impegno per ciascuna.
• Modelli dati: tipi, relazioni e attributi personalizzati, e quali di questi corrispondono direttamente a Commerce Cloud.
• Integrazioni: ogni connessione in entrata e in uscita (ERP, PIM, CRM, pagamenti, spedizioni, fiscalità) con protocollo, formato e frequenza.
• Punti caldi delle personalizzazioni: la piccola parte del codice personalizzato che porta la maggior parte della logica di business.

L’audit mostra regolarmente che una parte delle extension era un workaround per limiti dell’on-premise che Commerce Cloud copre nello standard. Queste escono subito dal perimetro, e ognuna è codice che non dovete migrare, testare e mantenere. I cinque errori più comuni nella migrazione iniziano proprio dove questo audit viene saltato.

Profilazione dei dati (settimane da -3 a -2)

Prima di toccare gli strumenti di migrazione, bisogna capire i dati. Profilate ogni entità per completezza, coerenza e qualità. Trovate duplicati, record orfani e dati che nessuno tocca da anni. Costruite e testate la pipeline di estrazione e caricamento con un piccolo campione. I problemi trovati qui costano ore; trovati nello Sprint 3 costano settimane.

Predisposizione degli ambienti (settimane da -2 a -1)

Predisponete gli ambienti SAP Commerce Cloud (sviluppo, staging, produzione), configurate le pipeline di build e deployment nel Cloud Portal, impostate monitoraggio e alerting e date accesso a tutti. Lavoro poco spettacolare, e tutto necessario. La documentazione di SAP Commerce Cloud descrive in dettaglio il modello di ambienti e di deployment.

Allineamento del team (settimana -1)

Finalizzare il backlog. Dare a ogni filone di lavoro (piattaforma, dati, integrazioni, frontend, test) un responsabile chiaro. Concordare la Definition of Done per ogni incremento, impostare stand-up quotidiani e demo settimanali per gli stakeholder, così che dal primo giorno tutti sappiano su cosa lavorano.

Cosa si completa nello Sprint 1? (giorni 1-21)

Le prime tre settimane portano la piattaforma di base su Commerce Cloud con i vostri modelli dati e la configurazione di base.

• Migrazione del modello dati: tipi, enum e relazioni personalizzati, convalidati rispetto all’audit.
• Logica di business essenziale: le personalizzazioni critiche individuate nell’audit, come calcolo del carrello, regole di prezzo, promozioni e calcolo delle imposte.
• Storefront di base: il SAP Composable Storefront con il vostro catalogo prodotti. Ancora nessuno stile personalizzato; prima viene la correttezza funzionale.
• Primo caricamento dei dati: una migrazione completa verso lo staging, con conteggi dei record, integrità dei dati e flussi di business principali convalidati.

Cosa non succede nello Sprint 1: rifiniture grafiche, integrazioni non critiche (analytics, recensioni, loyalty), ottimizzazione delle prestazioni e logica per i casi limite. Dire di no a queste cose è ciò che tiene lo sprint nei tempi.

Traguardo al giorno 21: uno storefront funzionante sullo staging di Commerce Cloud con dati reali, logica di business essenziale e un checkout di base. Gli stakeholder possono sfogliare i prodotti, metterli nel carrello ed effettuare un ordine. Non ha ancora un aspetto finito, ma funziona.

Come si ricompongono le integrazioni nello Sprint 2? (giorni 22-50)

Dimostrata la piattaforma di base, lo Sprint 2 ricollega l’ecosistema, in ordine di criticità per il business:

1. ERP e gestione ordini: esportazione ordini, allineamento delle giacenze, aggiornamenti dei prezzi
2. Fornitore di pagamenti: ricollegamento del gateway tramite l’integrazione pagamenti di Commerce Cloud
3. Spedizioni e logistica: calcolo delle tariffe, etichette, tracciamento
4. PIM e contenuti: feed dei dati prodotto, sincronizzazione dei media
5. CRM e CDP: sincronizzazione dei dati cliente

Per ogni integrazione: convalidare il contratto API esistente, aggiornare endpoint e autenticazione, eseguire test end-to-end con dati reali e documentare le differenze di comportamento.

In parallelo il team frontend applica il branding, costruisce componenti UI personalizzati, ottimizza per il mobile e si occupa della SEO: metadati, dati strutturati e redirect dai vecchi URL.

Traguardo al giorno 50: un deployment Commerce Cloud completamente integrato, con tutte le integrazioni critiche attive, un frontend coerente con il marchio e un flusso ordini completo dalla navigazione all’evasione.

Cosa rende diverso lo Sprint 3? (giorni 51-90)

L’ultima fase riguarda la fiducia. Il sistema funziona; ora dimostrate che è pronto per la produzione.

Test di prestazione (giorni 51-60). Test di carico con modelli di traffico realistici e simulazione del giorno di picco. Trovare ed eliminare i colli di bottiglia, convalidare l’auto-scaling, confrontare i tempi di caricamento con gli obiettivi.

Test di accettazione (giorni 55-70). Gli utenti di business testano ogni flusso critico con account cliente e dati prodotto reali, e tutte le integrazioni in condizioni realistiche. Tutti i problemi P1 e P2 vengono risolti.

Prova generale della migrazione dei dati (giorni 65-75). Eseguire l’intera pipeline da un capo all’altro e misurarne la durata, che determina la vostra finestra di cutover. Convalidare la migrazione delta per i dati creati tra prova generale e go-live e testare la procedura di rollback. Questo passo non è facoltativo.

Go-live e stabilizzazione (giorni 85-90). Eseguire il runbook: migrazione delta, switch del DNS, poi 48 ore di monitoraggio con tutto il team in reperibilità.

Cosa fa reggere una tempistica di 90 giorni?

Guardando ai nostri lanci commerce più rapidi, Franke compreso, cinque fattori hanno fatto la differenza.

Disciplina sul perimetro. Migriamo ciò che serve al business, non tutto ciò che esiste. Le personalizzazioni obsolete restano indietro, senza nostalgia.

Filoni di lavoro paralleli. Piattaforma, dati, integrazioni e frontend procedono in parallelo con punti di sincronizzazione quotidiani. Se un team è bloccato, gli altri continuano.

Investimento precoce nei dati. La profilazione inizia prima del kickoff, così il primo giorno tutti sanno cosa viene migrato e cosa resta indietro.

Rilasci iterativi con demo settimanali. Gli stakeholder vedono progressi ogni settimana, i problemi emergono presto e le correzioni di rotta richiedono giorni, non mesi.

Un team esperto. Chi l’ha già fatto riconosce presto schemi e insidie. Questa esperienza fa risparmiare più tempo di qualsiasi strumento.

Velocità e qualità non sono opposte. Per Franke lo SAP Quality Award è stato assegnato per «Rapid Time to Value», e dice esattamente questo.

La scadenza EoMM è già passata?

La manutenzione mainstream di SAP Commerce on-premise è terminata il 31 luglio 2026 (SAP Help Portal). Se siete ancora on-premise, ora siete in manutenzione specifica per il cliente: niente patch di sicurezza regolari, niente aggiornamenti normativi, supporto a prezzo individuale. Cosa significa nel dettaglio e quali misure transitorie hanno senso lo trovate in Il supporto on-premise di SAP Commerce è terminato: e adesso?.

Il conto del playbook non cambia: 30 giorni di preparazione più 90 giorni di migrazione fanno circa 120 giorni. È cambiato il fatto che ognuno di questi giorni ora passa fuori dalla manutenzione mainstream. È un motivo per iniziare la preparazione adesso invece di aspettare il momento perfetto, e per tenere il perimetro stretto come il playbook richiede. Se la vostra piattaforma è troppo grande per 90 giorni, suddividetela in ondate, così i primi mercati lasciano presto il sistema on-premise.

Per uno sguardo più ampio su ciò che SAP Commerce Cloud offre oggi, consultate la nostra pagina SAP Commerce Cloud. Se state ancora scegliendo un partner di implementazione, la nostra panoramica dei migliori partner SAP Commerce Cloud in Svizzera elenca i criteri che contano.

---

Analizziamo la vostra istanza SAP Hybris, mappiamo le personalizzazioni, profiliamo i dati e costruiamo un piano di migrazione realistico, 90 giorni dove il perimetro lo consente. Contattateci.

Domande frequenti

90 giorni sono realistici per ogni migrazione SAP Commerce?

No. Novanta giorni funzionano per piattaforme commerce di medie dimensioni con una preparazione pulita e un perimetro bloccato. Progetti con più storefront, molto lavoro di integrazione o grandi volumi di dati richiedono di solito da quattro a sei mesi o più. La variabile decisiva è quanta personalizzazione superflua e quanto debito tecnico si porta dietro la piattaforma.

Qual è il rischio maggiore di una migrazione in 90 giorni?

La migrazione dei dati. Per questo la profilazione dei dati inizia nella fase di preparazione, prima che parta il conteggio dei 90 giorni. Il primo giorno dello Sprint 1 conoscete volumi, problemi di qualità e regole di trasformazione, e la prova generale dello Sprint 3 convalida l’intera pipeline prima del go-live.

Quante persone servono per una migrazione in 90 giorni?

È tipico un team snello: alcuni consulenti Spadoom per SAP Commerce, frontend e integrazione, più product owner, business analyst e referente IT lato cliente. Contano più i filoni di lavoro paralleli con responsabilità chiare che il numero di persone; un team più grande con passaggi di consegne sequenziali è di solito più lento.

Cosa succede alla SEO migrando da Hybris a Commerce Cloud?

Le modifiche agli URL richiedono un piano di redirect completo: mappare tutti i vecchi URL, implementare redirect 301, trasferire metadati e dati strutturati e inviare la nuova sitemap. Con redirect completi, il traffico organico di solito si riprende nel giro di poche settimane. Monitorate Search Console ogni giorno nel primo mese e correggete i 404 in giornata.

La vecchia piattaforma Hybris e Commerce Cloud possono funzionare in parallelo?

Sì, e lo consigliamo. La vecchia piattaforma continua a servire il traffico di produzione mentre test di accettazione e di prestazione girano su Commerce Cloud. La finestra di cutover per migrazione delta e switch del DNS dura in genere alcune ore. Riportare il DNS indietro è un rollback pulito solo se gli ordini ricevuti sulla nuova piattaforma dopo il cutover vengono riportati nel vecchio sistema: pianificate questo passo nel runbook.