SAP Sales Cloud V2 Data Transfer Tool: Guida pratica alla migrazione passo dopo passo

Il Data Transfer Tool di SAP esiste per risolvere un problema specifico: spostare i dati di produzione da Sales Cloud V1 (C4C) a Sales Cloud V2. È il percorso di migrazione ufficiale, supportato da SAP. E funziona. Ma la documentazione sembra scritta per chi il tool lo conosce già.

Abbiamo eseguito migrazioni DTT per diversi clienti — da team vendite con 50 utenti a deployment con oltre 500 utenti, oggetti personalizzati complessi e integrazioni profonde con S/4HANA. Questa guida copre ciò che la documentazione ufficiale tralascia: le decisioni pratiche, gli errori che incontrerete, i passaggi di validazione che vi salvano da un go-live fallito, e tempistiche realistiche basate su dati di progetto concreti.

TL;DR: Il Data Transfer Tool (DTT) di SAP migra dati anagrafici e transazionali da Sales/Service Cloud V1 a V2. Eseguite prima il Readiness Check Tool (RCT) — identifica i blocchi prima di partire. DTT gestisce automaticamente account, contatti, lead, opportunità, attività e ticket; oggetti personalizzati, integrazioni e logica workflow vanno ricostruiti manualmente. Una tipica migrazione di fascia media (100-200 utenti, 500K-2M record) richiede 8-14 settimane complessive. Eseguite sempre almeno due migrazioni di test complete prima del cutover produttivo. SAP ha migliorato significativamente il DTT nelle release 2508 e 2511 (SAP Community, 2025).

Cos’è il Data Transfer Tool (DTT)?

Il Data Transfer Tool è lo strumento integrato di SAP per trasferire dati aziendali da un tenant V1 (C4C) a un tenant V2. Non è un add-on di terze parti. È incorporato nella console di amministrazione V2, e SAP lo ha progettato per gestire le differenze strutturali tra i due modelli dati.

SAP ha introdotto il DTT in parallelo con la disponibilità generale di V2, per poi migliorarlo significativamente nella release 2508 (agosto 2025) e ancora nella 2511 (novembre 2025). La release 2508 ha aggiunto il supporto per custom business objects e una gestione degli errori migliorata. La release 2511 ha esteso la copertura alle attività email, note con allegati e una gestione migliore dei riferimenti cross-object (SAP Community, 2025).

Cosa trasferisce il DTT:

• Account (aziendali e individuali)
• Contatti e le relative relazioni con gli account
• Lead e qualificazioni lead
• Opportunità con prodotti, fasi di vendita e parti coinvolte
• Attività (appuntamenti, task, telefonate, email)
• Ticket di servizio e interazioni
• Prodotti e listini prezzi
• Territori di vendita e assegnazioni organizzative
• Campi personalizzati su oggetti standard
• Allegati e documenti (con limiti di dimensione)

Cosa il DTT non trasferisce:

• Logica di codice personalizzato (script ABSL, azioni custom)
• Regole workflow e configurazioni di escalation
• Configurazioni di integrazione (communication arrangements, API)
• Personalizzazioni UI (mashup, contenuti embedded, UI custom)
• Report e configurazioni analytics
• Impostazioni utente e personalizzazione
• Template email e campi di unione

La distinzione è fondamentale. DTT trasferisce i dati. Tutto il resto — la logica di business, le integrazioni, l’interfaccia utente — va ricostruito nell’architettura V2. Per una visione più ampia del progetto complessivo, leggete la nostra strategia di migrazione da C4C a V2.

Prerequisiti: cosa deve essere pronto prima di iniziare

Prima di toccare il DTT, diversi elementi devono essere in ordine. Saltare uno qualsiasi di questi crea problemi a valle che costano più tempo della preparazione stessa.

Requisiti di sistema

