5 errori che le aziende commettono nella migrazione da SAP Commerce On-Prem

Abbiamo migrato piattaforme SAP Commerce per Franke, ANWR e Distrelec. Ogni singolo progetto ci ha insegnato qualcosa. Ma le lezioni più preziose sono venute dagli errori che abbiamo aiutato i clienti a evitare (o da cui li abbiamo aiutati a riprendersi quando ci erano già finiti dentro).

L’83% dei progetti di migrazione dati fallisce o sfora budget e tempistiche (Bloor Group, 2023). Le migrazioni SAP Commerce non fanno eccezione. I cinque errori qui sotto spiegano perché la maggior parte di quei progetti finisce fuori strada.

TL;DR: L’83% delle migrazioni dati sfora il budget (Bloor Group, 2023). Dai nostri progetti SAP Commerce con Franke, ANWR e Distrelec, i cinque errori più comuni sono: replicare le personalizzazioni on-prem 1:1, sottovalutare la migrazione dati, ignorare il debito tecnico, usare una delivery waterfall e partire troppo tardi. Gli approcci agili mostrano tassi di successo del 42% contro il 13% del waterfall (Standish Group, 2020). Partite presto, pulite prima, consegnate in modo iterativo.

Perché le aziende replicano le personalizzazioni on-prem 1:1?

Il 90% delle aziende che hanno migrato la piattaforma e-commerce ha riportato miglioramenti di vendite e fatturato (commercetools, 2024). Ma il singolo errore più costoso è cercare di portarsi dietro tutto senza cambiare nulla.

Le aziende passano anni a costruire funzionalità custom sulla piattaforma on-prem. Quando arriva il momento della migrazione, l’istinto è spostare tutto così com’è. Lo capisco. Tutta quella roba l’avete costruita per un motivo. Ma il punto è questo: molte di quelle personalizzazioni erano workaround per limitazioni on-prem che Commerce Cloud ha già risolto. Livelli di cache custom, script di scaling manuali, pipeline di deployment su misura. Commerce Cloud gestisce tutto questo nativamente.

Abbiamo visto migrazioni in cui dal 30 al 40% del codice custom era superfluo sulla piattaforma di destinazione. Ogni riga di quel codice inutile aggiunge tempo di migrazione, sforzo di test e costi di manutenzione futuri.

Cosa fare invece: prima di migrare una singola riga di codice, fate un audit di ogni personalizzazione. Classificate ciascuna: ancora necessaria, sostituibile con una funzionalità della piattaforma, oppure obsoleta. Eseguiamo un assessment strutturato che tipicamente identifica il 25-35% delle personalizzazioni come eliminabili. Questo riduce direttamente costi e tempi.

Come fa la migrazione dati a far deragliare le timeline?

L’83% dei progetti di migrazione dati fallisce o sfora budget e tempistiche (Bloor Group, 2023). Sulla carta la migrazione dati sembra semplice: export dalla sorgente, trasformazione, import nella destinazione. Nella pratica è la fase che fa deragliare più timeline. L’ho visto succedere più volte di quante riesca a contarne.

I problemi iniziano dalla qualità dei dati. I sistemi on-prem accumulano anni di dati incoerenti. Record clienti duplicati. Riferimenti prodotto orfani. Ordini con attributi mancanti. Strutture di catalogo cresciute senza manutenzione. Uno studio peer-reviewed ha rilevato che il 94% dei fogli di calcolo aziendali contiene errori (Poon et al., Frontiers of Computer Science, 2024). Quel disordine si trasferisce direttamente ai sistemi alimentati da import di fogli di calcolo.

Poi c’è il volume. Una piattaforma commerce B2B di medie dimensioni può avere 50 milioni di righe ordine, 2 milioni di record clienti e 500’000 varianti prodotto. Spostare quei dati in modo pulito richiede un design ETL accurato, molteplici esecuzioni di test e una strategia di migrazione delta per la finestra di cutover.

Un progetto su cui abbiamo lavorato comprendeva dati di oltre 15 anni di attività commerciale. Il solo data mapping ha richiesto tre settimane. Quell’investimento ci ha risparmiato un disastro di qualità dei dati che sarebbe emerso dopo il go-live.

Cosa fare invece: iniziate la data discovery nella prima settimana. Profilate i vostri dati per individuare problemi di qualità prima di scrivere un singolo script di migrazione. Costruite la capacità di migrazione delta fin dall’inizio, perché ne avrete bisogno. E prevedete il 20-25% dello sforzo totale di migrazione per il lavoro sui dati. Se qualcuno vi dice che la migrazione dati è “solo un export/import”, non ne ha mai fatta una su larga scala.

