Da Accelerator al Composable Storefront: una guida pratica alla migrazione

Migrare da Accelerator al SAP Composable Storefront non è un upgrade di versione. È un cambio di piattaforma del frontend: da template JSP lato server a un’applicazione Angular headless. Il backend resta, il frontend viene ricostruito. I team che lo pianificano come un upgrade sottovalutano l’impegno, e lo diciamo subito perché è l’errore più frequente che vediamo.

Ora c’è anche una data. SAP ha dichiarato deprecati i template UI Accelerator con la release 2205 e, secondo il piano pubblicato, li rimuove da SAP Commerce Cloud a settembre 2027 (SAP KBA 3263872). Una migrazione di tre-sei mesi che parte nell’autunno 2026 ha margine sufficiente; una che parte nella primavera 2027 no.

In sintesi: passare da Accelerator (JSP) al SAP Composable Storefront (Angular, in precedenza Spartacus) richiede da tre a sei mesi per le implementazioni standard, di più per configurazioni B2B e multi-sito. Backend e API OCC restano; l’intero frontend viene ricostruito. Fate prima l’audit delle personalizzazioni, colmate presto le lacune delle API OCC, configurate il server-side rendering fin dall’inizio e fate funzionare i due storefront in parallelo prima del passaggio. SAP prevede di rimuovere i template Accelerator a settembre 2027.

Perché non basta un «upgrade»?

Sembra che debba essere semplice: stessa piattaforma, nuovo frontend. Non lo è. Accelerator e Composable Storefront differiscono a ogni livello del frontend: JSP lato server contro Angular lato client, chiamate dirette al modello contro API REST OCC, sessioni server contro stato NgRx. Non esiste uno strumento di migrazione automatica, perché a livello di frontend le due architetture non hanno nulla in comune. Le indicazioni di SAP sul passaggio (KBA 3285373) e la documentazione del Composable Storefront descrivono la destinazione; il percorso per arrivarci è lavoro di progetto.

Se il Composable Storefront sia davvero la destinazione giusta, o se un frontend headless proprio sia più adatto, è una decisione a sé. La trattiamo in Vi serve SAP Spartacus? e in Composable Storefront vs React/Next.js.

Come si svolge la migrazione?

Dieci passi. Le prestazioni su mobile ne fanno parte fin dall’inizio, non di un progetto successivo.

Passo 1: audit delle personalizzazioni Accelerator. Censite ogni tag JSP personalizzato, controller, foglio di stile e file JavaScript. È un lavoro poco spettacolare che evita sorprese: in un progetto, questa settimana di audit ha fatto emergere 47 componenti personalizzati che nessuno aveva documentato.

Passo 2: individuare gli equivalenti nel Composable Storefront. La maggior parte dei componenti standard ha una controparte. I componenti personalizzati vanno ricostruiti in Angular.

Passo 3: verificare la copertura delle API OCC. Le funzioni che chiamano direttamente i servizi potrebbero richiedere nuovi endpoint OCC. È ciò che coglie i team di sorpresa più spesso.

Passo 4: predisporre il Composable Storefront. Generare l’applicazione, configurare la connessione al backend e impostare i mapping CMS.

Passo 5: ricostruire i componenti personalizzati. Priorità in base all’impatto sul business: prima le personalizzazioni del checkout e le funzioni B2B.

Passo 6: migrare i contenuti CMS. Rimappare slot di contenuto e componenti dai mapping Accelerator a quelli del Composable Storefront.

Passo 7: configurare il server-side rendering. Impostare l’SSR per i motori di ricerca e le prestazioni. Uno storefront commerce senza SSR è difficile da indicizzare e lento al primo caricamento: non saltate questo passo.

Passo 8: tema e marchio. Applicare il design: override degli stili, tipografia, colori.

