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

SAP’s Data Transfer Tool löst ein konkretes Problem: die Migration Ihrer Produktionsdaten von Sales Cloud V1 (C4C) auf Sales Cloud V2. Es ist der offizielle, von SAP unterstützte Migrationspfad. Und es funktioniert. Aber die Dokumentation liest sich, als wäre sie für Personen geschrieben worden, die das Tool bereits kennen.

Wir haben DTT-Migrationen für mehrere Kunden durchgeführt — von 50-Benutzer-Vertriebsteams bis zu Deployments mit über 500 Benutzern, komplexen Custom Objects und tiefen S/4HANA-Integrationen. Diese Anleitung behandelt, was die offizielle Dokumentation auslässt: die praktischen Entscheidungen, die Fehler, auf die Sie stossen, die Validierungsschritte, die Sie vor einem gescheiterten Go-Live bewahren, und realistische Zeitpläne basierend auf tatsächlichen Projektdaten.

TL;DR: SAP’s Data Transfer Tool (DTT) migriert Stamm- und Bewegungsdaten von Sales/Service Cloud V1 auf V2. Führen Sie zuerst das Readiness Check Tool (RCT) aus — es identifiziert Blocker, bevor Sie anfangen. DTT überträgt Konten, Kontakte, Leads, Opportunities, Aktivitäten und Tickets automatisch; Custom Objects, Integrationen und Workflow-Logik müssen manuell neu aufgebaut werden. Eine typische Mittelstandsmigration (100-200 Benutzer, 500K-2M Datensätze) dauert 8-14 Wochen insgesamt. Führen Sie immer mindestens zwei vollständige Testmigrationen durch, bevor Sie produktiv migrieren. SAP hat das DTT in den Releases 2508 und 2511 erheblich verbessert (SAP Community, 2025).

Was ist das Data Transfer Tool (DTT)?

Das Data Transfer Tool ist SAP’s integriertes Werkzeug zur Übertragung von Geschäftsdaten von einem V1-Tenant (C4C) auf einen V2-Tenant. Es ist kein Drittanbieter-Add-on. Es ist in die V2-Administrationskonsole eingebettet, und SAP hat es entwickelt, um die strukturellen Unterschiede zwischen den beiden Datenmodellen zu bewältigen.

SAP führte das DTT parallel zur allgemeinen V2-Verfügbarkeit ein und verbesserte es dann erheblich im Release 2508 (August 2025) und erneut in 2511 (November 2025). Das 2508-Release fügte Unterstützung für Custom Business Objects und verbessertes Error Handling hinzu. Das 2511-Release erweiterte die Abdeckung auf E-Mail-Aktivitäten, Notizen mit Anhängen und eine bessere Handhabung von Cross-Object-Referenzen (SAP Community, 2025).

Was DTT überträgt:

• Konten (Unternehmens- und Einzelkundenkonten)
• Kontakte und deren Kontobeziehungen
• Leads und Lead-Qualifizierungen
• Opportunities mit Produkten, Verkaufsphasen und beteiligten Parteien
• Aktivitäten (Termine, Aufgaben, Telefonate, E-Mails)
• Service-Tickets und Interaktionen
• Produkte und Preislisten
• Vertriebsgebiete und organisatorische Zuordnungen
• Benutzerdefinierte Felder auf Standardobjekten
• Anhänge und Dokumente (mit Grössenlimits)

Was DTT nicht überträgt:

• Benutzerdefinierte Code-Logik (ABSL-Skripte, Custom Actions)
• Workflow-Regeln und Eskalationskonfigurationen
• Integrationskonfigurationen (Communication Arrangements, APIs)
• UI-Anpassungen (Mashups, eingebettete Inhalte, Custom UIs)
• Berichte und Analytics-Konfigurationen
• Benutzereinstellungen und Personalisierung
• E-Mail-Vorlagen und Seriendruckfelder

Die Unterscheidung ist entscheidend. DTT überträgt die Daten. Alles andere — die Geschäftslogik, die Integrationen, die Benutzeroberfläche — muss in V2’s Architektur neu aufgebaut werden. Für einen umfassenderen Blick auf das Gesamtprojekt lesen Sie unsere C4C-zu-V2-Migrationsstrategie.

