SAP Sales Cloud V2 Data Transfer Tool: Die Migrationsanleitung Schritt für Schritt

Das Data Transfer Tool (DTT) von SAP überträgt Geschäftsdaten und Konfiguration aus SAP Cloud for Customer (C4C, «V1») nach SAP Sales Cloud und Service Cloud Version 2. Es ist ein Werkzeug von SAP, wird von SAP unterstützt und wird mit fast jedem Quartalsrelease besser. Was die Dokumentation nicht liefern kann, ist das Projekt drumherum: die Reihenfolge der Arbeiten, die Vorbereitung, die Testzyklen und die Entscheidungen, die Ihnen niemand abnimmt.

Diese Anleitung beschreibt dieses Projekt. Sie folgt der Reihenfolge, die wir in V1-zu-V2-Projekten verwenden: Readiness Check, Bereinigung, Vorbereitung von V2, Testübertragungen, Produktivübernahme und Validierung. Wo eine Aussage das Werkzeug von SAP beschreibt, verweist sie auf die SAP-Dokumentation. Wo sie unsere Planung beschreibt, steht das dabei.

Kurzfassung: Das DTT läuft in Ihrem V1-Tenant (Work Center «Transition») und wird von SAP auf Anfrage freigeschaltet. Führen Sie zuerst den Readiness Check aus, bereinigen Sie V1 (das DTT filtert keine Datensätze) und bereiten Sie einen leeren V2-Tenant mit der Konfiguration vor, die jedes Objekt braucht. Danach mindestens zwei vollständige Testübertragungen, die Produktivübernahme in einem geplanten Freeze-Fenster und der Delta-Modus für die Lücke dazwischen. Das DTT übernimmt die Daten; Eigenlogik, Integrationen, UI-Erweiterungen und Berichte werden in V2 neu aufgebaut. Der Datenstrang eines mittelgrossen Tenants dauert in unserer Planung typischerweise 8 bis 14 Wochen.

Was ist das Data Transfer Tool (DTT)?

Das DTT ist der Übertragungsteil des SAP-Werkzeugsets für den Wechsel von V1 zu V2. Der andere Teil ist das Readiness Check Tool (RCT), das Ihren V1-Tenant analysiert, bevor irgendetwas übertragen wird. Beide liegen im Work Center Transition des V1-Systems (SAP Help: Data Transfer Tool; SAP Help: Readiness Check Tool).

Das DTT überträgt Daten Objekt für Objekt. Für jedes unterstützte Objekt liefert SAP eine Vorlage mit Feldzuordnung, Transformationslogik und Ladevalidierung. Das Werkzeug steuert auch die Reihenfolge zwischen abhängigen Objekten und schreibt Protokolle und Fehlermeldungen, mit denen man arbeiten kann.

Der Umfang ist stetig gewachsen. Einige Änderungen aus den Release-Briefings von SAP:

• 2508 (August 2025): Testübertragung mit «Data Only» als Standard, eine Transfer History zur Überwachung, neue Objekte wie Territories und Competitor Products sowie Unterstützung für Notizen, externe IDs von Produktgruppen und weitere Erweiterungsfelder.
• 2511 (November 2025): Der Ladevorgang für die Geschäftskonfiguration lässt sich von der Übertragung der Geschäftsdaten trennen, dazu neue Voraussetzungsprüfungen (zum Beispiel der gescopten Services in V2) und detailliertere Fehlermeldungen (SAP Community: Release-Briefing 2511).
• 2602 (Februar 2026): Besuche, Routenplanung und Kontenhierarchie als übertragbare Objekte; die Übertragung von PDI-Felddaten ist nicht mehr Beta, sondern allgemein verfügbar (SAP Community: Pre-Release-Briefing 2602).
• 2605 (Mai 2026): eine Mengenübersicht für Organisationsstrukturen, die Übertragung von Key-User-Erweiterungsfeldern auf Geschäftspartnerbeziehungen und Codelisten-Zuordnungen als Teil von «Transfer All BC» (SAP Community: Pre-Release-Briefing 2605).

Weil sich die Liste jedes Quartal ändert, prüfen Sie die Objektliste zu Projektbeginn auf der SAP-Hilfeseite und nicht in einem Blogbeitrag (diesen eingeschlossen).

