SAP Sales Cloud V2 Data Transfer Tool: la guida alla migrazione passo dopo passo

Il Data Transfer Tool (DTT) di SAP trasferisce dati aziendali e configurazione da SAP Cloud for Customer (C4C, “V1”) a SAP Sales Cloud e Service Cloud Version 2. È uno strumento di SAP, supportato da SAP, e migliora quasi a ogni rilascio trimestrale. Quello che la documentazione non può darvi è il progetto che gli sta intorno: l’ordine dei lavori, la preparazione, i cicli di test e le decisioni che nessuno può prendere al posto vostro.

Questa guida descrive quel progetto. Segue la sequenza che usiamo nei progetti da V1 a V2: Readiness Check, pulizia, preparazione di V2, trasferimenti di prova, passaggio in produzione e convalida. Dove un’affermazione descrive lo strumento di SAP, rimanda alla documentazione SAP. Dove descrive la nostra pianificazione, lo dice.

In sintesi: il DTT viene eseguito nel tenant V1 (work center Transition) e SAP lo attiva su richiesta. Eseguite prima il Readiness Check, pulite V1 (il DTT non filtra i record) e preparate un tenant V2 vuoto con la configurazione richiesta da ciascun oggetto. Poi almeno due trasferimenti di prova completi, il cutover in una finestra di congelamento pianificata e la modalità delta per colmare la differenza. Il DTT gestisce i dati; logica personalizzata, integrazioni, estensioni dell’interfaccia e report vanno ricostruiti in V2. Nella nostra pianificazione, il filone dati di un tenant di medie dimensioni richiede in genere da 8 a 14 settimane.

Che cos’è il Data Transfer Tool (DTT)?

Il DTT è la parte di trasferimento degli strumenti che SAP mette a disposizione per il passaggio da V1 a V2. L’altra parte è il Readiness Check Tool (RCT), che analizza il tenant V1 prima che venga spostato qualsiasi dato. Entrambi si trovano nel work center Transition del sistema V1 (SAP Help: Data Transfer Tool; SAP Help: Readiness Check Tool).

Il DTT trasferisce i dati oggetto per oggetto. Per ogni oggetto supportato SAP fornisce un modello con mappatura dei campi, logica di trasformazione e convalida del caricamento. Lo strumento gestisce anche la sequenza tra oggetti dipendenti e produce log e messaggi di errore utilizzabili.

L’ambito è cresciuto in modo costante. Alcune novità annunciate da SAP nei briefing di rilascio:

• 2508 (agosto 2025): trasferimento di prova con “Data Only” come impostazione predefinita, una Transfer History per il monitoraggio, nuovi oggetti come Territories e Competitor Products e supporto per note, ID esterni dei gruppi di prodotti e ulteriori campi di estensione.
• 2511 (novembre 2025): il caricamento della configurazione aziendale si può separare dal trasferimento dei dati, nuovi controlli dei prerequisiti (ad esempio i servizi inclusi nello scope di V2) e messaggi di errore più dettagliati (SAP Community: briefing del rilascio 2511).
• 2602 (febbraio 2026): visite, pianificazione dei percorsi e gerarchia dei clienti come oggetti trasferibili; il trasferimento dei dati dei campi PDI passa da beta a disponibilità generale (SAP Community: pre-release briefing 2602).
• 2605 (maggio 2026): un riepilogo dei conteggi per le strutture organizzative, il trasferimento dei campi di estensione key user sulle relazioni tra partner commerciali e le mappature delle liste di codici all’interno di “Transfer All BC” (SAP Community: pre-release briefing 2605).

Poiché l’elenco cambia ogni trimestre, verificate l’elenco degli oggetti sulla pagina di aiuto SAP all’inizio del progetto, non su un articolo di blog (questo compreso).

Cosa copre di solito il DTT: clienti, contatti, clienti privati, lead, opportunità, attività (appuntamenti, compiti, telefonate), ticket, prodotti e relativi dati anagrafici, territori, strutture organizzative, note e allegati, e i campi di estensione quando la mappatura è completa.

Cosa non copre il DTT:

• Logica personalizzata creata con l’SDK di V1 (script PDI/ABSL, oggetti di business personalizzati con un proprio comportamento)
• Regole di workflow e notifiche
• Scenari di integrazione con ERP e sistemi terzi
• Adattamenti dell’interfaccia e mashup
• Report e dashboard
• Impostazioni personali e modelli di e-mail

Questa divisione definisce il progetto. Il DTT sposta i dati. Tutto il resto viene ricostruito nell’architettura di V2. Per il lato strategico di questa scelta leggete il nostro articolo sulla strategia di migrazione da C4C a V2 e la nostra valutazione degli attuali limiti di V2. 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.

Prerequisiti prima di iniziare

Accesso e tenant

• Richiedete il DTT a SAP. SAP attiva lo strumento per ogni cliente. Aprite un caso sulla componente LOD-LE-MIG-CNS indicando l’URL del vostro tenant V2.
• Assegnate il work center Transition. In V1 aggiungete il work center Transition al ruolo aziendale degli amministratori che eseguiranno il Readiness Check e il trasferimento.
• Predisponete per tempo il tenant V2. Secondo SAP, il tenant V2 di destinazione deve essere vuoto, senza dati aziendali. Non lasciate che qualcuno “faccia delle prove” nel tenant che caricherete. Per i prototipi usate un tenant separato.
• Verificate i prerequisiti di ogni oggetto. Alcune configurazioni devono esistere in V2 prima del trasferimento, ad esempio i tipi di caso per i ticket. SAP li documenta oggetto per oggetto: leggete queste pagine in fase di pianificazione, non durante la prima prova.

Eseguite prima il Readiness Check

Il Readiness Check Tool analizza il tenant V1 e mostra quali oggetti standard utilizzate, i volumi di dati per oggetto, i campi personalizzati, le soluzioni PDI, i mashup e i componenti incorporati, e gli elementi che SAP classifica come ostacoli alla transizione. I rilasci più recenti hanno aggiunto il volume degli allegati per oggetto e l’elenco degli add-on installati.

Per noi ogni progetto da V1 a V2 inizia con il Readiness Check. È la prima risposta concreta alla domanda: quanta parte del nostro sistema si sposta automaticamente e quanta dobbiamo ricostruire?

Pulite V1 prima del trasferimento

Il DTT non permette di scegliere un sottoinsieme di record per oggetto. Ciò che si trova in V1 viene trasferito. La pulizia va quindi fatta in V1:

• Duplicati. Unite in V1 i clienti e i contatti doppi. V2 dispone di un controllo dei duplicati configurabile, ma è pensato per i nuovi record, non per sistemare migliaia di record migrati.
• Record orfani. Contatti senza cliente, attività senza record padre, opportunità collegate a prodotti dismessi. Correggeteli o archiviateli.
• Campi personalizzati obsoleti. Un campo che nessuno compila da due anni non ha bisogno di un campo di estensione in V2. Ogni campo nell’ambito richiede una mappatura e un test.
• Utenti usciti dall’azienda. Riassegnate i record dei collaboratori che hanno lasciato l’azienda prima del trasferimento, non dopo.

È anche il momento di stabilire che cosa significhi “dati buoni” per il vostro sistema V2. Il nostro articolo sulla qualità dei dati CRM come base per l’IA descrive le regole che applichiamo.

Passo 1: leggere correttamente il Readiness Check

Aprite il Readiness Check nel work center Transition di V1 ed eseguitelo sul tenant di produzione. Poi esaminate i risultati per categoria:

Oggetti standard e volumi. Quali oggetti sono in uso e quanti record contiene ciascuno. Il volume determina la durata delle esecuzioni di prova e di produzione.

Estensioni specifiche del cliente. Campi personalizzati, soluzioni PDI, mashup e componenti incorporati. Questo elenco è il backlog dei filoni di ricostruzione: alcune voci diventano campi di estensione in V2, altre estensioni side-by-side su SAP Business AI Platform (BAIP, ex BTP), altre vengono eliminate.

Ostacoli alla transizione. Elementi che impediscono un trasferimento automatico. Ognuno ha bisogno di un responsabile e di una decisione.

Trasformate il risultato in un piano di migrazione: ogni oggetto nell’ambito, i suoi prerequisiti in V2, lo stato della mappatura e chi approva il risultato. Questo documento è il vostro piano per le settimane successive.