Voraussetzungen: Was vor dem Start erledigt sein muss

Bevor Sie das DTT anfassen, müssen mehrere Dinge in Ordnung sein. Jeder übersprungene Punkt erzeugt Probleme, deren Behebung mehr Zeit kostet als die Vorbereitung.

Systemanforderungen

• V2-Tenant provisioniert und aktiviert. Ihre V2-Umgebung muss live und zugänglich sein. Klingt selbstverständlich, aber die Tenant-Provisionierung kann über SAP’s Prozess 2-4 Wochen dauern. Frühzeitig starten.
• V1-Tenant auf unterstütztem Release-Stand. DTT erfordert, dass Ihr V1-System auf einem Mindest-Patchlevel ist. Prüfen Sie SAP Note 3350732 für das aktuelle Minimum. Falls Sie dahinter liegen, patchen Sie zuerst.
• Admin-Zugang zu beiden Tenants. Der Benutzer, der DTT ausführt, braucht volle Administratorrechte in Quell- (V1) und Ziel- (V2) System. Eingeschränkter Zugang führt zu stillen Fehlern.
• Netzwerkkonnektivität. Beide Systeme müssen kommunizieren können. Falls Ihr V1-Tenant IP-Whitelisting oder Custom-Proxy-Konfigurationen nutzt, stellen Sie sicher, dass die IP-Bereiche des V2-Tenants zugelassen sind.

Readiness Check Tool zuerst ausführen

Das Readiness Check Tool (RCT) ist vom DTT getrennt, aber vom Prozess untrennbar. RCT analysiert Ihr V1-System und erstellt einen Kompatibilitätsbericht: welche Objekte bereit für den Transfer sind, welche Aufmerksamkeit brauchen und welche inkompatibel sind.

Wir betrachten das RCT als unverzichtbar. Jede DTT-Migration, die wir durchgeführt haben, beginnt mit dem Readiness Check. Er fängt Probleme ab, die sonst erst mitten in der Migration auftauchen würden.

Datenbereinigung in V1

Ihre V1-Daten haben über Jahre Inkonsistenzen angesammelt. DTT wird diese Inkonsistenzen treu nach V2 übertragen, wenn Sie nicht vorher aufräumen.

• Doppelte Konten und Kontakte. Zusammenführen oder markieren Sie Duplikate vor der Migration. V2’s Deduplizierungsfähigkeiten sind besser, aber 3’000 Duplikate zu migrieren und dann zu bereinigen, ist Verschwendung.
• Verwaiste Datensätze. Kontakte ohne Konten, Aktivitäten ohne übergeordnete Datensätze, Opportunities mit gelöschten Produktverknüpfungen. Finden. Beheben oder entfernen.
• Custom Objects ohne Daten. Wenn ein Custom Object seit zwei Jahren leer ist, muss es nicht migriert werden. Jedes Objekt im Migrationsumfang erhöht die Komplexität.
• Inaktive Benutzer. Überprüfen Sie Ihre Benutzerbasis. Migrieren Sie nur aktive Benutzer. Weisen Sie Datensätze von ausgeschiedenen Mitarbeitenden vor der Migration neu zu, nicht danach.

Gartner schätzt, dass mangelhafte Datenqualität Organisationen durchschnittlich 12,9 Millionen Dollar pro Jahr kostet (Gartner, 2021). Die Datenbereinigung vor der Migration ist eine Investition, keine Kosten.

Schritt 1: Readiness Check durchführen

Greifen Sie auf das Readiness Check Tool innerhalb Ihrer V1-Administrationskonsole unter Administrator > Datentransfer > Readiness Check zu. Bei einigen V1-Versionen finden Sie es unter Migrationswerkzeuge.

Was der RCT-Bericht aussagt

Der Bericht bewertet Ihr System in drei Dimensionen:

Objektkompatibilität. Jedes Business Object erhält einen Status: Bereit (grün), Handlungsbedarf (gelb) oder Inkompatibel (rot). Bereite Objekte können direkt übertragen werden. «Handlungsbedarf»-Objekte haben kleinere Probleme — meist Lücken im Feldmapping oder Datenformatunterschiede. Inkompatible Objekte erfordern manuelle Bearbeitung.