Was das DTT typischerweise abdeckt: Konten, Kontakte, Privatkunden, Leads, Opportunities, Aktivitäten (Termine, Aufgaben, Telefonate), Tickets, Produkte und zugehörige Stammdaten, Territorien, Organisationsstrukturen, Notizen und Anhänge sowie Erweiterungsfelder, sofern die Zuordnung vollständig ist.

Was das DTT nicht abdeckt:

• Eigenlogik aus dem V1-SDK (PDI-/ABSL-Skripte, eigene Business-Objekte mit eigenem Verhalten)
• Workflow-Regeln und Benachrichtigungen
• Integrationsszenarien mit ERP und Drittsystemen
• UI-Anpassungen und Mashups
• Berichte und Dashboards
• Persönliche Einstellungen und E-Mail-Vorlagen

Diese Aufteilung bestimmt das Projekt. Das DTT überträgt die Daten. Alles andere wird in der Architektur von V2 neu aufgebaut. Für die strategische Seite dieser Entscheidung lesen Sie unseren Beitrag zur Migrationsstrategie von C4C zu V2 und unsere Einschätzung der aktuellen Grenzen von V2.

Voraussetzungen vor dem Start

Zugang und Tenants

• DTT bei SAP anfordern. SAP schaltet das Werkzeug pro Kunde frei. Eröffnen Sie einen Case auf der Komponente LOD-LE-MIG-CNS und geben Sie die URL Ihres V2-Tenants an.
• Work Center «Transition» zuordnen. Ordnen Sie in V1 das Work Center «Transition» der Geschäftsrolle der Administratoren zu, die den Readiness Check und die Übertragung ausführen.
• V2-Tenant früh bereitstellen. SAP gibt vor, dass der V2-Zieltenant leer sein soll, also ohne Geschäftsdaten. Lassen Sie niemanden im Tenant «ausprobieren», in den Sie später laden. Für Prototypen nutzen Sie einen separaten Tenant.
• Voraussetzungen pro Objekt prüfen. Manche Konfiguration muss vor der Übertragung in V2 existieren, zum Beispiel Case-Typen für Tickets. SAP dokumentiert das pro Objekt. Lesen Sie diese Seiten bei der Planung, nicht erst beim ersten Testlauf.

Zuerst den Readiness Check ausführen

Das Readiness Check Tool analysiert Ihren V1-Tenant. Es zeigt, welche Standardobjekte Sie nutzen, wie viele Daten pro Objekt vorhanden sind, welche eigenen Felder, PDI-Lösungen, Mashups und eingebetteten Komponenten es gibt und welche Punkte SAP als Transition-Blocker einstuft. Neuere Releases haben Anhangsvolumen pro Objekt und eine Liste der installierten Add-ons ergänzt.

Für uns beginnt jedes V1-zu-V2-Projekt mit dem Readiness Check. Er liefert die erste belastbare Antwort auf die Frage: Wie viel unseres Systems wandert automatisch, und wie viel bauen wir neu?

V1 vor der Übertragung bereinigen

Mit dem DTT können Sie pro Objekt keine Teilmenge von Datensätzen auswählen. Was in V1 liegt, wird übertragen. Die Bereinigung muss deshalb in V1 stattfinden:

• Dubletten. Führen Sie doppelte Konten und Kontakte in V1 zusammen. V2 hat eine konfigurierbare Dublettenprüfung, doch die ist für neue Datensätze gedacht und nicht dafür, Tausende übernommener Datensätze zu sortieren.
• Verwaiste Datensätze. Kontakte ohne Konto, Aktivitäten ohne übergeordneten Datensatz, Opportunities mit ausgelaufenen Produkten. Korrigieren oder archivieren Sie sie.
• Veraltete eigene Felder. Ein Feld, das seit zwei Jahren niemand ausfüllt, braucht in V2 kein Erweiterungsfeld. Jedes Feld im Umfang braucht eine Zuordnung und einen Test.
• Ausgeschiedene Benutzer. Weisen Sie Datensätze ehemaliger Mitarbeitender vor der Übertragung neu zu, nicht danach.

Jetzt ist auch der richtige Moment, festzulegen, was «gute Daten» für Ihr V2-System bedeuten. Unser Beitrag zur CRM-Datenqualität als Fundament für KI beschreibt die Regeln, mit denen wir arbeiten.

