Da SAP Hybris a Commerce Cloud in 90 giorni: Una guida alla migrazione

Abbiamo migrato Franke da SAP Hybris a SAP Commerce Cloud in 90 giorni. Novanta. Il team IT del cliente pensava che stessimo scherzando quando abbiamo messo la timeline sul tavolo. La maggior parte delle aziende lo tratta come un progetto da 8-12 mesi.

SAP ci ha assegnato un Quality Award per questo progetto. E questo articolo condivide la guida vera: la metodologia, la timeline, le decisioni che l’hanno reso possibile. Non la versione marketing. Quella reale.

TL;DR: Abbiamo migrato Franke da SAP Hybris a Commerce Cloud in 90 giorni (SAP Quality Award). La chiave: 30 giorni di preparazione prima del kickoff, gestione dello scope senza compromessi (35% delle personalizzazioni eliminate), workstream paralleli e delivery iterativa. Gli approcci agili mostrano tassi di successo del 42% contro il 13% del waterfall (Standish Group, 2020). Questa guida copre ogni fase, dall’audit al go-live.

Vi serve un partner invece di una guida fai-da-te? Spadoom è SAP Gold Partner specializzato in implementazioni SAP Commerce Cloud in Svizzera, Germania, Austria e Italia: sia Cloud Edition che la nuova ERP Edition. Richiedete una sessione di scoping gratuita o leggete il caso studio Franke a 90 giorni.

Perché 90 giorni sono raggiungibili?

L’83% dei progetti di migrazione dati fallisce o sfora il budget (Bloor Group, 2023). Suona terrificante. Ma nella nostra esperienza, la maggior parte delle timeline lunghe è gonfiata dagli sprechi, non dalla complessità.

Una migrazione in 90 giorni non significa tagliare gli angoli. Significa eliminare tre cose che mangiano tempo senza aggiungere valore.

La paralisi da analisi. I team passano mesi a documentare requisiti che esistono già nel sistema in funzione. Basta guardare quello che avete. Il sistema è lì.

La replica 1:1 di personalizzazioni inutili. Spostare codice che non serve sulla piattaforma di destinazione. Non migrate un workaround del 2017 solo perché c’è. Se la ruota era rotta, non portatevela dietro.

Le fasi sequenziali con ritardi nei passaggi di consegna. Aspettare approvazioni, handover, cambi di contesto tra team. Ogni passaggio di consegna perde una settimana.

Eliminate questi tre fattori, e il lavoro vero (migrazione dati, configurazione della piattaforma, riconnessione delle integrazioni, testing) entra in 90 giorni per una piattaforma commerce di medie dimensioni.

Cosa succede prima che parta l’orologio? (Settimane da -4 a 0)

L’orologio dei 90 giorni parte al kickoff. Ma i 30 giorni prima del kickoff fanno la differenza tra uno sprint controllato e un’improvvisazione caotica. I progetti agili riescono nel 42% dei casi contro il 13% del waterfall (Standish Group, 2020). Quel vantaggio inizia con una preparazione adeguata.

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

Mappiamo tutto nell’istanza SAP Hybris attuale. Extension personalizzate: contarle, classificarle (ancora necessarie / sostituibili / obsolete), stimare lo sforzo di migrazione per ciascuna. Modelli dati: documentare tipi custom, relazioni, attributi. Identificare cosa si mappa direttamente su Commerce Cloud e cosa richiede trasformazione. Integrazioni: elencare ogni connessione in ingresso e in uscita (ERP, PIM, CRM, pagamenti, spedizioni, fiscalità). Documentare protocolli, formati dati, frequenze. Hotspot delle personalizzazioni: identificare il 20% di codice custom che gestisce l’80% della logica di business.

Per Franke, questo audit ha rivelato che il 35% delle extension custom erano workaround per limitazioni on-prem che Commerce Cloud gestisce nativamente. Le abbiamo escluse subito dallo scope. Tre settimane di sforzo migratorio risparmiate lì. È questo il potere di un audit fatto bene.

Profiling dei dati (settimana da -3 a -2)

Prima di toccare gli strumenti di migrazione, capite i vostri dati. Il 64% delle organizzazioni indica la qualità dei dati come la principale sfida di integrità dei dati (McKinsey, 2024). Profilate ogni entità per completezza, coerenza, qualità. Identificate duplicati, record orfani, dati che nessuno tocca da 2+ anni. Costruite e testate la pipeline ETL con un piccolo campione. Un punto in tempo ne salva cento.

Setup degli ambienti (settimana da -2 a -1)

Provisionare gli ambienti SAP Commerce Cloud (sviluppo, staging, produzione). Configurare le pipeline CI/CD. Impostare monitoraggio e alerting. Garantire l’accesso a tutti i membri del team. Niente di glamour. Tutto necessario.

Allineamento del team (settimana -1)

Finalizzare il backlog. Assegnare responsabilità chiare per ogni workstream: piattaforma, dati, integrazioni, frontend, testing. Concordare la Definition of Done per ogni incremento. Stabilire standup giornalieri e demo settimanali per gli stakeholder. Al giorno 1 tutti sanno cosa fare.

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

