Migrazione da SAP C4C a Sales & Service Cloud V2: perché la strategia conta più della velocità

C4C è stato solido per quello che era. Funziona ancora e SAP continua a mantenerlo. Ma le nuove funzionalità CRM di SAP, tra cui Joule e i nuovi agenti di IA, nascono per Sales Cloud V2 e Service Cloud V2. Il divario tra ciò che C4C sa fare e ciò che offre V2 cresce a ogni release.

Poiché SAP non ha fissato una data di fine per C4C, potete scegliere voi il momento. Per questo il come conta più del quando.

In sintesi: passare da C4C a V2 è una reimplementazione, non un aggiornamento: cambiano modello dati, API e framework di estensione. La nostra strategia in cinque fasi (analisi, riprogettazione delle integrazioni, sviluppo in parallelo, migrazione dei dati, adozione) richiede 6-10 mesi per un’organizzazione di vendite e service di medie dimensioni. Partite da un inventario completo del vostro sistema C4C e da un calendario realistico. A settembre 2026 SAP non ha annunciato una data di fine manutenzione per C4C: non c’è motivo di affrettarsi.

Perché V2 non è un semplice aggiornamento?

È il punto più importante da capire. SAP ha costruito V2 da zero su SAP BTP. Quasi nulla si trasferisce così com’è:

• Modello dati: diverso. Campi personalizzati, oggetti di business ed estensioni non si trasferiscono automaticamente.
• API: diverse. Ogni integrazione basata sui servizi OData di C4C va ricostruita sulle API di V2.
• Interfaccia: diversa. È nuova, basata sui ruoli e segue il design SAP Fiori.
• Estendibilità: diversa. C4C usava strumenti key user e il PDI/SDK. V2 usa i servizi di SAP BTP. Più flessibilità, ma competenze diverse.

Le aziende che trattano V2 come un cambio di versione incontrano presto problemi. Per un confronto funzione per funzione leggete SAP Sales Cloud V2 vs. C4C: cosa è davvero cambiato e, per i team di service, Service Cloud V2: cosa è cambiato.

Perché la strategia conta più della velocità?

Quando il futuro di una piattaforma sembra incerto, l’istinto è affrettarsi. Una migrazione frettolosa porta:

• Integrazioni interrotte che nessuno aveva mappato prima del passaggio
• Logica di business persa, nascosta in codice C4C non documentato
• Utenti frustrati, perché la nuova interfaccia non assomiglia per nulla alla vecchia
• Sforamenti di budget, perché rifare costa più che pianificare

L’approccio giusto parte da un inventario completo. Ogni campo personalizzato, regola di workflow, integrazione e report viene censito e valutato. Non tutto appartiene a V2. Alcune cose erano soluzioni di ripiego che V2 gestisce nello standard. Altre sono obsolete. Quelle che contano meritano una ricostruzione pulita, non un trasferimento frettoloso.

Come si presenta una migrazione solida?

Per il passaggio da V1 a V2 SAP mette a disposizione un Readiness Check Tool (RCT) e un Data Transfer Tool (DTT), entrambi ampliati con le release 2508 e 2511 (panoramica della release). Gli strumenti aiutano, ma non sostituiscono una strategia. Ecco le cinque fasi che seguiamo.

Fase 1: analisi e scoperta (2-4 settimane)

Censite tutto nell’ambiente C4C: configurazione, oggetti personalizzati, integrazioni, report, ruoli utente e automazioni di workflow. Classificate ogni elemento come:

• Migrare: necessario in V2, da ricostruire nel nuovo modello
• Riprogettare: necessario, ma V2 lo gestisce nativamente (ad esempio le regole di instradamento diventano instradamento per competenze)
• Sostituire: esiste un’alternativa migliore in V2 o su BTP
• Dismettere: non più necessario, o sempre stato solo un ripiego