Schritt 1: Den Readiness Check richtig lesen

Öffnen Sie den Readiness Check im Work Center «Transition» von V1 und lassen Sie ihn gegen Ihren Produktivtenant laufen. Gehen Sie die Ergebnisse dann nach Kategorien durch:

Standardobjekte und Mengen. Welche Objekte sind in Gebrauch, und wie viele Datensätze enthält jedes? Die Menge bestimmt die Dauer der Test- und Produktivläufe.

Kundeneigene Erweiterungen. Eigene Felder, PDI-Lösungen, Mashups und eingebettete Komponenten. Diese Liste ist der Backlog für Ihre Neuaufbau-Stränge: Manches wird zum Erweiterungsfeld in V2, manches zur Side-by-Side-Erweiterung auf SAP BTP, und manches fällt weg.

Transition-Blocker. Punkte, die eine automatische Übertragung verhindern. Jeder davon braucht eine verantwortliche Person und eine Entscheidung.

Machen Sie aus dem Ergebnis einen Migrationsplan: jedes Objekt im Umfang, seine Voraussetzungen in V2, der Stand der Zuordnung und wer das Ergebnis abnimmt. Dieses Dokument ist Ihr Plan für die kommenden Wochen.

Schritt 2: Den V2-Tenant vorbereiten

Das DTT überträgt Datensätze. Es entwirft nicht Ihr V2-System.

Organisation und Benutzer

• Organisationsstruktur. Vertriebs- und Serviceorganisationen, Einheiten und Territorien. V2 hat ein eigenes Modell; behandeln Sie das als Designschritt, nicht als Kopie.
• Benutzer und Rollen. Legen Sie Benutzer und Geschäftsrollen in V2 an, damit die Zuständigkeit für Datensätze bei der Übertragung zugeordnet werden kann.
• Geschäftskonfiguration. Verkaufszyklen und Phasen, Status- und Grundcodes, Produktkategorien und die übrigen Einstellungen, auf die übertragene Daten verweisen. Seit 2511 lassen sich Konfiguration und Daten getrennt laden. Das macht es einfacher, zuerst die Konfiguration sauber abzuschliessen.

Erweiterungsfelder und Codelisten

Eigene Felder aus V1 brauchen ein Ziel in V2. Dort werden sie als Erweiterungsfelder über die Key-User-Erweiterbarkeit angelegt. Für jedes Feld im Umfang:

1. Erweiterungsfeld in V2 mit passendem Datentyp anlegen
2. Bei Codelisten-Feldern sicherstellen, dass jeder in V1 verwendete Wert in V2 existiert oder zugeordnet ist
3. V1-Feld und V2-Ziel im Zuordnungsdokument festhalten
4. Im ersten Übertragungslauf testen

Unvollständige Zuordnungen sind der häufigste Grund für abgelehnte Datensätze in Testläufen. Erweiterungsfelder, Notizen und Anhänge werden nur übertragen, wenn die Zuordnung für das Business-Objekt vollständig ist.

Einen Überblick, was V2 im Standard mitbringt, gibt unsere Lösungsseite zu SAP Sales Cloud V2.

Schritt 3: Die Übertragung konfigurieren

Im Work Center «Transition» listet das DTT die übertragbaren Objekte auf. Beginnen Sie mit Stammdaten, danach folgen Bewegungsdaten. Das DTT steuert die Reihenfolge zwischen abhängigen Objekten selbst, doch um die Protokolle zu lesen, müssen Sie die Abhängigkeiten kennen:

1. Organisationsstruktur, Territorien, Produkte
2. Konten und Privatkunden
3. Kontakte und Beziehungen
4. Leads
5. Opportunities
6. Aktivitäten (Termine, Aufgaben, Telefonate, Besuche)
7. Tickets

Wenn Opportunities scheitern, liegt die Ursache oft eine Ebene höher: ein Konto, das nicht übertragen wurde, ein Produkt, das es in V2 nicht gibt, oder ein fehlender Codelistenwert.

