5 errori che le aziende commettono nella migrazione da SAP Commerce on-premise

Abbiamo realizzato progetti SAP Commerce per Franke, ANWR e Distrelec, ognuno con vincoli, tempi e architetture diversi. Le lezioni più utili non sono arrivate da ciò che è andato bene. Sono arrivate dagli errori che abbiamo aiutato i clienti a evitare, o da cui li abbiamo aiutati a uscire quando li avevano già commessi.

Da quando la mainstream maintenance di SAP Commerce on-premise è terminata il 31 luglio 2026 (SAP Help Portal), molte aziende pianificano il passaggio sotto pressione. È proprio in quel momento che si commettono questi cinque errori. Per il quadro delle opzioni (continuare, fare da ponte, migrare o lasciare SAP) partite dalla nostra guida su SAP Commerce on-premise dopo la fine della mainstream maintenance. Questo articolo parla di come fare bene la migrazione.

In sintesi: i cinque errori che rendono lente e costose le migrazioni SAP Commerce sono: copiare 1:1 le personalizzazioni on-premise, sottovalutare la migrazione dei dati, trasferire il debito tecnico invece di eliminarlo, rilasciare tutto in un unico big bang e scambiare la manutenzione specifica per cliente per un piano. Ognuno si evita nella fase di preparazione: verificare le personalizzazioni, analizzare i dati dalla prima settimana, fare pulizia prima, procedere per incrementi e fissare una data.

Errore 1: replicare 1:1 le personalizzazioni on-premise

L’errore singolo più costoso è voler portare tutto con sé senza cambiare nulla.

Le aziende costruiscono per anni funzionalità su misura sulla loro piattaforma on-premise e, quando arriva il momento della migrazione, l’istinto è trasferire tutto. È comprensibile: ogni personalizzazione è nata per un motivo. Ma molte erano workaround per limiti dell’on-premise che SAP Commerce Cloud ha già risolto. Livelli di caching su misura, script di scalabilità manuali e pipeline di deployment artigianali sono gestiti dalla piattaforma.

Ogni riga di codice che trasferite senza necessità allunga la migrazione, aumenta i test e i costi di manutenzione futuri, e rende più difficile ogni aggiornamento successivo (lo stesso effetto che descriviamo nei sette errori di SAP Commerce Cloud che fanno deragliare i progetti).

Cosa fare invece: prima di migrare anche una sola riga di codice, verificate ogni personalizzazione e classificatela: ancora necessaria, sostituibile con una funzione standard oppure obsoleta. Si trasferisce solo il primo gruppo. Nei nostri assessment questa lista è quasi sempre più corta di quanto il cliente si aspettasse, e ogni voce eliminata accorcia il progetto.

Errore 2: sottovalutare la migrazione dei dati

Sulla carta la migrazione dei dati sembra semplice: esportare, trasformare, importare. In pratica è la fase che fa saltare più tabelle di marcia.

I problemi iniziano dalla qualità dei dati. I sistemi on-premise accumulano per anni dati incoerenti: record clienti duplicati, riferimenti a prodotti orfani, ordini con attributi mancanti e strutture di catalogo cresciute senza pulizia. Poi c’è il volume. Una piattaforma B2B di medie dimensioni può contenere molti milioni di righe d’ordine, e trasferirle in modo pulito richiede una progettazione ETL accurata, diversi cicli di prova e una strategia delta per la finestra di passaggio.

Sulle piattaforme in esercizio da molti anni, con una lunga storia commerciale, la sola mappatura dei dati può richiedere settimane. Non è tempo perso: è ciò che impedisce a un problema di qualità dei dati di emergere dopo il go-live.

Cosa fare invece: avviate l’analisi dei dati dalla prima settimana. Verificate la qualità dei dati prima di scrivere qualsiasi script di migrazione e prevedete fin dall’inizio la migrazione delta, perché vi servirà. Pianificate il lavoro sui dati come un filone a sé, con budget e responsabile propri. Chi dice che la migrazione dei dati è “solo esportazione e importazione” non ne ha mai fatta una su larga scala.

Errore 3: migrare il debito tecnico invece di eliminarlo

Un sistema disordinato produce un deployment cloud disordinato. Il debito tecnico non scompare quando si cambia piattaforma: vi segue.

Il debito tecnico che troviamo più spesso nelle installazioni SAP Commerce on-premise:

• Extension inutilizzate. Installate anni fa per una funzione poi abbandonata, ancora caricate, ancora fonte di conflitti di dipendenze.
• Configurazione scritta nel codice. Valori specifici dell’ambiente inseriti nel codice invece che esternalizzati. Funziona on-premise, dove controllate l’infrastruttura, e si rompe nel cloud, dove gli ambienti vengono predisposti per voi.
• Integrazioni obsolete. Collegamenti a sistemi sostituiti o spenti, che continuano a girare e ad aggiungere complessità.
• Dati di test in produzione. Residui di vecchi collaudi che falsano le analisi e creano dipendenze fittizie.

Il tempo dedicato alla pulizia prima dello sviluppo si ripaga durante lo sviluppo, perché il team non insegue dipendenze fantasma.

Cosa fare invece: eseguite un audit del debito tecnico prima di avviare la migrazione. Rimuovete le extension inutilizzate, esternalizzate la configurazione, dismettete le integrazioni morte ed eliminate i dati di test. Trattatelo come un risultato a sé, con una propria approvazione. Il team di migrazione dovrebbe ereditare una codebase pulita, non un museo.

Errore 4: rilasciare tutto in un unico big bang

I grandi programmi tecnologici hanno un bilancio debole: secondo BCG, per oltre due terzi dei programmi tecnologici su larga scala non si prevede una consegna nei tempi, nel budget e nel perimetro pianificati (BCG, 2024). Nelle migrazioni commerce tre fattori giocano contro un unico rilascio big bang:

• I requisiti cambiano durante il progetto. Il business va avanti e SAP rilascia aggiornamenti della piattaforma a migrazione in corso. Ciò che avete specificato nel primo mese può essere superato al quinto.
• Test tardivi trovano problemi tardivi. Un errore di mappatura scoperto nell’ultimo mese significa rilavorare l’intero sviluppo.
• I passaggi big bang concentrano il rischio. Commutare tutti i mercati, gli storefront e le integrazioni in un solo fine settimana significa che un unico guasto colpisce tutto.

Il lancio commerce di Franke in 90 giorni ha funzionato perché è stato consegnato in incrementi paralleli e testati, non con un unico passaggio finale; il playbook dei 90 giorni descrive l’approccio.

Cosa fare invece: suddividete la migrazione in cicli di consegna da due a quattro settimane, ciascuno con un incremento funzionante e testabile. Date la priorità in base al valore di business: prima lo storefront con più traffico, stabilizzatelo, poi estendete. Testate l’integrazione ERP sotto carico realistico da metà progetto, non nell’ultima settimana. Usate i feature flag per controllare il rollout.

Errore 5: scambiare la manutenzione specifica per cliente per un piano

Prima del 31 luglio 2026 questo errore si chiamava “partire troppo tardi”. Oggi ha una forma nuova: poiché la piattaforma continua a funzionare e SAP risolve ancora i problemi noti nell’ambito della manutenzione specifica per cliente, è forte la tentazione di considerare questa fase una comoda sala d’attesa.

Non lo è. La manutenzione specifica per cliente non porta nuovi support package, adeguamenti normativi né aggiornamenti delle librerie, e la soluzione di problemi nuovi può essere a pagamento (SAP Support). Nel frattempo una migrazione affrettata è una migrazione costosa: niente tempo per la pulizia, test compressi, nessun piano di ripiego per il passaggio e tariffe più alte, perché i team SAP Commerce esperti sono già impegnati con chi è partito prima.

Cosa fare invece: fissate una data obiettivo e pianificate a ritroso. Anche una migrazione rapida richiede una fase di preparazione per assessment, pulizia e scelta del partner prima dell’avvio dello sviluppo. Se state ancora scegliendo un partner di implementazione, la nostra panoramica dei partner SAP Commerce Cloud in Svizzera indica cosa verificare. Il resto è nella checklist passo per passo per la migrazione da SAP Hybris.

Cosa accomuna i cinque errori

Tutti gli errori di questa lista hanno la stessa causa: trattare la migrazione come un lavoro di copia tecnica invece che come un’occasione per semplificare. Le aziende che migrano senza intoppi verificano prima di costruire, fanno pulizia prima di traslocare, consegnano per incrementi e fissano una data abbastanza presto da avere ancora delle opzioni.

Un punto in più per chi usa SAP ERP: la maggior parte delle sorprese di una migrazione si trova nel punto di contatto tra commerce ed ERP (prezzi, disponibilità, trasferimento degli ordini), non nello shop. Se anche il passaggio a S/4HANA è nella vostra roadmap, pianificate le due cose insieme; la nostra guida a SAP Commerce Cloud con S/4HANA Public Cloud nel B2B mostra come si combinano.

La nostra offerta completa su SAP Commerce Cloud, dalla pianificazione della migrazione alla realizzazione con Composable Storefront, è sulla pagina della soluzione SAP Commerce Cloud.

---

State pianificando una migrazione SAP Commerce? Conduciamo assessment di migrazione strutturati che individuano le personalizzazioni eliminabili, analizzano la qualità dei dati e stimano tempi realistici. Contattateci.

Domande frequenti

Quanto dura una tipica migrazione a SAP Commerce Cloud?

Le migrazioni tipiche durano da 6 a 12 mesi, i progetti fast-track ben disciplinati da 4 a 6 mesi. All’estremo più rapido, abbiamo portato in produzione la piattaforma SAP Commerce Cloud di Franke in 90 giorni. La variabile principale non è la dimensione della piattaforma, ma quanto debito tecnico e codice personalizzato vi portate dietro; per questo la fase di preparazione è quella che conta di più.

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

SAP Commerce Cloud è la versione di SAP Commerce gestita da SAP nel cloud: SAP si occupa di infrastruttura, scalabilità, deployment e aggiornamenti della piattaforma. SAP Commerce on-premise (ultima release 2205) è uscito dalla mainstream maintenance il 31 luglio 2026 e riceve ormai solo manutenzione specifica per cliente, quindi niente nuovi support package, adeguamenti normativi o aggiornamenti delle librerie.

Quanto costa una migrazione SAP Commerce?

Dipende soprattutto dal numero di personalizzazioni, integrazioni e storefront e dallo stato dei vostri dati: una cifra affidabile richiede quindi un assessment del codice. I risparmi maggiori nascono eliminando personalizzazioni e dati non necessari prima di avviare la migrazione, non negoziando le tariffe di sviluppo.

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

Sì, ed è ciò che raccomandiamo. Migrate prima la piattaforma di base, poi uno storefront o un mercato alla volta, ciascuno testato prima di passare al successivo. I feature flag permettono di controllare il rollout senza un passaggio big bang nel fine settimana.

Cosa dovremmo fare con le personalizzazioni durante la migrazione?

Non date per scontato che ogni personalizzazione vada trasferita. Classificatele come ancora necessarie, sostituibili con una funzione standard oppure obsolete. Molte personalizzazioni on-premise, come caching su misura, script di scalabilità e pipeline di deployment, sono gestite nativamente da SAP Commerce Cloud.