Questa fase previene la causa di ritardo più frequente: personalizzazioni non documentate scoperte a metà migrazione. Se nessuno ricorda perché esiste una regola di workflow, il team passa giorni a indagare invece di costruire. Per un primo passo a prezzo fisso, il nostro assessment di readiness per la migrazione da V1 a V2 verifica il vostro panorama in 3 giorni per CHF 7’500, scalati dall’implementazione V2.

Fase 2: riprogettazione delle integrazioni (4-6 settimane)

La maggior parte delle integrazioni C4C va ricostruita, ed è anche un’occasione per semplificare. SAP fornisce contenuti di integrazione standard tra V2 e S/4HANA, e SAP Integration Suite copre la maggior parte degli altri scenari: serve meno codice di collegamento su misura.

Mappate ogni punto di integrazione, verificate se V2 offre un’alternativa standard e sostituite le interfacce punto a punto con un’integrazione basata su eventi, dove V2 pubblica gli eventi necessari. Definite l’architettura di destinazione prima di scrivere una riga di codice. Se S/4HANA fa parte del vostro panorama, la nostra guida su come S/4HANA Public Cloud e Sales Cloud V2 funzionano come stack integrato spiega i dati anagrafici condivisi, il processo quote-to-cash e cosa conservare della vostra integrazione C4C.

Fase 3: sviluppo in parallelo (8-12 settimane)

Costruite V2 mentre C4C resta in produzione. Nessun passaggio big bang. Così potete testare a fondo, validare le esecuzioni di migrazione e formare gli utenti prima del go-live.

Aree di configurazione principali per i team di service:

• Stati e transizioni del ciclo di vita dei casi
• Regole di instradamento per competenze e profili di competenza degli agenti
• Classificazione dei casi basata sull’IA, se licenziata (caricate presto i casi storici)
• Migrazione e riorganizzazione della knowledge base
• Definizioni SLA e regole di escalation

Fase 4: migrazione dei dati (4-6 settimane)

Clienti, contatti, opportunità, casi e attività passano a V2 con gli strumenti di migrazione di SAP. Definite le regole di mappatura, eseguite più migrazioni di prova con volumi paragonabili alla produzione e fissate una finestra di passaggio chiara. La nostra guida passo per passo al DTT spiega lo strumento.

Se intendete usare la classificazione dei casi basata sull’IA, importate presto i casi storici. Il modello impara da casi reali, non da dati di prova artificiali.

Fase 5: gestione del cambiamento e formazione (2-4 settimane)

Il cambio di interfaccia giustifica da solo una formazione dedicata, ma non basta: workflow, instradamento, visibilità degli SLA e funzioni di IA funzionano diversamente in V2. Coinvolgete i key user nei test di accettazione, formate con esercizi pratici invece che con slide e prevedete 2-4 settimane di stabilizzazione dopo il go-live.

Cosa ci insegna il lavoro di migrazione?

Gli stessi schemi si ripresentano ogni volta che pianifichiamo o verifichiamo un passaggio da C4C a V2.

Documentate tutto in C4C prima di iniziare. I ritardi maggiori nascono da personalizzazioni non documentate scoperte a metà migrazione.

Non migrate il debito tecnico. Se una soluzione di ripiego in C4C era sempre stata scomoda, non ricostruitela in V2. V2 risolve nello standard molti vecchi problemi: gerarchie di casi, instradamento per competenze, automazione degli SLA. Usate la migrazione per fare ordine.

Prevedete tempo abbondante per le integrazioni. Ogni endpoint API di C4C cambia in V2. Dieci integrazioni significano dieci ricostruzioni, e il budget deve rifletterlo.

Investite presto nell’adozione. Il sistema migliore fallisce se le persone lo rifiutano. Avviate la gestione del cambiamento dal primo giorno. Per i team di service si tratta di nuove competenze sull’agent desktop, non solo di nuove schermate.

Testate con dati reali. I dati di prova artificiali nascondono i problemi. Eseguite migrazioni di prova con volumi paragonabili alla produzione per trovare gli errori prima del go-live.

Perché la scelta del partner è decisiva?