Datenqualitäts-Score. Der Bericht markiert Datenqualitätsprobleme: fehlende Pflichtfelder, defekte Referenzen, verwaiste Datensätze und Datensätze, die V2-Feldlängenlimits überschreiten. Ein Score unter 70 % bedeutet: Bereinigung vor dem Fortfahren nötig.

Custom-Object-Bewertung. Benutzerdefinierte Business Objects werden auf V2-Kompatibilität geprüft. Einfache Erweiterungen (benutzerdefinierte Felder auf Standardobjekten) übertragen sich meist sauber. Komplexe Custom Objects mit ABSL-Logik werden für den manuellen Neuaufbau markiert.

Wie die Ergebnisse zu interpretieren sind

Ein perfekter Score ist selten und nicht nötig. Entscheidend ist: null rote Einträge und ein Aktionsplan für jeden gelben Eintrag. Aus unserer Erfahrung zeigt ein typisches V1-System:

• 60-70 % der Objekte in Grün (bereit)
• 25-35 % in Gelb (kleinere Anpassungen nötig)
• 5-10 % in Rot (manueller Neuaufbau nötig)

Die roten Einträge betreffen fast immer benutzerdefinierte Code-Logik und komplexe Integrationen — Dinge, für deren Übertragung DTT nie konzipiert war. Das ist erwartet, nicht beunruhigend.

Dokumentieren Sie die RCT-Ergebnisse. Sie bilden das Fundament Ihres Migrationsplans. Jeder gelbe und rote Eintrag braucht einen Verantwortlichen und ein Lösungsdatum.

Schritt 2: V2-Umgebung vorbereiten

Ihr V2-Tenant muss konfiguriert sein, bevor er Daten empfängt. DTT überträgt Datensätze, aber es erstellt nicht die Geschäftskonfiguration, um sie aufzunehmen.

Tenant-Einrichtung

• Organisationsstruktur. Bilden Sie Ihre Org-Struktur in V2 nach: Vertriebsorganisationen, Gebiete, Sparten. V2 verwendet ein anderes Zuordnungsmodell, also ist das keine Kopie — es ist ein Redesign.
• Benutzerbereitstellung. Erstellen Sie Benutzerkonten in V2 mit den entsprechenden Rollen. Ordnen Sie V1-Benutzer-IDs den V2-Benutzer-IDs zu — DTT nutzt dieses Mapping für die Neuzuordnung der Datensatzverantwortung.
• Geschäftskonfiguration. Richten Sie Lifecycle-Status, Begründungscodes, Verkaufsphasen, Produktkategorien und andere Konfigurationsdaten ein. Diese müssen in V2 existieren, bevor Daten ankommen.

Benutzerdefinierte Felder mappen

V1-Custom-Fields brauchen ein explizites Mapping auf V2-Erweiterungsfelder. Hier entsteht der grösste Konfigurationsaufwand.

In V2 werden benutzerdefinierte Felder über das Key User Extensibility-Framework erstellt. Feldtypen, Längen und Wertelisten können sich von V1 unterscheiden. Für jedes Custom Field in Ihrem Migrationsumfang:

1. Erstellen Sie das entsprechende Erweiterungsfeld in V2
2. Prüfen Sie, ob der Datentyp übereinstimmt (Text, Zahl, Datum, Codeliste)
3. Bei Codelistenfeldern: Stellen Sie sicher, dass alle V1-Werte in der V2-Werteliste vorhanden sind
4. Dokumentieren Sie das Mapping von V1-Feld-ID zu V2-Feld-ID

Dieses Mapping-Dokument ist unverzichtbar. DTT nutzt es während des Datentransfers für die korrekte Weiterleitung der Feldwerte. Fehler hier sind die häufigste Ursache für Migrationsausfälle.

Für Details zu den Funktionen von SAP Sales Cloud V2 und wie V2’s Erweiterbarkeit aussieht, lesen Sie unsere Lösungsübersicht.

Schritt 3: DTT konfigurieren

Mit der vorbereiteten V2-Umgebung öffnen Sie das Data Transfer Tool in der V2-Administrationskonsole: Einstellungen > Migration > Data Transfer Tool.

Objektauswahl

DTT zeigt eine Liste übertragbarer Objekte. Wählen Sie aus, welche Objekte in die Migration einbezogen werden sollen. Unsere Empfehlung: Beginnen Sie mit Stammdaten, dann Bewegungsdaten.

