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

Abbiamo migrato piattaforme SAP Commerce per aziende come Franke, ANWR e Distrelec. Ogni 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.

Ecco i cinque errori più comuni che le aziende commettono quando migrano da SAP Commerce on-prem. Ognuno è prevenibile, se sapete cosa tenere d’occhio.

Errore 1: Replicare le personalizzazioni on-prem 1:1 nel cloud

È il singolo errore più costoso. Le aziende investono anni a costruire funzionalità custom sulla piattaforma on-prem. Quando arriva il momento della migrazione, l’istinto è trasferire tutto così com’è su SAP Commerce Cloud.

Il problema? Molte di quelle personalizzazioni erano workaround per limitazioni on-prem che Commerce Cloud ha già risolto. Livelli di cache personalizzati, script di scalabilità manuali, pipeline di deployment su misura — Commerce Cloud gestisce tutto questo nativamente.

Abbiamo visto migrazioni in cui il 30-40% del codice custom era superfluo sulla piattaforma di destinazione. Ogni riga di codice inutile aggiunge tempo alla migrazione, sforzo nei 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 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 della migrazione.

Errore 2: Sottovalutare la complessità della migrazione dati

La migrazione dati sembra semplice sulla carta: export dal sistema sorgente, trasformazione, import nel sistema di destinazione. Nella pratica, è la fase che fa deragliare il maggior numero di timeline.

I problemi iniziano dalla qualità dei dati. I sistemi on-prem accumulano anni di dati inconsistenti — record clienti duplicati, riferimenti prodotto orfani, ordini con attributi mancanti, strutture di catalogo cresciute senza manutenzione.

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 questi 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 legato a Distrelec comprendeva dati di oltre 15 anni di attività commerciale. Il solo data mapping ha richiesto tre settimane — e quell’investimento ci ha protetto da un problema catastrofico di qualità 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 — 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.

Errore 3: Non pulire il debito tecnico prima di migrare

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 che sono stati sostituiti o dismessi. L’integrazione funziona ancora, genera ancora log, aggiunge ancora complessità.
• Dati di test in produzione: Residui da 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.

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 purgare i dati di test. Trattatelo come un deliverable autonomo con la propria timeline e sign-off. Il team di migrazione deve ereditare un codebase pulito, non un museo.

Errore 4: Scegliere un approccio waterfall invece di una delivery iterativa

Il piano classico: 3 mesi per i requisiti, 4 mesi per il build, 2 mesi per il testing, poi un go-live big-bang. Lo abbiamo visto. A scala, fallisce.

Il waterfall fallisce nelle migrazioni commerce per tre ragioni:

1. 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.
2. 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 su tutto il build.
3. I cutover big-bang sono ad alto rischio. Spostare ogni mercato, ogni storefront e ogni integrazione in un singolo weekend crea la massima esposizione. Un errore impatta tutto.

La migrazione di Franke è riuscita in 90 giorni in parte perché abbiamo lavorato in modo iterativo. Prima la piattaforma core, poi gli storefront, poi le integrazioni — ogni fase testata e validata prima di iniziare la successiva.

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. Questo approccio trova i problemi prima, distribuisce il rischio e dà agli stakeholder progressi visibili dalla seconda settimana.

Errore 5: Aspettare troppo e migrare sotto pressione

È 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.

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.
• Tariffe premium per i talenti. Ogni partner di implementazione è al completo. Pagate un sovrapprezzo per la disponibilità.
• Testing compresso. Si prendono scorciatoie. Problemi che avrebbero dovuto emergere nel QA raggiungono la produzione.
• Nessun piano di riserva. Se qualcosa va storto in un cutover affrettato, non c’è margine per il recupero.

Osserviamo che le aziende che partono 12 mesi prima dell’EoMM completano la migrazione per il 30-40% in meno rispetto a quelle che iniziano 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.

Lo schema dietro tutti e cinque gli errori

Ogni errore in questa lista condivide una causa radice: trattare la migrazione come un esercizio tecnico anziché come una trasformazione di business. Le aziende che migrano senza intoppi sono quelle che:

• Fanno audit prima di costruire
• Puliscono prima di traslocare
• Consegnano per incrementi anziché in un big bang
• 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.

Pronti a evitare questi errori?

Se state pianificando una migrazione SAP Commerce, iniziate con un assessment di migrazione. Verificheremo le vostre personalizzazioni, profilieremo i vostri dati, stimeremo la timeline e identificheremo le insidie specifiche del vostro setup.

Contattateci — facciamo in modo che la vostra migrazione stia dalla parte giusta di queste cinque lezioni.