• Tenant V2 provisionato e attivato. Il vostro ambiente V2 deve essere live e accessibile. Sembra ovvio, ma il provisioning del tenant può richiedere 2-4 settimane attraverso il processo SAP. Iniziate per tempo.
• Tenant V1 su release supportata. DTT richiede che il vostro sistema V1 sia su un livello di patch minimo. Verificate la SAP Note 3350732 per il minimo attuale. Se siete indietro, applicate la patch prima.
• Accesso amministratore a entrambi i tenant. L’utente che esegue DTT necessita di diritti amministrativi completi sia nel sistema sorgente (V1) che nel sistema destinazione (V2). Un accesso parziale causa errori silenziosi.
• Connettività di rete. Entrambi i sistemi devono poter comunicare. Se il vostro tenant V1 utilizza IP whitelisting o configurazioni proxy personalizzate, assicuratevi che i range IP del tenant V2 siano autorizzati.

Eseguire prima il Readiness Check Tool

Il Readiness Check Tool (RCT) è separato dal DTT ma inscindibile dal processo. RCT analizza il vostro sistema V1 e produce un report di compatibilità: quali oggetti sono pronti per il trasferimento, quali necessitano attenzione e quali sono incompatibili.

Per noi l’RCT non è negoziabile. Ogni migrazione DTT che abbiamo eseguito inizia con il readiness check. Intercetta problemi che altrimenti emergerebbero a metà migrazione.

Pulizia dati in V1

I vostri dati V1 hanno accumulato anni di inconsistenze. DTT trasferirà fedelmente quelle inconsistenze in V2, a meno che non facciate pulizia prima.

• Account e contatti duplicati. Unire o contrassegnare i duplicati prima della migrazione. Le capacità di deduplicazione di V2 sono migliori, ma migrare 3’000 record duplicati per poi deduplicarli è uno spreco.
• Record orfani. Contatti senza account, attività senza record padre, opportunità collegate a prodotti cancellati. Trovateli. Correggeteli o eliminateli.
• Oggetti personalizzati senza dati. Se un oggetto personalizzato è vuoto da due anni, non ha bisogno di migrare. Ogni oggetto nel perimetro della migrazione aggiunge complessità.
• Utenti inattivi. Revisionate la vostra base utenti. Migrate solo gli utenti attivi. Riassegnate i record dei dipendenti usciti prima della migrazione, non dopo.

Gartner stima che la scarsa qualità dei dati costi alle organizzazioni in media 12,9 milioni di dollari all’anno (Gartner, 2021). Pulire i dati prima della migrazione è un investimento, non un costo.

Passo 1: Eseguire il Readiness Check

Accedete al Readiness Check Tool dal pannello di amministrazione V1 sotto Administrator > Data Transfer > Readiness Check. Su alcune versioni V1, lo trovate sotto Migration Tools.

Cosa vi dice il report RCT

Il report valuta il vostro sistema su tre dimensioni:

Compatibilità degli oggetti. Ogni business object riceve uno stato: Pronto (verde), Richiede Attenzione (giallo) o Incompatibile (rosso). Gli oggetti pronti possono essere trasferiti direttamente. Quelli con «Richiede Attenzione» hanno problemi minori — solitamente lacune nel mapping dei campi o differenze nel formato dati. Gli oggetti incompatibili richiedono gestione manuale.

Punteggio qualità dati. Il report segnala problemi di qualità: campi obbligatori mancanti, riferimenti interrotti, record orfani e record che superano i limiti di lunghezza dei campi V2. Un punteggio sotto il 70% significa che serve pulizia prima di procedere.

Valutazione oggetti personalizzati. I custom business objects vengono valutati per la compatibilità V2. Estensioni semplici (campi personalizzati su oggetti standard) si trasferiscono solitamente senza problemi. Oggetti personalizzati complessi con logica ABSL vengono segnalati per la ricostruzione manuale.

Come interpretare i risultati

Un punteggio perfetto è raro e non necessario. Ciò che conta è zero elementi rossi e un piano d’azione per ogni elemento giallo. Dalla nostra esperienza, un sistema V1 tipico mostra:

• 60-70% degli oggetti in verde (pronti)
• 25-35% in giallo (aggiustamenti minori necessari)
• 5-10% in rosso (ricostruzione manuale necessaria)