Die Migrationsreihenfolge ist wichtig. Objekte mit Abhängigkeiten müssen sequenziell übertragen werden:

1. Produkte und Preislisten — referenziert von Opportunities und Angeboten
2. Konten (Unternehmenskonten zuerst, dann Einzelkunden)
3. Kontakte — verknüpft mit Konten
4. Leads — referenzieren Kontakte und Konten
5. Opportunities — referenzieren Konten, Kontakte, Produkte
6. Aktivitäten — referenzieren alle oben genannten
7. Service-Tickets — referenzieren Konten, Kontakte, Produkte

DTT handhabt diese Sequenzierung automatisch, wenn Sie alle Objekte gleichzeitig auswählen. Aber das Verständnis der Reihenfolge hilft beim Debugging: Wenn Opportunities fehlschlagen, liegt es oft daran, dass eine Kontoreferenz in einem früheren Batch nicht übertragen wurde.

Feldmapping

DTT mappt Standardfelder zwischen V1 und V2 automatisch. Für benutzerdefinierte Felder konfigurieren Sie das Mapping manuell anhand des Mapping-Dokuments aus Schritt 2.

Die Feldmapping-Oberfläche zeigt:

• Quellfeld (V1): Feldname, Datentyp, Beispielwerte
• Zielfeld (V2): gematchtes Feld oder «Nicht zugeordnet»
• Transformationsregeln: optionale Wertkonvertierung (z. B. V1-Code «A001» wird zu V2-Code «ACTIVE»)

Prüfen Sie jedes Mapping. Auto-gemappte Felder sind meist korrekt, aber wir haben Fälle gesehen, in denen ähnlich benannte Felder in V1 und V2 unterschiedliche Semantik hatten. Ein Feld namens «Kategorie» in V1 könnte auf «Klassifizierung» in V2 mappen — gleiches Konzept, anderes Feld.

Transformationsregeln

Für Felder, bei denen V1 und V2 unterschiedliche Wertelisten verwenden, definieren Sie Transformationsregeln:

• Codelisten-Mappings. V1-Status «In Bearbeitung» wird zu V2-Status «In Arbeit». Definieren Sie jedes Wertepaar.
• Feldverkettung. V1 teilt Adressen eventuell in Strasse1 + Strasse2 auf. V2 kombiniert sie möglicherweise anders.
• Standardwerte. V2 kann neue Pflichtfelder haben, die in V1 nicht existieren. Setzen Sie Standardwerte, um Null-Fehler zu vermeiden.
• Datumsformat-Handling. Selten ein Problem bei SAP-zu-SAP-Transfers, aber prüfen Sie die Zeitzonenbehandlung, wenn Ihre V1- und V2-Tenants in unterschiedlichen Regionen liegen.

Schritt 4: Testmigration durchführen

Führen Sie DTT nie gegen Produktionsdaten aus, ohne mindestens eine — besser zwei — vollständige Testmigrationen. Das ist nicht verhandelbar.

Vorgehensweise

1. Erstellen Sie einen Test-V2-Tenant oder nutzen Sie die Qualitäts-/Staging-Umgebung. Testen Sie nie gegen die produktive V2-Instanz.
2. Führen Sie DTT mit vollem Umfang aus. Alle Objekte, alle Custom Fields, alle Transformationsregeln einbeziehen. Ein Teiltest validiert keine Cross-Object-Referenzen.
3. Nutzen Sie produktionsnahe Datenmengen. Wenn die Produktion 1 Million Datensätze hat, testen Sie nicht mit 10’000. Datenvolumen erzeugt andere Fehlermodi: Timeout-Fehler, Speicherlimits und Performance-Engpässe, die nur bei voller Skalierung auftreten.
4. Messen Sie die Ausführungszeit. Erfassen Sie, wie lange jeder Objekttyp braucht. Diese Daten bestimmen Ihr produktives Cutover-Fenster.

Validierungsprüfungen nach der Testmigration

Nach Abschluss des Testlaufs:

Datensatzzählung vergleichen. Vergleichen Sie die Quell- und Zielzählung für jeden Objekttyp. Abweichungen deuten auf fehlgeschlagene Datensätze hin.