Prüfen Sie die mitgelieferten Zuordnungsvorlagen Objekt für Objekt. Die Standardfelder hat SAP zugeordnet. Ihre Aufgabe ist der kundeneigene Teil: Erweiterungsfelder, Codelistenwerte und die Felder, deren Bedeutung sich in Ihrer V1-Nutzung über die Jahre verschoben hat. Ein Feld «Kategorie» kann in drei Verkaufseinheiten drei verschiedene Dinge bedeuten.

Schritt 4: Testübertragungen durchführen

Führen Sie die Produktivübertragung nie ohne mindestens einen, besser zwei vollständige Testläufe durch.

So testen Sie

1. Einen V2-Testtenant verwenden, der leer und genau wie der Produktivtenant vorbereitet ist. Testen Sie nie im Tenant, mit dem Sie live gehen.
2. Den vollen Umfang übertragen. Alle Objekte, alle Erweiterungsfelder. Ein Teiltest zeigt die Probleme in objektübergreifenden Verweisen nicht.
3. Produktive Mengen verwenden. Eine kleine Stichprobe verdeckt die Probleme, die erst bei grossen Mengen auftreten: lange Laufzeiten, grosse Anhänge, seltene Codelistenwerte.
4. Die Laufzeit pro Objekt messen. Diese Zahlen bestimmen Ihr Cutover-Fenster.

Was Sie nach jedem Lauf prüfen

Mengen. Vergleichen Sie die Anzahl Datensätze pro Objekt in V1 und V2. Transfer History und Mengenübersichten helfen; bei wichtigen Objekten zählen Sie zusätzlich unabhängig nach.

Objekt	V1	V2	Differenz	Massnahme
Konten	12’450	12’450	0	OK
Kontakte	34’200	34’187	-13	Protokoll prüfen
Opportunities	8’930	8’930	0	OK
Aktivitäten	156’000	155’842	-158	Protokoll prüfen

Beispiel zur Veranschaulichung, keine Kundendaten.

Beziehungen. Prüfen Sie stichprobenartig 50 bis 100 Datensätze über alle Objekte: Hängen Kontakte an den richtigen Konten, zeigen Opportunities die richtigen Produkte und Phasen, hängen Aktivitäten am richtigen übergeordneten Datensatz, sind die Werte der Erweiterungsfelder angekommen?

Fehlerprotokoll. Ordnen Sie jeden Fehler ein: blockierend, Datenverlust oder kosmetisch. Blockierende Fehler und Datenverluste werden vor dem nächsten Lauf behoben.

Typische Fehlerkategorien

Kategorie	Typische Ursache	Vorgehen
Fehlender Verweis	Ein übergeordneter Datensatz (Konto, Produkt) wurde nicht übertragen oder existiert in V2 nicht	Zuerst das übergeordnete Objekt korrigieren, dann das abhängige Objekt erneut übertragen
Unbekannter Codelistenwert	Ein V1-Wert hat in V2 kein Gegenstück	Wert in V2 ergänzen oder einem bestehenden zuordnen
Leeres Pflichtfeld	V2 verlangt einen Wert, den V1 nie hatte	Standardwert in der Zuordnung setzen oder das Feld vor der Übertragung in V1 füllen
Erweiterungsfeld nicht übertragen	Zuordnung für das Business-Objekt unvollständig	Zuordnung vervollständigen, Objekt erneut übertragen
Fehlende V2-Konfiguration	Voraussetzung nicht angelegt (zum Beispiel Case-Typen)	Konfiguration in V2 anlegen; die Voraussetzungsprüfungen seit 2511 melden viele dieser Fälle
Dubletten	V1 enthält denselben Kunden mehrfach	Vor dem nächsten Lauf in V1 zusammenführen
Grosse Anhänge	Dateien überschreiten Grössengrenzen oder bremsen den Lauf	Anhangsvolumen im Readiness Check prüfen; sehr grosse Dateien archivieren oder separat übertragen

Die genauen Meldungen stehen im DTT-Protokoll; seit 2511 zeigt SAP den Fehlertyp detaillierter an. Planen Sie zwei bis drei Testzyklen. Jeder Zyklus sollte weniger Fehler bringen. Sinken die Zahlen nicht, stimmt etwas Grundsätzliches nicht: meist bei der Zuordnung oder bei der Datenqualität in V1.

Schritt 5: Die Produktivübertragung durchführen