Gli elementi rossi riguardano quasi sempre logica di codice personalizzato e integrazioni complesse — cose per le quali DTT non è mai stato progettato. È atteso, non allarmante.

Documentate i risultati RCT. Diventano le fondamenta del vostro piano di migrazione. Ogni elemento giallo e rosso necessita di un responsabile e una data di risoluzione.

Passo 2: Preparare l’ambiente V2

Il vostro tenant V2 deve essere configurato prima di ricevere dati. DTT trasferisce record, ma non crea la configurazione aziendale per ospitarli.

Configurazione del tenant

• Struttura organizzativa. Ricreate la vostra struttura organizzativa in V2: organizzazioni di vendita, territori, divisioni. V2 utilizza un modello di assegnazione diverso, quindi non è una copia — è un riprogettazione.
• Provisioning utenti. Create gli account utente in V2 con i ruoli appropriati. Mappate gli ID utente V1 sugli ID utente V2 — DTT usa questo mapping per riassegnare la proprietà dei record.
• Configurazione aziendale. Impostate gli stati del ciclo di vita, i codici motivo, le fasi di vendita, le categorie prodotto e altri dati di configurazione. Devono esistere in V2 prima che arrivino i dati.

Mapping dei campi personalizzati

I campi personalizzati V1 necessitano di un mapping esplicito sui campi di estensione V2. È qui che si concentra la maggior parte del tempo di configurazione.

In V2, i campi personalizzati vengono creati attraverso il framework Key User Extensibility. Tipi di campo, lunghezze e liste di valori possono differire da V1. Per ogni campo personalizzato nel perimetro della migrazione:

1. Create il campo di estensione corrispondente in V2
2. Verificate che il tipo di dato corrisponda (testo, numero, data, lista codici)
3. Per i campi con lista codici, assicuratevi che tutti i valori V1 esistano nella lista valori V2
4. Documentate il mapping dall’ID campo V1 all’ID campo V2

Questo documento di mapping è essenziale. DTT lo utilizza durante il trasferimento dati per instradare correttamente i valori dei campi. Errori qui sono la causa più comune di fallimenti nella migrazione.

Per dettagli sulle funzionalità di SAP Sales Cloud V2 e sull’estensibilità di V2, consultate la nostra panoramica soluzioni.

Passo 3: Configurare il DTT

Con l’ambiente V2 preparato, aprite il Data Transfer Tool dalla console di amministrazione V2: Impostazioni > Migrazione > Data Transfer Tool.

Selezione degli oggetti

DTT presenta un elenco di oggetti trasferibili. Selezionate quali oggetti includere nella migrazione. La nostra raccomandazione: iniziate con i dati anagrafici, poi i dati transazionali.

L’ordine di migrazione è importante. Gli oggetti con dipendenze devono essere trasferiti in sequenza:

1. Prodotti e listini prezzi — referenziati da opportunità e preventivi
2. Account (account aziendali prima, poi clienti individuali)
3. Contatti — collegati agli account
4. Lead — referenziano contatti e account
5. Opportunità — referenziano account, contatti, prodotti
6. Attività — referenziano tutti i precedenti
7. Ticket di servizio — referenziano account, contatti, prodotti

DTT gestisce questa sequenza automaticamente se selezionate tutti gli oggetti contemporaneamente. Ma comprendere l’ordine aiuta nel debug: se le opportunità falliscono, spesso è perché un riferimento account non è stato trasferito in un batch precedente.

Mapping dei campi

DTT mappa automaticamente i campi standard tra V1 e V2. Per i campi personalizzati, configurate il mapping manualmente usando il documento di mapping del Passo 2.

L’interfaccia di mapping mostra:

• Campo sorgente (V1): nome campo, tipo dato, valori esempio
• Campo destinazione (V2): campo corrispondente o «Non mappato»
• Regole di trasformazione: conversione opzionale dei valori (es. codice V1 «A001» diventa codice V2 «ACTIVE»)