Beziehungsintegrität prüfen. Prüfen Sie stichprobenartig 50-100 Datensätze über Objekttypen hinweg. Verifizieren Sie:

• Kontakte sind dem richtigen Konto zugeordnet
• Opportunities zeigen die korrekten Produkte und Verkaufsphasen
• Aktivitäten sind den richtigen übergeordneten Datensätzen zugewiesen
• Benutzerdefinierte Feldwerte wurden korrekt übertragen

Fehlerprotokoll prüfen. DTT erzeugt ein detailliertes Fehlerprotokoll. Jeder Fehler muss klassifiziert werden: kritisch (blockiert Migration), schwerwiegend (Datenverlust) oder geringfügig (kosmetisch). Kritische und schwerwiegende Fehler müssen vor dem Produktionslauf behoben werden.

Häufige Testmigrationsfehler und Lösungen

Feldlängen-Abweichung. Ein V1-Textfeld erlaubt 255 Zeichen; das V2-Pendant nur 100. Datensätze mit Werten über dem V2-Limit scheitern. Lösung: V2-Feldlänge erhöhen oder Transformationsregel zum Kürzen hinzufügen.

Lookup-Fehler. Eine V1-Opportunity referenziert eine Konto-ID, die in V2 nicht existiert. Das passiert, wenn Kontodatensätze in einem früheren Batch still fehlschlagen. Lösung: Ursache beheben (meist ein Datenqualitätsproblem in V1) und erneut ausführen.

Duplikat-Schlüsselverletzungen. V2 hat strengere Eindeutigkeitsregeln als V1. Wenn V1 doppelte externe IDs erlaubte, lehnt V2 den zweiten Datensatz ab. Lösung: Duplikate in V1 vor der Migration bereinigen.

Pflichtfeld-Nullwerte. V2 führt neue Pflichtfelder ein, die in V1 nicht existieren. Datensätze ohne Werte scheitern. Lösung: Standardwerte in den Transformationsregeln hinterlegen.

Führen Sie die Testmigration durch, beheben Sie alle Fehler und führen Sie sie erneut aus. Wir machen typischerweise 2-3 Testzyklen vor dem Produktionslauf. Jeder Zyklus sollte weniger Fehler ergeben. Wenn die Fehlerzahlen nicht sinken, stimmt etwas Grundlegendes nicht.

Schritt 5: Produktionsmigration durchführen

Die Produktionsmigration ist der Höhepunkt. Zu diesem Zeitpunkt haben Sie den Prozess bereits durch Testläufe bewiesen. Die Produktionsdurchführung sollte vorhersehbar sein.

Timing-Überlegungen

Wochenende oder verkehrsarmes Fenster. DTT belastet sowohl V1- als auch V2-Systeme. Führen Sie die Migration ausserhalb der Geschäftszeiten durch, um Auswirkungen auf aktive Benutzer zu minimieren. Für europäische Unternehmen ist Freitag Abend bis Sonntag Morgen das Standardfenster.

Einfrierphase. Erklären Sie einen Datenstopp für das V1-System vor dem Start. Keine neuen Datensätze, keine Aktualisierungen. Änderungen in V1 nach dem DTT-Snapshot gehen verloren. Kommunizieren Sie das mindestens eine Woche im Voraus an alle Benutzer.

Dauerplanung. Nutzen Sie Ihre Testmigrations-Zeiten, plus 20-30 % Puffer. Wenn der Test 8 Stunden dauerte, planen Sie 10-12 Stunden für die Produktion. Netzwerkvariabilität, grössere Datensatzmengen und parallele Systemlast kosten zusätzliche Zeit.

Fortschritt überwachen

DTT bietet ein Fortschritts-Dashboard mit:

• Aktuelle Phase (welcher Objekttyp wird übertragen)
• Verarbeitete Datensätze vs. Gesamtzahl
• Fehlerzähler (laufende Summe)
• Geschätzte Restzeit

Weisen Sie jemanden zur kontinuierlichen Überwachung zu. Wenn die Fehlerrate bei einem Objekttyp über 2 % steigt, pausieren und untersuchen. Ein Problem während der Migration zu beheben ist einfacher als nach einem abgeschlossenen, aber fehlerhaften Lauf aufzuräumen.