Prime tre settimane. Piattaforma core funzionante su Commerce Cloud con i vostri modelli dati e la configurazione base. Nessuna distrazione.

Migrazione del modello dati. Trasferire tipi custom, enum e relazioni su Commerce Cloud. Validare rispetto all’audit della piattaforma.

Logica di business core. Migrare il 20% critico delle personalizzazioni identificate nell’audit. Calcolo del carrello, regole di prezzo, configurazione del motore promozioni, calcolo fiscale. Le cose senza cui il business non può funzionare.

Storefront base. Fare il deploy del Composable Storefront con il vostro catalogo prodotti. Nessuno styling custom ancora. Prima la correttezza funzionale.

Primo caricamento dati. Eseguire una migrazione dati completa su staging. Validare conteggi dei record, integrità dei dati, flussi di business chiave.

Cosa NON viene fatto: rifinitura del design visuale, integrazioni non critiche (analytics, piattaforme di recensioni, loyalty), ottimizzazione delle performance, logica di business per casi limite. Nello sprint 1 diciamo no a molte cose. È proprio il punto.

Milestone al giorno 21: uno storefront funzionante su Commerce Cloud staging con dati reali, logica di business core e flusso di checkout base. Gli stakeholder possono navigare i prodotti, aggiungere al carrello, completare un ordine. Non è bello da vedere. Funziona.

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

Con la piattaforma core dimostrata, lo sprint 2 riconnette l’ecosistema e raffina l’esperienza. Le integrazioni si affrontano in ordine di criticità per il business:

1. ERP/gestione ordini: export ordini, sincronizzazione inventario, aggiornamenti prezzi
2. Provider di pagamento: riconnettere il gateway di pagamento con l’estensione payment di Commerce Cloud
3. Spedizioni/logistica: calcolo tariffe, generazione etichette, aggiornamenti tracking
4. PIM/contenuti: feed dati prodotto, sincronizzazione dei media asset
5. CRM/CDP: sincronizzazione dei dati cliente

Per ogni integrazione: validare il contratto API esistente, aggiornare endpoint e autenticazione, eseguire test end-to-end con dati reali, documentare eventuali differenze comportamentali.

In parallelo: applicare lo styling del brand al Composable Storefront, implementare i componenti UI custom, ottimizzare per mobile, gestire i requisiti SEO (meta tag, dati strutturati, redirect URL dai vecchi percorsi).

Milestone al giorno 50: un deployment Commerce Cloud completamente integrato con tutte le integrazioni critiche live, frontend coerente con il brand e flusso ordini end-to-end dalla navigazione all’evasione. Ora sì che si ragiona.

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

La fase finale riguarda la confidenza. Avete già un sistema funzionante. Ora dimostrate che è pronto per la produzione.

Performance testing (giorni 51-60). Test di carico con pattern di traffico realistici. Simulazione del giorno di picco. Identificare e risolvere i colli di bottiglia. Validare il comportamento dell’auto-scaling. Confrontare i tempi di caricamento pagina con gli obiettivi.

User acceptance testing (giorni 55-70). Gli utenti business testano ogni flusso critico. Account clienti reali, dati prodotto reali. Verificare tutte le integrazioni in condizioni realistiche. Risolvere tutti i problemi P1 e P2.

Prova generale della migrazione dati (giorni 65-75). Eseguire l’intera pipeline di migrazione dati end-to-end. Misurare il tempo trascorso: definisce la vostra finestra di cutover. Validare la migrazione delta per i dati creati tra la prova generale e il go-live. Testare le procedure di rollback. Questo passo non è negoziabile. Saltarlo significa giocare d’azzardo.

Go-live e stabilizzazione (giorni 85-90). Eseguire il runbook di go-live. Migrazione dati delta. Cambio del DNS. Monitoraggio per 48 ore con l’intero team in standby.

Cosa ha fatto riuscire la migrazione Franke?

Il 90% delle aziende che hanno migrato la piattaforma e-commerce ha riportato miglioramenti di fatturato (commercetools, 2024). Ma non ogni migrazione porta quei risultati. Guardando indietro a Franke, cinque fattori hanno reso possibile la timeline di 90 giorni.

Gestione dello scope senza compromessi. Non abbiamo migrato tutto. Abbiamo migrato ciò di cui il business aveva bisogno. Quel 35% di personalizzazioni superflue è rimasto indietro. Niente nostalgia. Niente “ma l’abbiamo sempre avuto”.

Workstream paralleli. Piattaforma, dati, integrazioni e frontend procedevano in parallelo con punti di sincronizzazione giornalieri. Nessun handover sequenziale. Quando un team incontrava un blocco, gli altri continuavano ad avanzare.

Investimento anticipato sui dati. Il profiling dei dati è iniziato prima del kickoff. Al giorno 1 sapevamo esattamente cosa stavamo migrando e cosa lasciavamo indietro. Zero sorprese sui dati.