Revisionate ogni mapping. I campi auto-mappati sono solitamente corretti, ma abbiamo visto casi in cui campi con nomi simili in V1 e V2 avevano semantiche diverse. Un campo chiamato «Categoria» in V1 potrebbe mapparsi su «Classificazione» in V2 — stesso concetto, campo diverso.

Regole di trasformazione

Per i campi dove V1 e V2 utilizzano insiemi di valori diversi, definite regole di trasformazione:

• Mapping liste codici. Lo stato V1 «In Lavorazione» diventa lo stato V2 «In Corso». Definite ogni coppia di valori.
• Concatenazione campi. V1 potrebbe dividere l’indirizzo in Via1 + Via2. V2 potrebbe combinarli diversamente.
• Valori predefiniti. V2 può avere nuovi campi obbligatori che non esistono in V1. Impostate valori predefiniti per prevenire errori null.
• Gestione formato date. Raramente un problema nei trasferimenti SAP-to-SAP, ma verificate la gestione dei fusi orari se i vostri tenant V1 e V2 sono in regioni diverse.

Passo 4: Eseguire una migrazione di test

Non eseguite mai DTT contro dati di produzione senza almeno una — preferibilmente due — migrazioni di test complete. Questo non è negoziabile.

Approccio al test

1. Create un tenant V2 di test o usate l’ambiente di qualità/staging. Non testate mai contro l’istanza V2 di produzione.
2. Eseguite DTT con perimetro completo. Includete tutti gli oggetti, tutti i campi personalizzati, tutte le regole di trasformazione. Un test parziale non valida i riferimenti cross-object.
3. Usate dati a scala di produzione. Se la produzione ha 1 milione di record, non testate con 10’000. Il volume dei dati crea modalità di errore diverse: errori di timeout, limiti di memoria e colli di bottiglia di performance che appaiono solo a piena scala.
4. Misurate il tempo di esecuzione. Registrate quanto tempo impiega ogni tipo di oggetto. Questi dati determinano la vostra finestra di cutover produttivo.

Controlli di validazione dopo il test

Dopo il completamento del test:

Confronto conteggio record. Confrontate i conteggi sorgente e destinazione per ogni tipo di oggetto. Le discrepanze indicano record falliti.

Integrità delle relazioni. Controllate a campione 50-100 record tra i tipi di oggetto. Verificate che:

• I contatti siano collegati agli account corretti
• Le opportunità mostrino i prodotti e le fasi di vendita giusti
• Le attività siano associate ai record padre corretti
• I valori dei campi personalizzati si siano trasferiti correttamente

Revisione log errori. DTT genera un log errori dettagliato. Ogni errore va classificato: critico (blocca la migrazione), grave (perdita dati) o minore (cosmetico). Gli errori critici e gravi devono essere risolti prima dell’esecuzione in produzione.

Errori comuni nella migrazione di test e soluzioni

Superamento lunghezza campo. Un campo testo V1 ammette 255 caratteri; l’equivalente V2 ne ammette 100. I record con valori che superano il limite V2 falliscono. Soluzione: aumentare la lunghezza del campo V2 o aggiungere una regola di trasformazione per troncare.

Errori di lookup. Un’opportunità V1 referenzia un ID account che non esiste in V2. Succede quando i record account falliscono silenziosamente in un batch precedente. Soluzione: risolvere la causa radice (solitamente un problema di qualità dati in V1) e rieseguire.

Violazioni chiave duplicata. V2 ha vincoli di unicità più rigidi di V1. Se V1 permetteva ID esterni duplicati, V2 respingerà il secondo record. Soluzione: pulire i duplicati in V1 prima della migrazione.

Campi obbligatori null. V2 introduce nuovi campi obbligatori che non esistono in V1. I record senza valori falliscono. Soluzione: aggiungere valori predefiniti nelle regole di trasformazione.

Eseguite la migrazione di test, correggete tutti gli errori e rieseguitela. Tipicamente facciamo 2-3 cicli di test prima dell’esecuzione produttiva. Ogni ciclo dovrebbe produrre meno errori. Se i conteggi degli errori non diminuiscono, c’è qualcosa di sistemico che non funziona.