Checkpoint-Strategie

Für grosse Migrationen (1M+ Datensätze) empfehlen wir einen phasenweisen Ansatz:

1. Phase A: Stammdaten — Konten, Kontakte, Produkte. Validieren vor dem Fortfahren.
2. Phase B: Opportunities und Leads — setzt saubere Stammdaten voraus.
3. Phase C: Aktivitäten und Tickets — höchstes Volumen, geringstes Risiko bei soliden Stammdaten.
4. Phase D: Anhänge und Dokumente — langsamster Transfer, netzwerkintensiv.

Jede Phase hat einen Checkpoint. Zählungen und Beziehungen validieren, bevor die nächste Phase beginnt. Wenn Phase B scheitert, setzen Sie Phase B zurück, ohne Phase A’s erfolgreichen Transfer zu verlieren.

Rollback-Strategie

DTT hat keinen Ein-Klick-Rollback. Wenn die Migration katastrophal scheitert:

• V1 bleibt intakt. DTT liest aus V1; es modifiziert die Quelle nicht. Ihr V1-System bleibt voll funktionsfähig.
• V2 kann zurückgesetzt werden. Für einen Neustart kann SAP den V2-Tenant auf den Ausgangszustand zurücksetzen. Das erfordert ein Support-Ticket und dauert 24-48 Stunden.
• Partieller Rollback. Wenn nur bestimmte Objekttypen fehlschlugen, können Sie die fehlgeschlagenen Datensätze in V2 löschen und DTT nur für diese Objekte erneut ausführen.

Der sicherste Ansatz: V1 voll betriebsbereit halten, bis V2 validiert ist und die Benutzer die Migration als abgeschlossen bestätigt haben. Wir empfehlen einen Parallelbetrieb von mindestens 2 Wochen.

Schritt 6: Post-Migrations-Validierung

Die Migration ist mechanisch abgeschlossen. Jetzt wird sie bewiesen.

Datensatzzählung

Führen Sie einen vollständigen Zählvergleich über alle migrierten Objekttypen durch. Das ist derselbe Check wie beim Testen, aber gegen Produktionsdaten. Was im Test bestanden hat, sollte auch in der Produktion bestehen. Neue Abweichungen weisen auf Daten hin, die zwischen Testlauf und Produktionsstillstand erstellt wurden.

Beziehungsintegritätsprüfungen

Tiefer als reines Zählen. Validieren Sie, dass Geschäftsbeziehungen den Transfer überstanden haben:

• Kontohierarchien. Eltern-Kind-Kontostrukturen sind intakt.
• Kontakt-zu-Konto-Zuordnungen. Keine verwaisten Kontakte.
• Opportunity-Pipeline. Verkaufsphasen, erwarteter Umsatz, Abschlussdaten und Produktzeilenposten sind korrekt.
• Aktivitäts-Zeitstrahl. Kürzliche Aktivitäten erscheinen in der richtigen chronologischen Reihenfolge bei den richtigen Datensätzen.
• Benutzerdefinierte Feldwerte. Stichprobenartig 100+ Datensätze pro Custom Field prüfen, ob Transformationsregeln funktioniert haben.

Benutzerakzeptanztest-Checkliste

Bevor Sie Erfolg erklären, lassen Sie Fachbenutzer ihre eigenen Daten validieren:

• Vertriebsleiter: Pipeline-Ansicht öffnen, Opportunity-Anzahl und -Werte auf Übereinstimmung prüfen
• Account Executives: Top-10-Konten auf Vollständigkeit prüfen
• Service-Mitarbeitende: aktuelle Tickethistorie und Kundeninteraktionsprotokolle verifizieren
• Admins: Gebietszuordnungen und Benutzerrollenmappings bestätigen
• Reporting: Standardberichte ausführen und Gesamtzahlen mit V1-Baselines vergleichen

UAT dauert typischerweise 3-5 Werktage. Nicht hetzen. Ein Benutzer, der drei Monate später fehlende Daten entdeckt, stört den Betrieb weit mehr als eine zusätzliche Validierungswoche jetzt.

Was das DTT nicht überträgt

Dieser Abschnitt ist entscheidend. Das Verständnis dessen, was DTT zurücklässt, bestimmt den Rest Ihres Migrationsprojektumfangs und -budgets.