Passo 2: preparare il tenant V2

Il DTT trasferisce record. Non progetta il vostro sistema V2.

Organizzazione e utenti

• Struttura organizzativa. Organizzazioni di vendita e di servizio, unità e territori. V2 ha un modello proprio: trattatelo come una fase di progettazione, non come una copia.
• Utenti e ruoli. Create utenti e ruoli aziendali in V2, in modo che la responsabilità dei record possa essere assegnata durante il trasferimento.
• Configurazione aziendale. Cicli e fasi di vendita, codici di stato e di motivazione, categorie di prodotto e le altre impostazioni a cui fanno riferimento i dati trasferiti. Dal rilascio 2511 configurazione e dati si possono caricare separatamente, il che rende più semplice chiudere prima la configurazione.

Campi di estensione e liste di codici

I campi personalizzati di V1 hanno bisogno di una destinazione in V2, dove vengono creati come campi di estensione tramite l’estensibilità key user. Per ogni campo nell’ambito:

1. Create il campo di estensione in V2 con un tipo di dato corrispondente
2. Per i campi con lista di codici, verificate che ogni valore usato in V1 esista in V2 o sia mappato
3. Registrate il campo V1 e la destinazione V2 nel documento di mappatura
4. Testatelo nel primo trasferimento

Le mappature incomplete sono la causa più frequente di record respinti nei test. Campi di estensione, note e allegati vengono trasferiti solo se la mappatura dell’oggetto di business è completa.

Per una panoramica di ciò che V2 offre di serie, consultate la nostra pagina su SAP Sales Cloud V2.

Passo 3: configurare il trasferimento

Nel work center Transition il DTT elenca gli oggetti trasferibili. Iniziate dai dati anagrafici, poi passate ai dati transazionali. Il DTT gestisce da sé la sequenza tra oggetti dipendenti, ma per leggere i log dovete conoscere le dipendenze:

1. Struttura organizzativa, territori, prodotti
2. Clienti e clienti privati
3. Contatti e relazioni
4. Lead
5. Opportunità
6. Attività (appuntamenti, compiti, telefonate, visite)
7. Ticket

Se le opportunità falliscono, la causa si trova spesso un livello più in alto: un cliente non trasferito, un prodotto che in V2 non esiste o un valore mancante in una lista di codici.

Controllate i modelli di mappatura forniti oggetto per oggetto. I campi standard li ha mappati SAP. Il vostro compito è la parte specifica: campi di estensione, valori delle liste di codici e i campi il cui significato è cambiato negli anni di utilizzo di V1. Un campo “Categoria” può significare tre cose diverse in tre unità di vendita.

Passo 4: eseguire i trasferimenti di prova

Non eseguite mai il trasferimento in produzione senza almeno una, meglio due, prove complete.

Come eseguire le prove

1. Usate un tenant V2 di test vuoto e preparato esattamente come quello di produzione. Non fate mai prove nel tenant con cui andrete in produzione.
2. Trasferite l’intero ambito. Tutti gli oggetti, tutti i campi di estensione. Una prova parziale non mostra i problemi nei riferimenti tra oggetti.
3. Usate volumi di produzione. Un piccolo campione nasconde i problemi che emergono solo su larga scala: tempi di esecuzione lunghi, allegati pesanti, valori rari nelle liste di codici.
4. Misurate i tempi per oggetto. Questi dati definiscono la finestra di cutover.

Cosa verificare dopo ogni esecuzione

Conteggi. Confrontate il numero di record per oggetto in V1 e in V2. Transfer History e riepiloghi dei conteggi aiutano; per gli oggetti importanti contate anche in modo indipendente.

Oggetto	V1	V2	Differenza	Azione
Clienti	12’450	12’450	0	OK
Contatti	34’200	34’187	-13	Verificare il log
Opportunità	8’930	8’930	0	OK
Attività	156’000	155’842	-158	Verificare il log

Esempio illustrativo, non dati di clienti.

Relazioni. Controllate a campione da 50 a 100 record tra i vari oggetti: i contatti sono collegati ai clienti giusti, le opportunità mostrano i prodotti e le fasi corretti, le attività sono associate al record padre giusto, i valori dei campi di estensione sono arrivati?