Jetzt sollte der Ablauf keine Überraschungen mehr bergen. Der Produktivlauf wiederholt, was die Testläufe bewiesen haben.

Zeitpunkt

Ruhiges Zeitfenster wählen. Die Übertragung belastet beide Systeme. Für Unternehmen in der Schweiz und in Deutschland ist das Wochenende die übliche Wahl.

V1 einfrieren. Kündigen Sie mindestens eine Woche im Voraus einen Änderungsstopp in V1 an. Was nach dem Snapshot in V1 geändert wird, muss über den Delta-Modus nachkommen oder geht verloren.

Dauer mit Puffer planen. Nehmen Sie die Laufzeit des letzten Testlaufs und rechnen Sie 20 bis 30 Prozent dazu. Die Produktivmengen sind grösser, und die Systeme stehen unter anderer Last.

Den Lauf überwachen

Bestimmen Sie eine Person, die die Übertragung durchgehend über Transfer History und Protokolle verfolgt. Zeigt ein Objekt ungewöhnlich viele Fehler, halten Sie an und klären Sie die Ursache. Ein Problem mitten im Lauf ist billiger als eine abgeschlossene, aber fehlerhafte Übertragung.

Checkpoints für grosse Tenants

Bei Tenants mit mehr als einer Million Datensätzen teilen Sie den Lauf in Phasen und validieren nach jeder Phase:

1. Stammdaten: Organisationsstruktur, Produkte, Konten, Kontakte
2. Verkaufsbelege: Leads und Opportunities
3. Aktivitäten und Tickets: die grössten Mengen
4. Anhänge: der langsamste Teil

Den Rückfall planen

Das DTT liest aus V1 und verändert die Quelle nicht. Scheitert die Produktivübertragung, ist V1 unversehrt, und die Anwender arbeiten dort weiter. Weil V2 vor der Übertragung leer sein soll, heisst ein Neustart, den V2-Tenant zu bereinigen. Klären Sie mit SAP im Voraus, wie ein Zurücksetzen abläuft, und planen Sie diese Zeit ein. Halten Sie V1 verfügbar, bis V2 validiert und abgenommen ist.

Schritt 6: Nach dem Cutover validieren

Mengen und Delta

Wiederholen Sie den Mengenvergleich mit den Produktivdaten. Jede neue Differenz deutet auf Datensätze hin, die zwischen dem letzten Testlauf und dem Freeze angelegt oder geändert wurden. Für diese Objekte lassen Sie die Delta-Übertragung laufen.

Geschäftsbeziehungen

• Kontenhierarchien sind vollständig
• Kontakte hängen an den richtigen Konten
• Pipeline: Phasen, erwartete Werte, Abschlussdaten und Produkte stimmen
• Aktivitätenhistorie erscheint in der richtigen Reihenfolge am richtigen Datensatz
• Erweiterungsfelder tragen die richtigen Werte (mindestens 100 Datensätze pro wichtigem Feld stichprobenartig prüfen)

Abnahme durch die Fachbereiche

Bevor Sie den Erfolg melden, prüfen die Anwender ihre eigenen Daten:

• Vertriebsleitung: Pipeline-Ansicht, Anzahl und Wert der Opportunities
• Account Manager: ihre zehn wichtigsten Konten
• Service-Mitarbeitende: aktuelle Tickets und Kundenhistorie
• Administratoren: Territorien, Rollen und Zuordnungen
• Reporting: Kennzahlen im Vergleich mit V1

Planen Sie drei bis fünf Arbeitstage ein. Wer drei Monate später fehlende Daten entdeckt, verursacht weit mehr Aufwand als eine zusätzliche Woche Prüfung jetzt.

Was das Projekt neu aufbauen muss

Die Daten sind der Teil, den das DTT übernimmt. Der Rest gehört in Projektplan und Budget:

Eigenlogik. V1-Erweiterungen aus dem SAP Cloud Applications Studio (PDI, ABSL) laufen in V2 nicht. Die Logik wird mit den Key-User-Werkzeugen von V2 (Regeln, Validierungen, Ableitungen) oder als Side-by-Side-Erweiterung auf SAP BTP neu gebaut. Das ist meist der grösste Posten beim Neuaufbau.

Workflows und Benachrichtigungen. Diese bauen Sie in V2 neu auf. Viele V1-Skripte werden dabei zu Konfiguration.