Passo 5: Eseguire la migrazione di produzione

La migrazione di produzione è il culmine del processo. A questo punto, avete già dimostrato che il processo funziona attraverso i test. L’esecuzione produttiva dovrebbe essere prevedibile.

Considerazioni sui tempi

Weekend o finestra a basso traffico. DTT carica sia il sistema V1 che V2. Eseguite fuori orario per minimizzare l’impatto sugli utenti attivi. Per le aziende europee, venerdì sera a domenica mattina è la finestra standard.

Periodo di congelamento. Dichiarate un blocco dati sul sistema V1 prima di iniziare. Nessun nuovo record, nessun aggiornamento. Le modifiche fatte in V1 dopo lo snapshot DTT vanno perse. Comunicatelo a tutti gli utenti con almeno una settimana di anticipo.

Pianificazione della durata. Usate i tempi della migrazione di test, con un margine del 20-30%. Se il test ha richiesto 8 ore, pianificate 10-12 ore per la produzione. Variabilità di rete, volumi di record maggiori e carico di sistema concorrente aggiungono tempo.

Monitoraggio del progresso

DTT fornisce una dashboard di progresso che mostra:

• Fase corrente (quale tipo di oggetto è in fase di trasferimento)
• Record elaborati vs. totale
• Conteggio errori (totale progressivo)
• Tempo rimanente stimato

Assegnate qualcuno al monitoraggio continuo. Se il tasso di errore supera il 2% per qualsiasi tipo di oggetto, mettete in pausa e investigate. È più facile risolvere un problema durante la migrazione che fare pulizia dopo un’esecuzione completata ma difettosa.

Strategia dei checkpoint

Per migrazioni di grandi dimensioni (1M+ record), considerate un approccio per fasi:

1. Fase A: Dati anagrafici — account, contatti, prodotti. Validare prima di procedere.
2. Fase B: Opportunità e lead — dipende da dati anagrafici puliti.
3. Fase C: Attività e ticket — volume più alto, rischio più basso se i dati anagrafici sono solidi.
4. Fase D: Allegati e documenti — trasferimento più lento, intensivo sulla rete.

Ogni fase ha un checkpoint. Validate conteggi e relazioni prima di avviare la fase successiva. Se la Fase B fallisce, annullate la Fase B senza perdere il trasferimento riuscito della Fase A.

Strategia di rollback

DTT non ha un rollback con un clic. Se la migrazione fallisce in modo catastrofico:

• V1 resta intatto. DTT legge da V1; non modifica la sorgente. Il vostro sistema V1 resta pienamente operativo.
• V2 può essere resettato. Per un riavvio pulito, SAP può resettare il tenant V2 allo stato vuoto. Richiede un ticket di supporto e impiega 24-48 ore.
• Rollback parziale. Se solo specifici tipi di oggetto sono falliti, potete eliminare i record falliti in V2 e rieseguire DTT solo per quegli oggetti.

L’approccio più sicuro: mantenere V1 pienamente operativo fino a quando V2 non è validato e gli utenti hanno confermato che la migrazione è completa. Raccomandiamo un periodo di operatività parallela di almeno 2 settimane.

Passo 6: Validazione post-migrazione

La migrazione è meccanicamente completa. Ora si dimostra.

Confronto conteggio record

Eseguite un confronto completo dei conteggi su tutti i tipi di oggetto migrati. È lo stesso controllo dei test, ma sui dati di produzione. Ciò che ha superato il test dovrebbe superare anche la produzione. Nuove discrepanze puntano a dati creati tra il test e il congelamento produttivo.

Verifiche di integrità delle relazioni

Più profondo del semplice conteggio. Validate che le relazioni aziendali siano sopravvissute al trasferimento:

• Gerarchie account. Le strutture genitore-figlio sono intatte.
• Associazioni contatto-account. Nessun contatto orfano.
• Pipeline opportunità. Fasi di vendita, ricavo atteso, date di chiusura e voci prodotto sono corretti.
• Timeline attività. Le attività recenti appaiono nel giusto ordine cronologico sui record corretti.
• Valori campi personalizzati. Controllate a campione 100+ record per ogni campo personalizzato per verificare che le regole di trasformazione abbiano funzionato.