Una migrazione da C4C a V2 non è un progetto standard. Un partner che conosce solo V2 non vede le particolarità del vostro sistema C4C. Un partner che conosce solo C4C non sa progettare bene lo stato di destinazione in V2. Serve un team che capisca entrambi, il sistema che lasciate e quello verso cui andate, e, se V2 deve dialogare con il vostro ERP, anche S/4HANA.

Cosa cercare:

• Esperienza pratica con C4C: vecchio modello dati, particolarità delle API e modelli di estensione
• Progetti V2 realizzati: ambienti V2 in produzione, non solo corsi SAP
• Competenze di integrazione tra S/4HANA, SAP BTP e sistemi di terze parti
• Un metodo ripetibile invece dell’improvvisazione
• Gestione del cambiamento, non solo realizzazione tecnica

In Spadoom lo stesso team segue Sales e Service Cloud V2, le estensioni BTP e il lato S/4HANA dell’integrazione. Per valutare i partner in generale leggete come scegliere un partner di implementazione SAP CX e la nostra panoramica delle società di consulenza SAP CX in Svizzera.

Perché non aspettare un altro trimestre?

Aspettare è un’opzione legittima, perché per C4C non è stata annunciata una data di fine. Ma ha un costo:

• V2 continua ad acquisire funzionalità (classificazione dei casi con IA, Joule, agenti Joule) che C4C non riceverà.
• SAP Jam Collaboration, parte del pacchetto V1, non sarà più accessibile dal 1° gennaio 2027 (panoramica della release). Chi lo usa ha comunque bisogno di un’alternativa.
• Il debito tecnico in C4C continua a crescere, e con esso la migrazione futura.

Affrettarsi resta peggio che aspettare. Una strategia chiara, un’analisi approfondita e un calendario realistico trasformano la migrazione da rischio in miglioramento. Verificate le funzioni da cui dipendete nel SAP Roadmap Explorer e nella documentazione di Service Cloud V2, e usate il nostro confronto V1-V2 per dimensionare il passaggio.

Per una guida dettagliata dedicata ai team di service leggete la nostra guida alla migrazione a Service Cloud V2. Se desiderate un secondo parere sul vostro piano, parlate con il nostro team.

Domande frequenti

Quanto dura una migrazione da C4C a V2?

Per una migrazione congiunta di vendite e service con 50-200 utenti, pianificate 6-10 mesi in cinque fasi. Gli ambienti più piccoli possono concludersi in 4-6 mesi; i sistemi molto personalizzati richiedono 10-14 mesi. La fase che più spesso sfora è la ricostruzione delle integrazioni: pianificate con margine.

Possiamo far funzionare C4C e V2 in parallelo?

Sì, ed è consigliabile. Costruire V2 mentre C4C resta in produzione permette di testare, validare la migrazione dei dati e formare gli utenti prima del passaggio. Prevedete almeno 8-12 settimane di sovrapposizione durante la fase di sviluppo.

Cosa succede alle nostre integrazioni C4C?

Ognuna va verificata e la maggior parte va ricostruita, perché endpoint API e modello dati di V2 sono diversi. I contenuti di integrazione standard di SAP per S/4HANA e SAP Integration Suite rendono spesso le nuove integrazioni più semplici delle originali, soprattutto se sostituite le interfacce punto a punto con quelle basate su eventi.

Servono nuove competenze per V2?

Sì. Le estensioni V2 girano su SAP BTP con CAP, Node.js o Java invece del PDI/SDK di C4C. Se il vostro team non ha esperienza con BTP, prevedete formazione o lavorate con un partner che ha già realizzato estensioni V2.

Esiste una data ufficiale di fine vita per C4C?

No. A settembre 2026 SAP non ha annunciato una data di fine manutenzione per C4C, e V1 riceve ancora release regolari. Le novità come gli agenti Joule arrivano in V2, e SAP Jam Collaboration, parte del pacchetto V1, non sarà più accessibile dal 1° gennaio 2027. Pianificate il passaggio secondo i vostri tempi, non sotto la pressione di una scadenza.