Cosa succede se non pulite prima il debito tecnico?

Il 47% dei leader IT indica il debito tecnico come uno dei principali motivi di spesa eccessiva nell’infrastruttura digitale (IDC, 2024). Migrare un sistema disordinato produce un deployment cloud disordinato. Il debito tecnico non scompare quando cambiate piattaforma. Vi segue.

Il debito tecnico comune che troviamo nei deployment SAP Commerce on-prem:

Extension inutilizzate. Installate anni fa per una funzionalità poi abbandonata. Vengono ancora caricate, consumano ancora risorse, creano ancora conflitti di dipendenze.

Configurazioni hardcoded. Valori specifici dell’ambiente incorporati nel codice invece che esternalizzati. Funzionano on-prem, dove controllate l’infrastruttura. Si rompono nel cloud, dove gli ambienti sono dinamici.

Integrazioni obsolete. Connessioni a sistemi sostituiti o dismessi. L’integrazione gira ancora, genera ancora log, aggiunge ancora complessità senza motivo.

Dati di test in produzione. Residui di cicli di UAT mai ripuliti. Inquinano le analytics e creano dipendenze false.

Una fase del progetto ANWR ha richiesto due settimane di pulizia prima che il vero lavoro di migrazione potesse iniziare. Quell’investimento iniziale ha ridotto la timeline della migrazione di un mese, perché il team non doveva fare debug di dipendenze fantasma durante il build. Due settimane ben spese.

Cosa fare invece: eseguite un audit del debito tecnico 2-3 mesi prima dell’inizio della migrazione. Rimuovete le extension inutilizzate, esternalizzate le configurazioni, dismettete le integrazioni morte e ripulite i dati di test. Trattatelo come un deliverable autonomo con la propria timeline e il proprio sign-off. Il team di migrazione deve ereditare un codebase pulito, non un museo.

Perché la delivery waterfall fallisce nelle migrazioni commerce?

I progetti agili riescono nel 42% dei casi contro il 13% del waterfall (Standish Group CHAOS Report, 2020). Quel divario si allarga nelle migrazioni commerce, dove tre fattori cospirano contro la delivery big-bang.

I requisiti cambiano durante il progetto. Le esigenze di business evolvono. SAP rilascia aggiornamenti della piattaforma a metà migrazione. Ciò che avete specificato al mese uno potrebbe essere obsoleto al mese cinque.

Il testing tardivo trova problemi tardivi. Quando testate tutto alla fine, i problemi si accumulano. Un errore di data mapping scoperto al mese otto richiede rework sull’intero build. Una scoperta costosa.

I cutover big-bang sono ad alto rischio. Passare ogni mercato, ogni storefront e ogni integrazione in un unico weekend crea la massima esposizione. Un solo errore impatta tutto.

La migrazione di Franke è riuscita in 90 giorni anche perché abbiamo consegnato in modo iterativo. Prima la piattaforma core, poi gli storefront, poi le integrazioni. Ogni fase testata e validata prima di iniziare la successiva. Esecuzione pulita.

Cosa fare invece: suddividete la migrazione in cicli di delivery di 2-4 settimane. Ogni ciclo produce un incremento funzionante e testabile. Prioritizzate per valore di business: migrate prima lo storefront con più traffico, stabilizzatelo, poi espandete. Usate feature flag per controllare il rollout.

Qual è il vero costo di partire troppo tardi?

È il meta-errore. E il più comune.

Le aziende conoscono la scadenza EoMM. La discutono nei comitati direttivi. La inseriscono nei registri dei rischi. E poi non agiscono finché non è troppo tardi per una timeline confortevole. L’ho visto succedere ancora e ancora.

Una migrazione affrettata è una migrazione costosa. Ecco cosa succede quando si parte troppo tardi.

Niente tempo per la pulizia. Migrate il disordine così com’è, poi passate mesi a correggerlo nel cloud. Niente tempo per una pianificazione adeguata. Tariffe premium per i talenti, perché ogni partner di implementazione è al completo. Testing compresso, dove si tagliano gli angoli e problemi che il QA avrebbe dovuto intercettare raggiungono la produzione. Nessun piano di riserva se qualcosa va storto durante il cutover.