Integrationen. Kommunikationsvereinbarungen, ERP-Integration, Marketing- und Drittanbieteranbindungen werden für V2 neu eingerichtet. Für die Integration mit S/4HANA stellt SAP Standard-Integrationsinhalte im SAP Business Accelerator Hub bereit. Unser Beitrag zur Integrationsarchitektur von Sales Cloud V2 und S/4HANA Public Cloud zeigt, wie wir das aufsetzen. Telefonie ist ein eigenes Thema; dazu gibt es unseren CTI-Leitfaden.

UI-Anpassungen und Mashups. Diese bauen Sie mit den Anpassungswerkzeugen und Mashups von V2 neu auf.

Berichte und Dashboards. Neu aufbauen in der V2-Analytik oder in SAP Analytics Cloud. Ein guter Moment, die Berichte zu löschen, die niemand öffnet.

E-Mail-Vorlagen. In V2 neu anlegen; die Platzhalter-Syntax ist anders.

In unseren Projekten ist die Datenübertragung der kleinere Teil des Aufwands. Der grösste Teil steckt in den Punkten oben. Für den Budgetrahmen lesen Sie unseren Preis- und Kostenleitfaden zu SAP Sales Cloud V2.

Wie lange dauert der DTT-Strang?

Das sind die Spannen, mit denen wir für den Datenstrang allein planen. Es sind keine SAP-Zahlen, und sie hängen stark von der Datenqualität und der Anzahl Erweiterungsfelder ab.

Phase	Klein (25 bis 50 Benutzer)	Mittel (100 bis 200 Benutzer)	Gross (500+ Benutzer)
Readiness Check und Bereinigung V1	1 bis 2 Wochen	2 bis 4 Wochen	4 bis 6 Wochen
Vorbereitung V2 und Zuordnung	2 bis 3 Wochen	3 bis 5 Wochen	5 bis 8 Wochen
Konfiguration der Übertragung	1 Woche	1 bis 2 Wochen	2 bis 3 Wochen
Testübertragungen	1 bis 2 Wochen	2 bis 3 Wochen	3 bis 4 Wochen
Produktivübernahme	1 Wochenende	1 Wochenende	1 bis 2 Wochenenden
Validierung	1 Woche	1 bis 2 Wochen	2 bis 3 Wochen
Gesamtdauer	6 bis 9 Wochen	8 bis 14 Wochen	14 bis 24 Wochen

Die Phasen überlappen sich, deshalb ist die Gesamtdauer kürzer als die Summe. Das gesamte V1-zu-V2-Projekt (Neuaufbau von Logik und Integrationen, Schulung, Go-live) läuft parallel und dauert meist länger. Das grössere Bild zeigt unser Vergleich zur Migration von V1 auf V2, oder Sie probieren den V1-zu-V2-Assistenten aus.

Planungstabelle für einen mittelgrossen Tenant

Woche	Aktivität	Abhängig von	Ergebnis
1 bis 2	DTT anfordern, Readiness Check ausführen	Admin-Zugang V1	Readiness-Bericht und Massnahmenliste
2 bis 4	V1 bereinigen	Massnahmenliste	Bereinigte V1-Daten
3 bis 6	V2-Tenant vorbereiten	V2 bereitgestellt	Konfiguriertes, leeres V2
4 bis 6	Erweiterungsfelder und Zuordnung	V2-Konfiguration	Zuordnungsdokument
5 bis 7	Übertragung konfigurieren	Zuordnungsdokument	Übertragung bereit
6 bis 8	Testübertragung 1	Übertragung bereit	Fehlerliste und Korrekturen
8 bis 9	Testübertragung 2	Korrekturen umgesetzt	Validierungsbericht
10	Produktivübernahme	Tests bestanden	Daten in V2
10 bis 12	Validierung und Delta	Cutover abgeschlossen	Abnahme durch die Fachbereiche

Rechnen Sie bei jeder Schätzung 20 Prozent dazu. Bereinigung und Zuordnung sind die Phasen, die am ehesten überziehen, denn niemand kennt den wahren Zustand seiner V1-Daten, bevor er hinschaut. Teams unterschätzen diese Phase gern um die Hälfte, und sie gibt das Tempo für alles Weitere vor.