Log degli errori. Classificate ogni errore: bloccante, perdita di dati o estetico. Gli errori bloccanti e le perdite di dati si risolvono prima dell’esecuzione successiva.

Categorie di errore tipiche

Categoria	Causa tipica	Cosa fare
Riferimento mancante	Un record padre (cliente, prodotto) non è stato trasferito o non esiste in V2	Correggere prima l’oggetto padre, poi ritrasferire l’oggetto dipendente
Valore di lista sconosciuto	Un valore di V1 non ha corrispondenza in V2	Aggiungere il valore in V2 o mapparlo su uno esistente
Campo obbligatorio vuoto	V2 richiede un valore che in V1 non è mai esistito	Impostare un valore predefinito nella mappatura o compilare il campo in V1 prima del trasferimento
Campo di estensione non trasferito	Mappatura dell’oggetto di business incompleta	Completare la mappatura e ritrasferire l’oggetto
Configurazione V2 mancante	Prerequisito non creato (ad esempio i tipi di caso)	Creare la configurazione in V2; i controlli dei prerequisiti introdotti con il 2511 ne segnalano molti
Duplicati	V1 contiene più volte lo stesso cliente	Unirli in V1 prima dell’esecuzione successiva
Allegati pesanti	I file superano i limiti di dimensione o rallentano l’esecuzione	Verificare i volumi degli allegati nel Readiness Check; archiviare o trasferire a parte i file molto grandi

I messaggi esatti si trovano nel log del DTT; dal 2511 SAP indica il tipo di errore in modo più dettagliato. Prevedete da due a tre cicli di prova. Ogni ciclo dovrebbe produrre meno errori. Se i numeri non scendono, c’è un problema di fondo: di solito nella mappatura o nella qualità dei dati in V1.

Passo 5: eseguire il trasferimento in produzione

A questo punto il processo non dovrebbe riservare sorprese. L’esecuzione in produzione ripete ciò che le prove hanno dimostrato.

Tempistica

Scegliete una finestra tranquilla. Il trasferimento carica entrambi i sistemi. Per le aziende in Svizzera e in Germania la scelta abituale è il fine settimana.

Congelate V1. Annunciate con almeno una settimana di anticipo uno stop alle modifiche in V1. Ciò che viene modificato in V1 dopo lo snapshot deve arrivare tramite la modalità delta, altrimenti va perso.

Pianificate la durata con un margine. Prendete il tempo dell’ultima prova e aggiungete dal 20 al 30 per cento. I volumi di produzione sono maggiori e i sistemi lavorano con un carico diverso.

Monitorare l’esecuzione

Incaricate una persona di seguire il trasferimento senza interruzioni, tramite la Transfer History e i log. Se un oggetto mostra un numero insolito di errori, fermatevi e indagate. Un problema scoperto a metà esecuzione costa meno di un trasferimento completato ma difettoso.

Checkpoint per i tenant di grandi dimensioni

Per i tenant con più di un milione di record, suddividete l’esecuzione in fasi e convalidate dopo ciascuna:

1. Dati anagrafici: struttura organizzativa, prodotti, clienti, contatti
2. Documenti di vendita: lead e opportunità
3. Attività e ticket: i volumi maggiori
4. Allegati: la parte più lenta

Pianificare il ripiego

Il DTT legge da V1 e non modifica l’origine. Se il trasferimento in produzione non riesce, V1 è intatto e gli utenti continuano a lavorarci. Poiché V2 deve essere vuoto prima del trasferimento, ripartire significa ripulire il tenant V2. Concordate in anticipo con SAP come funzionerebbe un ripristino e includete quel tempo nel piano. Mantenete V1 disponibile finché V2 non è stato convalidato e approvato.

Passo 6: convalidare dopo il cutover

Conteggi e delta

Ripetete il confronto dei conteggi sui dati di produzione. Ogni nuova differenza indica record creati o modificati tra l’ultima prova e il congelamento. Per questi oggetti eseguite il trasferimento delta.

Relazioni di business

• Le gerarchie dei clienti sono complete
• I contatti sono assegnati ai clienti giusti
• Pipeline: fasi, valori attesi, date di chiusura e prodotti sono corretti
• La cronologia delle attività compare nell’ordine giusto sul record giusto
• I campi di estensione riportano i valori corretti (controllate a campione almeno 100 record per ogni campo importante)