Checklist per il test di accettazione utente

Prima di dichiarare il successo, fate validare ai business user i propri dati:

• Responsabili vendite: aprire la vista pipeline, verificare che conteggi e valori delle opportunità corrispondano
• Account executive: controllare i 10 account principali per completezza
• Agenti di servizio: verificare la cronologia recente dei ticket e i log delle interazioni cliente
• Amministratori: confermare assegnazioni territoriali e mapping ruoli utente
• Reporting: eseguire report standard e confrontare i totali con le baseline V1

Lo UAT richiede tipicamente 3-5 giorni lavorativi. Non affrettatevi. Un utente che scopre dati mancanti tre mesi dopo è molto più disruptivo di una settimana extra di validazione adesso.

Cosa il DTT non trasferisce

Questa sezione è critica. Comprendere cosa DTT non copre determina il resto del perimetro e del budget del vostro progetto di migrazione.

Logica di codice personalizzato. V1 utilizza ABSL (ABAP Scripting Language) per la logica di business personalizzata. V2 non supporta ABSL. Tutta la logica personalizzata deve essere reimplementata — come configurazioni key user V2 o come estensioni basate su BTP. Questo è tipicamente lo sforzo manuale più grande nella migrazione.

Regole workflow. I workflow V1 non si trasferiscono. Ricostruiteli nel rule engine di V2. La buona notizia: il rule engine di V2 è più potente. Molti workflow V1 che richiedevano codice personalizzato possono essere costruiti con configurazione in V2.

Configurazioni di integrazione. Communication arrangements, endpoint API, connessioni middleware e configurazioni SSO sono specifiche del tenant. Ogni integrazione deve essere ristabilita in V2. Se il vostro sistema V1 si integra con S/4HANA, strumenti marketing o servizi di terze parti, pianificate una ricostruzione completa delle integrazioni. Leggete la nostra guida all’integrazione CTI per vedere come appaiono le integrazioni V2 nella pratica.

Personalizzazioni UI. Mashup, contenuti HTML embedded, voci di navigazione personalizzate e side panel devono essere ricostruiti nel framework UI di V2. V2 utilizza un modello di estensione side-by-side diverso tramite SAP Build Work Zone.

Report e dashboard. I report V1 non si trasferiscono. Ricostruiteli usando le analytics integrate di V2 o SAP Analytics Cloud. La maggior parte dei clienti scopre che il reporting nativo di V2 copre l’80% di ciò che avevano costruito manualmente in V1.

Template email. I template email con campi di unione vanno ricreati nell’editor template di V2. La sintassi dei campi di unione è diversa.

Includete questo nel budget. In un tipico progetto di migrazione DTT, il trasferimento dati in sé rappresenta il 20-30% dello sforzo totale. Il restante 70-80% è la ricostruzione degli elementi sopra elencati. Per il contesto dei costi, leggete la nostra guida ai prezzi di SAP Sales Cloud V2.

Errori DTT comuni e come risolverli

In base ai nostri progetti di migrazione, questi sono gli errori che incontrerete più frequentemente:

Mantenete un log errori aggiornato. Categorizzate gli errori per gravità e frequenza. Alcuni errori (come i limiti dimensione allegati) riguardano pochi record e possono essere gestiti individualmente dopo la migrazione. Altri (come «riferimento non trovato») indicano problemi sistemici che richiedono un’analisi delle cause radice.

Tempistiche: quanto dura una migrazione DTT?

Le tempistiche variano in base al volume dati, alla complessità delle personalizzazioni e al numero di integrazioni. Ecco cosa abbiamo visto nei nostri progetti:

Per dimensione aziendale

Queste tempistiche coprono solo il workstream di migrazione dati. Il progetto complessivo V1-a-V2 — inclusa la ricostruzione delle integrazioni, la reimplementazione della logica personalizzata, la formazione e il go-live — è più lungo. Per il quadro completo, leggete il nostro confronto migrazione V1 vs V2.