Häufige Fragen

Wo läuft das Data Transfer Tool, und wie erhalte ich Zugang?

Das DTT läuft in Ihrem V1-Tenant, im Work Center «Transition». SAP schaltet es auf Anfrage frei: Eröffnen Sie einen Case auf der Komponente LOD-LE-MIG-CNS mit den Angaben zu Ihrem V2-Tenant und ordnen Sie danach das Work Center «Transition» der Administratorrolle in V1 zu.

Unterstützt das DTT eine Delta-Migration?

Ja. Sobald ein Objekt erfolgreich übertragen wurde, schaltet das DTT dieses Objekt in den Delta-Modus. Spätere Läufe übernehmen Datensätze, die seit dem Erstladen in V1 angelegt oder geändert wurden. Genau das brauchen Sie für die Lücke zwischen letztem Test und Cutover. Testen Sie, wie Ihr Szenario mit in V1 gelöschten Datensätzen umgeht, und planen Sie nach dem Cutover eine Bereinigung ein.

Kann ich filtern, welche Datensätze das DTT überträgt?

Nicht so, wie die meisten Teams es erwarten. Das DTT überträgt die Daten eines Objekts und nicht eine gefilterte Teilmenge. Was nicht in V2 landen soll, muss vor der Übertragung in V1 bereinigt oder archiviert werden.

Funktioniert das DTT auch für die Migration von Service Cloud V1 auf V2?

Ja. Die Transition-Werkzeuge decken Sales Cloud und Service Cloud ab, auch Tickets. Einige Service-Konfigurationen, etwa Case-Typen, legen Sie zuerst manuell in V2 an. Der Ablauf ist derselbe: Readiness Check, Vorbereitung, Testübertragungen, Cutover.

Kann ich mit dem DTT von einem Fremd-CRM auf V2 migrieren?

Nein. Das DTT ist nur für V1 zu V2 gedacht. Aus Salesforce, Dynamics 365 oder anderen Systemen laden Sie Daten über die Data Workbench von V2 (CSV- oder Excel-Import) oder über die V2-APIs, bei grösseren Mengen meist über SAP Integration Suite. Für Vertriebsteams, die mit Tabellen arbeiten, beschreibt unser Leitfaden für den Umstieg von Excel auf Sales Cloud V2 den einfacheren Weg.

Wie gehe ich mit eigenen Objekten mit komplexen Beziehungen um?

Eigene Felder auf Standardobjekten wandern mit dem DTT, sobald sie zugeordnet sind, und PDI-Felddaten werden unterstützt. Eigene Business-Objekte mit eigener Logik, eigenen Beziehungen und eigener Oberfläche werden in V2 oder auf SAP BTP neu gebaut. Ihre Daten exportieren Sie über die OData-API aus V1 und laden sie über die APIs in V2. Das ist Projektarbeit, keine DTT-Arbeit.

Was passiert nach der Migration mit meinem V1-System?

Das DTT liest aus V1 und verändert die Quelldaten nicht. V1 läuft weiter, bis Sie es stilllegen. Legen Sie fest, wie lange Anwender und Revision Lesezugriff brauchen, und planen Sie das Ende des V1-Abonnements als eigenen Schritt.

Gibt es eine maximale Datenmenge für das DTT?

Uns ist keine veröffentlichte harte Grenze bekannt. Die Menge bestimmt die Laufzeit. Nutzen Sie deshalb den Readiness Check, um Datensätze und Anhangsvolumen pro Objekt zu sehen, testen Sie mit produktiven Mengen und planen Sie das Cutover-Fenster nach den gemessenen Laufzeiten.

---

Eine Migration von V1 auf V2 ist ein Projekt mit einem Datenstrang, keine Datenübertragung mit ein paar Nebenaufgaben. Das DTT macht den Datenteil beherrschbar. Der Rest hängt an der Vorbereitung: saubere Daten, vollständige Zuordnungen, echte Testläufe und ein Plan, der den Neuaufbau ehrlich abbildet.

Wenn Sie eine DTT-Migration planen und eine zweite Meinung zu Ihrem Readiness-Bericht möchten, nehmen Sie Kontakt mit uns auf. Wir gehen ihn gern mit Ihnen durch.