Accettazione da parte delle funzioni aziendali

Prima di dichiarare il successo, fate verificare agli utenti i propri dati:

• Direzione vendite: vista pipeline, numero e valore delle opportunità
• Account manager: i loro dieci clienti più importanti
• Operatori del servizio: ticket recenti e storico del cliente
• Amministratori: territori, ruoli e assegnazioni
• Reporting: indicatori a confronto con V1

Prevedete da tre a cinque giorni lavorativi. Un utente che scopre dati mancanti tre mesi dopo crea molti più problemi di una settimana di controlli in più adesso.

Cosa deve ricostruire il progetto

I dati sono la parte che gestisce il DTT. Il resto va inserito in piano di progetto e budget:

Logica personalizzata. Le estensioni V1 create con SAP Cloud Applications Studio (PDI, ABSL) non funzionano in V2. La logica si ricostruisce con gli strumenti key user di V2 (regole, convalide, determinazioni) oppure come estensione side-by-side su SAP BAIP. Di solito è la voce più consistente.

Workflow e notifiche. Si ricostruiscono in V2. Molti script di V1 diventano configurazione.

Integrazioni. Accordi di comunicazione, integrazione ERP e collegamenti con marketing e sistemi terzi vanno configurati di nuovo per V2. Per l’integrazione con S/4HANA, SAP mette a disposizione contenuti di integrazione standard sul SAP Business Accelerator Hub. Il nostro articolo sull’architettura di integrazione tra Sales Cloud V2 e S/4HANA Public Cloud mostra come la impostiamo. La telefonia è un tema a parte, trattato nella nostra guida all’integrazione CTI.

Adattamenti dell’interfaccia e mashup. Si ricostruiscono con gli strumenti di adattamento e i mashup di V2.

Report e dashboard. Si ricostruiscono nell’analitica di V2 o in SAP Analytics Cloud. È un buon momento per eliminare i report che nessuno apre.

Modelli di e-mail. Si ricreano in V2; la sintassi dei segnaposto è diversa.

Nei nostri progetti il trasferimento dei dati è la parte minore dello sforzo. La maggior parte del lavoro sta nelle voci sopra elencate. Per il quadro dei costi consultate la nostra guida a prezzi e costi di SAP Sales Cloud V2.

Quanto dura il filone DTT?

Sono gli intervalli con cui pianifichiamo il solo filone dati. Non sono cifre di SAP e dipendono molto dalla qualità dei dati e dal numero di campi di estensione.

Fase	Piccolo (da 25 a 50 utenti)	Medio (da 100 a 200 utenti)	Grande (oltre 500 utenti)
Readiness Check e pulizia di V1	1-2 settimane	2-4 settimane	4-6 settimane
Preparazione di V2 e mappatura	2-3 settimane	3-5 settimane	5-8 settimane
Configurazione del trasferimento	1 settimana	1-2 settimane	2-3 settimane
Trasferimenti di prova	1-2 settimane	2-3 settimane	3-4 settimane
Passaggio in produzione	1 fine settimana	1 fine settimana	1-2 fine settimana
Convalida	1 settimana	1-2 settimane	2-3 settimane
Durata complessiva	6-9 settimane	8-14 settimane	14-24 settimane

Le fasi si sovrappongono, per questo la durata complessiva è inferiore alla somma. Il progetto completo da V1 a V2 (ricostruzione di logica e integrazioni, formazione, go-live) procede in parallelo e di solito dura di più. Per il quadro generale consultate il nostro confronto sulla migrazione da V1 a V2 oppure provate il wizard V1-V2.

Tabella di pianificazione per un tenant di medie dimensioni

Settimana	Attività	Dipende da	Risultato
1-2	Richiedere il DTT, eseguire il Readiness Check	Accesso amministratore V1	Rapporto e lista delle azioni
2-4	Pulire V1	Lista delle azioni	Dati V1 puliti
3-6	Preparare il tenant V2	V2 disponibile	V2 configurato e vuoto
4-6	Campi di estensione e mappatura	Configurazione V2	Documento di mappatura
5-7	Configurare il trasferimento	Documento di mappatura	Trasferimento pronto
6-8	Trasferimento di prova 1	Trasferimento pronto	Lista errori e correzioni
8-9	Trasferimento di prova 2	Correzioni applicate	Rapporto di convalida
10	Passaggio in produzione	Prove superate	Dati in V2
10-12	Convalida e delta	Cutover completato	Approvazione delle funzioni aziendali