Benutzerdefinierte Code-Logik. V1 verwendet ABSL (ABAP Scripting Language) für benutzerdefinierte Geschäftslogik. V2 unterstützt ABSL nicht. Alle Custom Logic muss neu implementiert werden — entweder als V2-Key-User-Konfigurationen oder als BTP-basierte Erweiterungen. Dies ist typischerweise der grösste manuelle Aufwand in der Migration.

Workflow-Regeln. V1-Workflows werden nicht übertragen. Bauen Sie sie in V2’s Rule Engine neu auf. Die gute Nachricht: V2’s Rule Engine ist leistungsfähiger. Viele V1-Workflows, die Custom Code erforderten, können in V2 mit Konfiguration umgesetzt werden.

Integrationskonfigurationen. Communication Arrangements, API-Endpunkte, Middleware-Verbindungen und SSO-Konfigurationen sind tenant-spezifisch. Jede Integration muss in V2 neu aufgesetzt werden. Wenn Ihr V1-System mit S/4HANA, Marketing-Tools oder Drittanbieterdiensten integriert ist, planen Sie einen vollständigen Integrationsneubau. Lesen Sie unseren CTI-Integrationsleitfaden für eine Vorstellung davon, wie V2-Integrationen in der Praxis aussehen.

UI-Anpassungen. Mashups, eingebettete HTML-Inhalte, Custom-Navigationseinträge und Side Panels müssen in V2’s UI-Framework neu aufgebaut werden. V2 verwendet ein anderes Side-by-Side-Erweiterungsmodell via SAP Build Work Zone.

Berichte und Dashboards. V1-Berichte werden nicht übertragen. Bauen Sie sie mit V2’s integrierten Analytics oder SAP Analytics Cloud neu auf. Die meisten Kunden stellen fest, dass V2’s natives Reporting 80 % dessen abdeckt, was sie in V1 manuell erstellt haben.

E-Mail-Vorlagen. E-Mail-Templates mit Seriendruckfeldern müssen in V2’s Template-Editor neu erstellt werden. Die Seriendruckfeld-Syntax ist unterschiedlich.

Budgetieren Sie das ein. Bei einem typischen DTT-Migrationsprojekt macht der Datentransfer selbst 20-30 % des Gesamtaufwands aus. Die verbleibenden 70-80 % entfallen auf den Neuaufbau der oben genannten Punkte. Für den Kostenkontext lesen Sie unseren SAP Sales Cloud V2 Preisleitfaden.

Häufige DTT-Fehler und ihre Behebung

Basierend auf unseren Migrationsprojekten sind dies die Fehler, auf die Sie am häufigsten stossen:

Führen Sie ein laufendes Fehlerprotokoll. Kategorisieren Sie Fehler nach Schweregrad und Häufigkeit. Manche Fehler (wie Anhang-Grössenlimits) betreffen wenige Datensätze und können individuell nach der Migration behandelt werden. Andere (wie «Referenz nicht gefunden») deuten auf systemische Probleme hin, die eine Ursachenanalyse erfordern.

Zeitplan: Wie lange dauert eine DTT-Migration?

Zeitpläne variieren je nach Datenvolumen, Anpassungskomplexität und Anzahl der Integrationen. Hier unsere Projekterfahrungen:

Nach Unternehmensgrösse

Diese Zeitpläne decken nur den Datenmigrations-Workstream ab. Das gesamte V1-zu-V2-Projekt — einschliesslich Integrations-Neuaufbau, Custom-Logic-Reimplementierung, Schulung und Go-Live — dauert länger. Für das Gesamtbild lesen Sie unseren V1-vs-V2-Migrationsvergleich.

Planungstabelle

Nutzen Sie dies als Ausgangsrahmen für Ihren Projektplan:

Addieren Sie auf jede Schätzung 20 %. Aus unserer Erfahrung sind die Phasen Datenbereinigung und Feldmapping am wahrscheinlichsten von Überziehungen betroffen. Niemand kennt den wahren Zustand seiner V1-Daten, bis er genau hinschaut.

FAQ

Unterstützt DTT Delta-Migration?