Tabella di pianificazione

Usate questo come framework iniziale per il vostro piano di progetto:

Aggiungete il 20% a ogni stima. Nella nostra esperienza, le fasi di pulizia dati e mapping campi sono le più soggette a sforamenti. Nessuno conosce il vero stato dei propri dati V1 fino a quando non va a guardare.

FAQ

Il DTT supporta la migrazione delta?

Sì, con alcune limitazioni. DTT può essere eseguito in modo incrementale per trasferire record creati o modificati dopo la migrazione iniziale. Questo è utile per il periodo tra la migrazione di test e il cutover produttivo. Tuttavia, la migrazione delta non gestisce le cancellazioni — i record eliminati in V1 dopo il trasferimento iniziale restano in V2. Pianificate un passaggio di pulizia dopo il cutover.

Posso eseguire il DTT più volte?

Sì. DTT è progettato per l’esecuzione iterativa. Ogni esecuzione può essere limitata a specifici tipi di oggetto o filtrata per intervallo di date. Le esecuzioni successive saltano i record già trasferiti (identificati da chiavi univoche). È così che funziona il ciclo test-e-affina.

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

Sì. DTT copre sia gli oggetti Sales Cloud che Service Cloud. Ticket di servizio, interazioni, articoli della knowledge base e configurazioni SLA rientrano nell’ambito del DTT. Il processo è identico — prima RCT, poi configurazione DTT, esecuzioni di test e migrazione produttiva.

Cosa succede al mio sistema V1 dopo la migrazione?

Nulla. V1 resta pienamente operativo. SAP raccomanda di mantenere l’accesso a V1 per almeno 90 giorni dopo il go-live di V2 per scopi di riferimento e audit. Prima o poi il tenant V1 viene dismesso, ma è un processo separato secondo i vostri tempi.

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

No. DTT è esclusivamente per la migrazione SAP V1-a-V2. Se state migrando da Salesforce, Dynamics 365 o un altro CRM, userete le API di importazione dati standard di SAP o una soluzione middleware. Abbiamo pubblicato una guida separata sulla migrazione da Excel a V2 per scenari più semplici.

Come gestisco oggetti personalizzati con relazioni complesse?

Gli oggetti personalizzati con strutture semplici (campi personalizzati su oggetti standard) si trasferiscono tramite DTT. Oggetti business personalizzati complessi con relazioni inter-oggetto, logica ABSL o UI custom necessitano di ricostruzione manuale. Esportate i dati da V1 via OData, trasformateli e importateli in V2 via le API V2. Questo è lavoro di progetto, non lavoro DTT.

Cosa succede se il mio sistema V1 è fortemente personalizzato?

Forte personalizzazione significa più sforzo di ricostruzione manuale, ma non vi esclude dall’uso del DTT. DTT gestisce i dati; il vostro team di progetto gestisce la logica. Il report RCT quantifica esattamente quanta personalizzazione si trova fuori dall’ambito DTT. Usate quel report per definire perimetro e budget dei workstream manuali.

Esiste un volume massimo di dati per il DTT?

SAP non pubblica un limite fisso. Abbiamo migrato con successo tenant con oltre 10M di record su tutti i tipi di oggetto. La performance è il vincolo pratico: dataset molto grandi richiedono più tempo e possono necessitare di ottimizzazione delle dimensioni dei batch. La release 2511 ha migliorato significativamente le performance DTT per scenari ad alto volume.

La migrazione da V1 a V2 non è opzionale per le organizzazioni investite nell’ecosistema CRM di SAP. Il Data Transfer Tool rende gestibile la parte relativa ai dati. Ciò che distingue una migrazione fluida da una dolorosa è la preparazione: dati puliti, mapping completo dei campi, test approfonditi e tempistiche realistiche.

Se state pianificando una migrazione DTT e volete un secondo parere sulla vostra preparazione, contattateci. Abbiamo fatto questo percorso abbastanza volte da sapere dove si nascondono i problemi.