Vediamo aziende che partono 12 mesi prima dell’EoMM completare la migrazione spendendo dal 30 al 40% in meno rispetto a chi inizia con 4 mesi di anticipo. Il lavoro è lo stesso. La differenza di costo dipende interamente da ritmo, pianificazione e disponibilità delle persone giuste.

Cosa fare invece: partite ora. Non il prossimo trimestre. Ora. Anche se la migrazione in sé richiede solo 90 giorni, come per Franke, serve tempo per assessment, pulizia, selezione del partner e allineamento del team. Una migrazione di 90 giorni richiede una fase preparatoria di 30-60 giorni. Includetela nella vostra pianificazione.

Quale schema collega tutti e cinque gli errori?

Ogni errore di questa lista condivide una causa radice: trattare la migrazione come un esercizio tecnico anziché come una trasformazione di business. Il 90% delle aziende che hanno migrato la piattaforma ha riportato miglioramenti di fatturato (commercetools, 2024). Ma solo quando hanno affrontato il passaggio in modo strategico.

Le aziende che migrano senza intoppi sono quelle che fanno audit prima di costruire, puliscono prima di traslocare, consegnano per incrementi e partono abbastanza presto da avere alternative.

Abbiamo realizzato migrazioni SAP Commerce per ANWR, Franke, Distrelec e altri. Ognuna con vincoli, tempistiche e architetture diverse. Il filo conduttore dei progetti riusciti è la disciplina nella preparazione. Prima vista sembra ovvio. Ma quel dato dell’83% di fallimenti vi dice che non lo è.

Per un quadro completo delle nostre competenze su SAP Commerce Cloud, dalla pianificazione della migrazione alla delivery del Composable Storefront, visitate la nostra pagina della soluzione SAP Commerce Cloud.

State pianificando una migrazione SAP Commerce? Eseguiamo assessment di migrazione strutturati che identificano le personalizzazioni eliminabili, profilano la qualità dei dati e stimano timeline realistiche. Contattateci.

Domande Frequenti

Quanto dura una tipica migrazione a SAP Commerce Cloud?

Dipende dalla complessità. La nostra più rapida (Franke) si è conclusa in 90 giorni. La maggior parte delle piattaforme B2B di medie dimensioni richiede da 4 a 6 mesi, preparazione inclusa. La variabile più grande non è la dimensione della piattaforma. È quanto debito tecnico e codice custom esistono. Le aziende che eseguono prima una fase di pulizia tagliano tipicamente il 20-30% dalla timeline di build.

Qual è la differenza tra SAP Commerce on-prem e SAP Commerce Cloud?

SAP Commerce Cloud è la versione gestita e hosted nel cloud di SAP Commerce. Gestisce automaticamente infrastruttura, scaling, deployment e patch di sicurezza. L’on-prem vi dà pieno controllo ma vi obbliga a gestire tutto questo da soli. Con l’avvicinarsi dell’End of Mainstream Maintenance (EoMM) di SAP, i clienti on-prem devono pianificare il passaggio a Commerce Cloud o a una piattaforma alternativa.

Quanto costa una migrazione SAP Commerce?

I costi variano molto in base al volume di personalizzazioni, alla complessità dei dati e al numero di integrazioni. Un benchmark utile: prevedete il 20-25% dello sforzo totale per la sola migrazione dati. Le aziende che partono presto (12+ mesi prima della scadenza) spendono tipicamente dal 30 al 40% in meno di quelle che corrono. L’assessment di migrazione è il miglior primo passo. Produce una stima dei costi realistica basata sul vostro codebase reale.

Possiamo migrare SAP Commerce per fasi invece che tutto in una volta?

Sì, e lo raccomandiamo con forza. Migrare uno storefront o un mercato alla volta riduce il rischio e fa emergere i problemi prima. Gli approcci agili hanno un tasso di successo del 42% contro il 13% del waterfall (Standish Group, 2020). I feature flag vi permettono di controllare il rollout senza cutover big-bang.

Cosa dovremmo fare con le personalizzazioni durante la migrazione?

Non date per scontato che ogni personalizzazione debba essere trasferita. Nella nostra esperienza, il 25-35% delle personalizzazioni on-prem è superfluo su SAP Commerce Cloud, perché la piattaforma le gestisce nativamente. Prima di migrare il codice, eseguite un assessment strutturato: classificate ogni personalizzazione come ancora necessaria, sostituibile con una funzionalità della piattaforma, oppure obsoleta. Questo singolo passo ha l’impatto più grande nella riduzione di costi e tempi della migrazione.