Aggiungete il 20 per cento a ogni stima. Pulizia e mappatura sono le fasi che più facilmente sforano, perché nessuno conosce il vero stato dei propri dati V1 finché non li guarda. I team tendono a sottostimare questa fase di circa la metà, ed è quella che detta il ritmo di tutto il resto.

Domande frequenti

Dove viene eseguito il Data Transfer Tool e come si ottiene l’accesso?

Il DTT viene eseguito nel vostro tenant V1, nel work center Transition. SAP lo attiva su richiesta: aprite un caso sulla componente LOD-LE-MIG-CNS indicando i dati del tenant V2, poi assegnate il work center Transition al ruolo degli amministratori in V1.

Il DTT supporta la migrazione delta?

Sì. Quando un oggetto è stato trasferito con successo, il DTT lo passa in modalità delta. Le esecuzioni successive riprendono i record creati o modificati in V1 dopo il caricamento iniziale: è ciò che serve per colmare la differenza tra l’ultima prova e il cutover. Verificate come il vostro scenario gestisce i record cancellati in V1 e prevedete una pulizia dopo il cutover.

Posso filtrare i record che il DTT trasferisce?

Non nel modo in cui la maggior parte dei team se lo aspetta. Il DTT trasferisce i dati di un oggetto, non un sottoinsieme filtrato. Ciò che non deve arrivare in V2 va pulito o archiviato in V1 prima del trasferimento.

Il DTT funziona anche per la migrazione di Service Cloud da V1 a V2?

Sì. Gli strumenti di transizione coprono Sales Cloud e Service Cloud, ticket compresi. Alcune configurazioni di servizio, come i tipi di caso, vanno prima create manualmente in V2. Il processo è lo stesso: Readiness Check, preparazione, trasferimenti di prova, cutover.

Posso migrare da un CRM di terze parti a V2 con il DTT?

No. Il DTT serve solo per il passaggio da V1 a V2. Da Salesforce, Dynamics 365 o altri sistemi si caricano i dati con il Data Workbench di V2 (importazione CSV o Excel) o tramite le API di V2, per volumi maggiori di solito attraverso SAP Integration Suite. Per i team di vendita che lavorano con fogli di calcolo, la nostra guida al passaggio da Excel a Sales Cloud V2 descrive il percorso più semplice.

Come gestire oggetti personalizzati con relazioni complesse?

I campi personalizzati sugli oggetti standard vengono trasferiti dal DTT una volta mappati, e i dati dei campi PDI sono supportati. Gli oggetti di business personalizzati con logica, relazioni e interfacce proprie vanno ricostruiti in V2 o su SAP BAIP. I loro dati si esportano da V1 tramite l’API OData e si caricano in V2 tramite le sue API. È lavoro di progetto, non lavoro del DTT.

Che cosa succede al sistema V1 dopo la migrazione?

Il DTT legge da V1 e non modifica i dati di origine. V1 resta operativo finché non lo dismettete. Stabilite per quanto tempo utenti e revisori hanno bisogno dell’accesso in lettura e pianificate la fine dell’abbonamento V1 come passo separato.

Esiste un volume massimo di dati per il DTT?

Non ci risulta un limite rigido pubblicato. Il volume determina i tempi di esecuzione: usate il Readiness Check per vedere record e volumi degli allegati per oggetto, fate le prove con volumi di produzione e pianificate la finestra di cutover sulla base dei tempi misurati.

---

Una migrazione da V1 a V2 è un progetto con un filone dati, non un trasferimento di dati con qualche attività accessoria. Il DTT rende gestibile la parte dei dati. Il resto dipende dalla preparazione: dati puliti, mappature complete, prove reali e un piano che descriva onestamente il lavoro di ricostruzione.

Se state pianificando una migrazione con il DTT e desiderate un secondo parere sul vostro rapporto di Readiness Check, contattateci. Lo esaminiamo volentieri insieme a voi.