Ja, mit Einschränkungen. DTT kann inkrementell laufen, um Datensätze zu übertragen, die nach der initialen Migration erstellt oder geändert wurden. Das ist nützlich für den Zeitraum zwischen Testmigration und Produktions-Cutover. Allerdings behandelt die Delta-Migration keine Löschungen — Datensätze, die in V1 nach dem initialen Transfer gelöscht werden, bleiben in V2. Planen Sie einen Bereinigungsdurchlauf nach dem Cutover.

Kann ich DTT mehrmals ausführen?

Ja. DTT ist für iterative Ausführung konzipiert. Jeder Lauf kann auf bestimmte Objekttypen eingegrenzt oder nach Datumsbereich gefiltert werden. Folgeläufe überspringen bereits übertragene Datensätze (identifiziert durch eindeutige Schlüssel). So funktioniert der Test-und-Verfeinern-Zyklus.

Funktioniert DTT auch für die Service Cloud V1-zu-V2-Migration?

Ja. DTT deckt sowohl Sales-Cloud- als auch Service-Cloud-Objekte ab. Service-Tickets, Interaktionen, Knowledge-Artikel und SLA-Konfigurationen liegen im DTT-Umfang. Der Prozess ist identisch — zuerst RCT, dann DTT-Konfiguration, Testläufe und Produktionsmigration.

Was passiert mit meinem V1-System nach der Migration?

Nichts. V1 bleibt voll betriebsfähig. SAP empfiehlt, den V1-Zugang mindestens 90 Tage nach V2-Go-Live für Referenz- und Auditzwecke aufrechtzuerhalten. Irgendwann wird der V1-Tenant ausser Betrieb genommen, aber das ist ein separater Prozess nach Ihrem Zeitplan.

Kann ich mit DTT von einem Drittanbieter-CRM zu V2 migrieren?

Nein. DTT ist ausschliesslich für SAP V1-zu-V2-Migration. Bei einer Migration von Salesforce, Dynamics 365 oder einem anderen CRM nutzen Sie SAP’s Standard-Datenimport-APIs oder eine Middleware-Lösung. Wir haben eine separate Anleitung zur Excel-zu-V2-Migration für einfachere Szenarien veröffentlicht.

Wie gehe ich mit Custom Objects mit komplexen Beziehungen um?

Custom Objects mit einfachen Strukturen (benutzerdefinierte Felder auf Standardobjekten) übertragen sich via DTT. Komplexe Custom Business Objects mit Inter-Object-Beziehungen, ABSL-Logik oder Custom UIs brauchen einen manuellen Neuaufbau. Exportieren Sie die Daten aus V1 via OData, transformieren Sie sie und importieren Sie sie via V2’s APIs in V2. Das ist Projektarbeit, keine DTT-Arbeit.

Was, wenn mein V1-System stark angepasst ist?

Starke Anpassung bedeutet mehr manuellen Neuaufbau-Aufwand, disqualifiziert Sie aber nicht von der DTT-Nutzung. DTT übernimmt die Daten; Ihr Projektteam übernimmt die Logik. Der RCT-Bericht quantifiziert genau, wieviel Anpassung ausserhalb des DTT-Umfangs liegt. Nutzen Sie diesen Bericht für Scoping und Budgetierung der manuellen Workstreams.

Gibt es ein maximales Datenvolumen für DTT?

SAP veröffentlicht kein festes Limit. Wir haben erfolgreich Tenants mit über 10M Datensätzen über alle Objekttypen migriert. Die Performance ist die praktische Begrenzung: Sehr grosse Datenmengen dauern länger und erfordern möglicherweise Anpassungen der Batchgrösse. Das 2511-Release hat die DTT-Performance für Hochvolumen-Szenarien deutlich verbessert.

Die Migration von V1 auf V2 ist für Organisationen im SAP-CRM-Ökosystem keine Option, sondern Notwendigkeit. Das Data Transfer Tool macht den Datenteil handhabbar. Was eine reibungslose Migration von einer schmerzhaften unterscheidet, ist die Vorbereitung: saubere Daten, vollständiges Feldmapping, gründliches Testen und realistische Zeitpläne.

Wenn Sie eine DTT-Migration planen und eine zweite Meinung zu Ihrer Bereitschaft wünschen, nehmen Sie Kontakt auf. Wir haben das oft genug gemacht, um zu wissen, wo die Probleme versteckt liegen.