Passo 9: test in parallelo. Far funzionare entrambi gli storefront sullo stesso backend e confrontare funzionalità e conversione per due-quattro settimane. Le nostre migrazioni meglio riuscite hanno tutte usato questo funzionamento in parallelo. Costa tempo, ed è lì che emerge ciò che il controllo qualità non vede.

Passo 10: passaggio definitivo. Reindirizzare il traffico, monitorare da vicino per due settimane e tenere Accelerator disponibile come ripiego.

Quali tempi sono realistici?

• B2C standard (10-20 componenti personalizzati): 3-4 mesi
• Molte personalizzazioni (30 o più componenti): 4-6 mesi
• Storefront B2B: 5-7 mesi
• Più siti e più lingue: 6-9 mesi

La variabile principale è il numero di componenti personalizzati, e la maggior parte dei team lo sottovaluta. Prima l’audit, poi il piano. Se il cambio di storefront fa parte di una migrazione più ampia da SAP Commerce on-premise, la nostra checklist di migrazione mostra come si incastrano i filoni di lavoro.

Quali sono gli errori di migrazione più comuni?

Voler replicare Accelerator alla perfezione. Usate la migrazione per semplificare. Un cliente ha preteso la corrispondenza al pixel con il suo storefront Accelerator; dopo tre mesi si è reso conto che metà di quelle scelte di design erano state errori già la prima volta.

Migrare tutto in una volta. Procedete per sezioni: elenco prodotti, poi carrello e checkout, poi B2B. Sulla carta sembra più lento, nella pratica è più veloce, perché i problemi emergono quando il loro impatto è ancora piccolo.

Ignorare le lacune delle API OCC. Le funzioni personalizzate che chiamano direttamente i servizi richiedono lavoro sul backend. Individuatele presto, altrimenti bloccano il team frontend per settimane.

Sottovalutare la curva di apprendimento di Angular. Prevedete da quattro a otto settimane di formazione o inserite sviluppatori Angular nel team. Le competenze JSP non si trasferiscono in questo mondo.

Se cercate un partner per il passaggio, la nostra panoramica dei migliori partner SAP Commerce Cloud in Svizzera elenca i criteri che contano, e la nostra pagina SAP Commerce Cloud mostra come lavoriamo. Parlateci del vostro storefront.

Domande frequenti

Fino a quando possiamo tenere lo storefront Accelerator?

SAP ha dichiarato deprecati i template UI e gli add-on Accelerator con la release 2205. Secondo il piano pubblicato da SAP (KBA 3263872), vengono rimossi da SAP Commerce Cloud a settembre 2027, con un periodo di adozione esteso che termina a settembre 2028. Fino ad allora gli storefront continuano a funzionare, ma senza evoluzioni: pianificate il passaggio adesso.

Possiamo far funzionare entrambi gli storefront contemporaneamente?

Sì. Accelerator e Composable Storefront possono funzionare sullo stesso backend Commerce Cloud. Potete instradare il traffico per URL, dominio o percentuale, migrare una sezione alla volta e confrontare la conversione prima del passaggio definitivo.

Le nostre personalizzazioni Accelerator vengono mantenute?

Il codice frontend no: template JSP, tag, controller e JavaScript vengono ricostruiti come componenti Angular. La logica di business nel backend resta e viene raggiunta tramite le API REST OCC; le funzioni che chiamano i servizi direttamente dallo storefront richiedono nuovi endpoint OCC.

Come proteggiamo la SEO durante la migrazione?

Mantenete le strutture degli URL dove possibile e impostate redirect 301 dove cambiano. Configurate il server-side rendering fin dall’inizio, perché uno storefront Angular solo lato client è difficile da indicizzare. Monitorate con attenzione Google Search Console durante e dopo il passaggio.

Conviene aggiornare Commerce Cloud e migrare lo storefront nello stesso momento?

Meglio di no. Aggiornate prima il backend, verificatene la stabilità e poi migrate lo storefront. Fare entrambe le cose insieme raddoppia il rischio e rende molto difficile capire cosa si è rotto quando qualcosa va storto.