Delivery iterativa con demo settimanali. Gli stakeholder vedevano progressi ogni settimana. I problemi emergevano presto. Le correzioni di rotta avvenivano in giorni, non in mesi.

Team esperto. Il nostro team l’aveva già fatto. Conosceva la piattaforma, i pattern di migrazione, le insidie comuni. Conta più di quanto la gente creda. Prima vista sembra una migrazione come le altre, ma il riconoscimento dei pattern maturato nei progetti precedenti taglia settimane.

SAP ha premiato il progetto con un Quality Award per metodologia, coinvolgimento degli stakeholder e qualità della delivery. Velocità e qualità non sono opposti. Una migrazione mirata e ben pianificata produce entrambe.

Quando dovreste partire?

La guida funziona. Ma l’orologio dei 90 giorni inizia a ticchettare solo quando la preparazione è completata. Se avete davanti la scadenza EoMM di luglio 2026 (SAP Help Portal, 2026), il calcolo è semplice:

30 giorni di preparazione + 90 giorni di migrazione = 120 giorni in totale. Per andare live entro luglio 2026, iniziate la preparazione al più tardi entro marzo 2026. Per andare live comodamente con margine, partite entro gennaio 2026.

Più tardi iniziate, più compressa diventa la timeline. E le timeline compresse costano di più. Funziona così.

Per uno sguardo più ampio su cosa offre SAP Commerce Cloud (prezzi, casi d’uso settoriali, metodologia di implementazione) visitate la nostra pagina della soluzione SAP Commerce Cloud.

Analizzeremo la vostra istanza SAP Hybris, mapperemo le personalizzazioni, profileremo i dati e costruiremo un piano realistico di 90 giorni su misura per la vostra situazione. Contattateci e trasformiamo la vostra scadenza EoMM in un progetto di 90 giorni.

Volete aiuto a tradurre tutto questo in pratica?

Spadoom implementa SAP Commerce Cloud end-to-end: Cloud Edition per enterprise B2B/B2C, ERP Edition per PMI su S/4HANA Public Cloud, e migrazioni da Hybris on-premise. Vedete il caso studio Franke a 90 giorni per un esempio concreto, o prenotate una sessione di scoping.

Domande Frequenti

90 giorni sono realistici per ogni migrazione SAP Commerce?

Onestamente, dipende dalla complessità. Novanta giorni funzionano per piattaforme commerce di medie dimensioni con una fase di preparazione pulita. Deployment più grandi con più storefront, un forte carico di integrazioni o grandi volumi di dati possono richiedere da 4 a 6 mesi. La variabile chiave non è la dimensione della piattaforma. È quanta personalizzazione superflua e quanto debito tecnico esistono. Il nostro audit strutturato identifica tipicamente il 25-35% delle personalizzazioni come eliminabili, il che accorcia direttamente la timeline.

Qual è il rischio più grande in una migrazione di 90 giorni?

La migrazione dati, senza dubbio. L’83% dei progetti di migrazione dati sfora budget o tempistiche (Bloor Group, 2023). Per questo iniziamo il profiling dei dati nella fase di pre-migrazione, prima che parta l’orologio dei 90 giorni. Al giorno 1 dello Sprint 1 conosciamo già volumi, problemi di qualità e requisiti di trasformazione. La prova generale nello Sprint 3 valida l’intera pipeline prima del go-live.

Quante persone richiede una migrazione di 90 giorni?

Il team Franke era snello: 3-4 consulenti Spadoom più 2-3 risorse lato cliente (product owner, business analyst, referente IT). In totale 6-7 persone. Non è questione di dimensione del team. È questione di workstream paralleli con responsabilità chiare e punti di sincronizzazione giornalieri. Un team più grande con handover sequenziali sarebbe in realtà più lento.

Cosa succede alla SEO quando si migra da Hybris a Commerce Cloud?

I cambiamenti nella struttura degli URL richiedono un solido piano di redirect. Lo gestiamo nello Sprint 2: mappare tutti i vecchi URL sui nuovi percorsi, implementare redirect 301, aggiornare dati strutturati e meta tag, inviare la nuova sitemap a Google. Fatto correttamente, il traffico organico si riprende in 2-4 settimane. Composable Storefront offre inoltre Core Web Vitals migliori out of the box, il che spesso migliora i ranking dopo la migrazione.

Possiamo far girare la vecchia piattaforma Hybris e il nuovo Commerce Cloud in parallelo durante la migrazione?

Sì, e lo raccomandiamo. Durante lo Sprint 3 i due sistemi girano simultaneamente. La vecchia piattaforma gestisce il traffico di produzione mentre completiamo UAT e performance testing su Commerce Cloud. La finestra di cutover (cambio DNS) è tipicamente di 4-8 ore, durante le quali eseguiamo la migrazione dati delta. Se qualcosa va storto, il rollback è un ritorno del DNS alla vecchia piattaforma. Pulito e sicuro.