Migration mit einem Shadow-Import testen

Von Victor Hoang · Aktualisiert am 23. März 2026

Ein Shadow-Import ist der Unterschied zwischen „wir haben 3 Zuordnungsfehler in der Sandbox gefunden" und „wir haben 3 Zuordnungsfehler am Umstellungstag gefunden, während 30 Vertriebsmitarbeiter warten". Die Forschung von Gartner zum IT-Projektrisiko zeigt durchgängig, dass die Testphasen der am häufigsten zusammengestrichene Teil von Migrationsprojekten sind, und dieses Zusammenstreichen ist die Hauptursache für Rollbacks. Ein korrekter Durchlauf dauert 2–3 Stunden. Er verhindert genau die Probleme, die den Go-live um eine Woche verzögern.

Ein Migrationsteam übersprang den Shadow-Import, weil es bereits in einer Tabelle getestet hatte. Es prüfte in Excel, dass die Feldzuordnung korrekt aussah, bestätigte, dass die Picklist-Werte zusammenpassten, und fühlte sich sicher. Am Umstellungstag stellte es fest, dass sich die Beziehungsfelder zwischen Kontakten und Deals nicht auflösten: Das Importwerkzeug behandelte Verknüpfungs-Lookups anders, als der Tabellenvergleich nahegelegt hatte. Jeder Deal im System war von seinen Kontakten abgekoppelt. Die Umstellung wurde um fünf Tage verschoben, während das Team die Verknüpfungen manuell auflöste. Diese Art von Beziehungsfehler ist schwerer zu erkennen, wenn Sie das Design des CRM-Datenmodells des Zielsystems vor dem Test nicht durchdacht haben. Und sie ist fast immer vermeidbar, wenn das Dokument zur Feldzuordnung vor Beginn des Testlaufs vollständig ist.

Ein Shadow-Import in einer echten Sandbox hätte das in den ersten 10 Minuten aufgedeckt.

Dieser Leitfaden führt Sie durch den kompletten Shadow-Import-Prozess: Einrichtung, Auswahl des Testdatensatzes, den Importlauf selbst, die QA-Verifizierung und die Freigabekriterien, die Sie für die Umstellung freigeben.

Schritt 1: Eine Sandbox oder Testumgebung einrichten

Sie brauchen eine echte Instanz des Ziel-CRM, keinen Tabellenvergleich und keine visuelle Gegenüberstellung. Ziel ist es, Ihr tatsächliches Import-Tooling gegen eine tatsächliche CRM-Umgebung laufen zu lassen und zu sehen, was passiert.

HubSpot: Sandbox-Accounts von HubSpot gibt es in den Tarifen Professional und Enterprise. Gehen Sie zu Settings > Account Management > Sandboxes. Legen Sie eine Sandbox an und konfigurieren Sie dieselben benutzerdefinierten Properties, Pipeline-Stufen und Definitionen der Lifecycle-Stufen wie in Ihrem Produktiv-Account. Die Sandbox sollte das Produktiv-Setup abbilden, sonst testen Sie gegen eine andere Konfiguration als die, die Sie am Umstellungstag nutzen. Die HubSpot-Dokumentation zur Sandbox beschreibt, was automatisch aus der Produktivumgebung synchronisiert wird und was Sie manuell konfigurieren müssen.

Salesforce: Salesforce kennt mehrere Sandbox-Typen. Für Migrationstests genügt eine Developer-Sandbox: Sie hat dieselbe Konfiguration (Objekte, Felder, Picklist-Werte) wie die Produktivumgebung. Full Sandboxes enthalten Produktivdaten, sind aber langsamer bereitzustellen und für Migrationstests meist unnötig. Setup > Environments > Sandboxes > New Sandbox.

Pipedrive: Pipedrive hat keine native Sandbox. Legen Sie unter einer anderen E-Mail-Adresse einen kostenlosen Testaccount an. Konfigurieren Sie ihn passend zu Ihren produktiven Pipeline-Stufen und benutzerdefinierten Feldern. Die Grenzen des kostenlosen Tarifs genügen für Tests mit 500–1.000 Datensätzen.

Zoho CRM: Zoho bietet eine Sandbox-Umgebung unter Setup > Developer Space > Sandbox. Die Konfiguration bildet Ihre Produktivinstanz ab.

Wenn keine Sandbox verfügbar ist:

• Legen Sie einen neuen Produktiv-Account mit einem Test-Unternehmensnamen und einer eigenen Admin-E-Mail-Adresse an
• Verwenden Sie für alle Testdatensätze einen eindeutig beschrifteten Import-Tag („TEST IMPORT - DELETE")
• Löschen Sie nach dem Testen vor der Umstellung alle Datensätze mit diesem Tag

Die Sandbox muss Folgendes enthalten:

• Alle benutzerdefinierten Felder angelegt und konfiguriert (gleicher Typ, gleiche Picklist-Werte wie in der Produktivumgebung): Der Leitfaden zu benutzerdefinierten Feldern behandelt, welche Felder Sie anlegen und wie Sie sie einheitlich benennen
• Pipeline-Stufen und Lifecycle-Stufen, passend zu Ihrer Zielkonfiguration definiert
• Benutzerkonten eingerichtet, wenn Sie Felder zur Benutzerzuweisung testen
• Integrations-Webhooks deaktiviert: Sie wollen nicht, dass Testimporte echte Benachrichtigungen auslösen

Schritt 2: Einen repräsentativen Testdatensatz vorbereiten

Beim Testdatensatz bleiben die meisten Shadow-Importe hinter dem Nötigen zurück. Teams verwenden 50 saubere, gut formatierte Datensätze und schließen daraus, dass die Migration funktioniert. Dann enthält der vollständige Datenbestand 40 Datensätze mit Umlauten und Akzenten, 200 mit leeren Beziehungsfeldern und 15 mit Notizen, die HTML-Tags enthalten, und der vollständige Import bricht auf eine Weise, die der Test nicht vorhergesagt hat.

Zielgröße: 500–1.000 Datensätze. Das ist groß genug, um Randfälle aufzudecken, aber klein genug für manuelle QA. Die im Wikipedia-Artikel zu ETL beschriebenen Prinzipien für ETL-Tests empfehlen, dass Testdatensätze repräsentative Stichproben jedes Datenqualitätsmusters enthalten und nicht nur saubere Datensätze: Dieselbe Logik gilt hier. Falls Sie den Schritt der Datenbereinigung und Deduplizierung noch nicht durchgeführt haben, holen Sie das nach, bevor Sie Ihren Testdatensatz aufbauen. Saubere Daten zeigen Zuordnungsfehler klarer als schmutzige.

Auswahlkriterien für den Testdatensatz

Stellen Sie Ihren Datensatz so zusammen, dass er gezielt Problemdatensätze enthält und nicht nur saubere:

Exportieren Sie genau diese Auswahl. Nehmen Sie nicht einfach die ersten 500 Zeilen. Die ersten 500 Zeilen sind meist die zuletzt angelegten Datensätze, und die sind in der Regel sauberer als ältere. Sie wollen das Chaos in Ihrem Testdatensatz haben.

Schritt 3: Den Import mit exakt Ihrem Tooling ausführen

Das ist entscheidend: Verwenden Sie dasselbe Importwerkzeug, dieselbe Datei zur Feldzuordnung und dieselben Transformationsregeln wie am Umstellungstag. Nutzen Sie für den Testimport eine andere Methode, testen Sie einen anderen Prozess.

Gängige Importwerkzeuge nach Kombination aus Quelle und Ziel:

• HubSpot → anderes CRM: Nativer CSV-Export + CSV-Import des Ziel-CRM oder ein Migrationswerkzeug wie der native Import-Assistent von HubSpot für flache Objekte. Die Importdokumentation von HubSpot beschreibt das erforderliche Format der Spaltenüberschriften für jedes Objekt: Ihre Test-CSV muss dem exakt folgen, sonst überspringt der Import Zeilen still und leise.
• Salesforce → anderes CRM: Salesforce Data Loader (kostenlos, das eigene Werkzeug von Salesforce) für CSV-Exporte oder ein speziell dafür gebautes Migrationswerkzeug. Der Batch-Modus des Data Loader ist für Testläufe unverzichtbar: Er erzeugt ein Erfolgs- und Fehlerprotokoll pro Zeile, das die QA erheblich beschleunigt.
• Pipedrive → anderes CRM: Nativer CSV-Export + Import-Assistent des Ziels
• Beliebig → beliebig: Migrationswerkzeuge von Drittanbietern wie Trujay, Migrate.io oder Import2 lösen Beziehungen automatisch auf

Vor dem Lauf: Laden Sie Ihr Dokument zur Feldzuordnung und die Transformationsregeln. Sie sollten dem Dokument folgen und nicht improvisieren. Treffen Sie beim Testimport Entscheidungen spontan, ist das Dokument nicht fertig. Gehen Sie zurück und vervollständigen Sie es vor dem eigentlichen Lauf. Wenn Sie von HubSpot wechseln, behandelt der Wechsel von HubSpot zu Rework die Eigenheiten der Importreihenfolge, die speziell für dieses Quellsystem gelten.

Importreihenfolge (das ist wichtig):

1. Zuerst Unternehmen / Accounts
2. Danach Kontakte (damit sich Unternehmensverknüpfungen auflösen können)
3. Dann Deals / Opportunities (Kontaktverknüpfungen müssen existieren)
4. Zuletzt Aktivitäten (Deal- und Kontaktverknüpfungen müssen existieren)

Führen Sie den Import in dieser Reihenfolge auch für den Test aus. Abweichungen von der Reihenfolge gehören zu den häufigsten Ursachen defekter Beziehungsfelder.

Beobachten Sie das Importprotokoll in Echtzeit. Gehen Sie nicht weg und kommen später zurück. Das Protokoll zeigt Validierungsfehler bei Feldern, fehlgeschlagene Typkonvertierungen und übersprungene Datensätze. Notieren Sie jeden Fehler mit der Datensatz-ID und der Fehlermeldung: Sie brauchen diese Liste für den QA-Schritt.

Schritt 4: QA-Checkliste nach dem Import

Nehmen Sie nach Abschluss des Imports nicht an, dass er funktioniert hat, nur weil er ohne Fehler beendet wurde. Gehen Sie diese Checkliste systematisch durch.

QA-Checkliste nach dem Import

Prüfung der Datensatzanzahl:

• Die Gesamtzahl der importierten Kontakte entspricht der erwarteten Anzahl (Basiswert minus beabsichtigte Auslassungen)
• Die Gesamtzahl der importierten Unternehmen entspricht der erwarteten Anzahl
• Die Gesamtzahl der importierten Deals entspricht der erwarteten Anzahl
• Die Anzahl der Importfehler entspricht dem Fehlerprotokoll (keine stillen Auslassungen)

Korrektheit der Feldtypen:

• Datumsfelder werden als Datum angezeigt (nicht als Textzeichenketten, nicht als Unix-Zeitstempel)
• Zahlenfelder (Annual Revenue, Deal-Betrag) werden als Zahlen angezeigt, nicht als Text
• Währungsfelder werden im Zielsystem korrekt formatiert
• Telefonfelder werden in einem einheitlichen Format angezeigt
• Checkbox-Felder sind True/False (nicht „1"/„0" oder „Yes"/„No", sofern das nicht das Ziel ist)

Zuordnung der Picklist-Werte:

• Alle Werte der Lifecycle-Stufe werden auf gültige Zielwerte abgebildet (keine leeren Lifecycle-Stufen)
• Werte der Lead-Quelle werden korrekt abgebildet
• Werte der Deal-Stufe werden korrekt abgebildet
• Alle benutzerdefinierten Picklist-Felder werden korrekt abgebildet

Integrität der Beziehungen:

• Öffnen Sie 20 Kontaktdatensätze und prüfen Sie, ob die Unternehmensverknüpfung stimmt
• Öffnen Sie 10 Deal-Datensätze und prüfen Sie, ob die Kontaktverknüpfung stimmt
• Prüfen Sie, dass bei mindestens 3 Deal-Datensätzen der richtige Deal-Inhaber zugewiesen ist
• Prüfen Sie bei allen Datensätzen mit Mehrfachverknüpfung (Kontakte, die mit mehreren Deals verknüpft sind), dass alle Verknüpfungen vorhanden sind

Ergebnisse von Formeln und berechneten Feldern:

• Wenn das Ziel-CRM Felder berechnet (Tage seit der letzten Aktivität, Alter des Deals usw.), prüfen Sie 5 Datensätze stichprobenartig auf plausible Werte

Prüfung der Automatisierungs-Trigger:

• Prüfen Sie, dass Datensätze des Testimports keine Live-Workflows/Sequenzen ausgelöst haben (wichtig, wenn Sie in einer produktionsnahen Umgebung gearbeitet haben)

Protokollieren Sie jeden Fehler. Eine QA-Prüfung, die „größtenteils funktioniert", ist nicht bestanden: Jeder Fehler ist ein Mangel in Ihrem Dokument zur Feldzuordnung, der den vollständigen Import betreffen wird.

Schritt 5: Die drei meistgenutzten Berichte testen

Die Prüfung auf Feldebene findet Fehler in einzelnen Datensätzen. Die Prüfung von Berichten findet systemische Zuordnungsprobleme, die erst bei der Aggregation der Daten auftreten.

Bestimmen Sie Ihre drei meistgenutzten Berichte:

• Üblicherweise: Pipeline-Übersicht nach Stufe, Kontakte nach Lifecycle-Stufe und in diesem Monat angelegte Deals
• Fragen Sie Ihr Vertriebsteam, welche Berichte es täglich öffnet: Das sind die, die Sie verifizieren sollten. Der Artikel zum wöchentlichen Pipeline-Review beschreibt, auf welche Formate von Pipeline-Berichten sich Vertriebsteams am meisten verlassen, ein nützlicher Kontext für die Entscheidung, welche Berichte beim Testen am wichtigsten sind.

Für jeden Bericht gilt:

1. Führen Sie denselben Bericht im Quellsystem für Ihre Teststichprobe mit 500 Datensätzen aus
2. Führen Sie denselben Bericht (gefiltert auf importierte Datensätze) im Zielsystem aus
3. Vergleichen Sie die Zahlen

Die Anzahlen sollten übereinstimmen. Zeigt Ihr Quellsystem in der Teststichprobe 85 SQL-Kontakte und das Zielsystem 79, haben Sie einen Zuordnungsfehler bei der Lifecycle-Stufe, der 6 Datensätze betrifft. Finden Sie sie vor dem vollständigen Import.

Häufige Abweichungen auf Berichtsebene und ihre Ursachen:

• Abweichende Anzahl in einer Lifecycle-Stufe: Ein Picklist-Wert, der nicht korrekt abgebildet wurde
• Umsatzsummen stimmen nicht: Währungsfeld als Text importiert (wird nicht korrekt summiert)
• Datumsbasierte Filter liefern falsche Datensätze: Datumsformat falsch importiert; Datensätze werden dem falschen Zeitraum zugerechnet
• Berichte ohne Inhaber: Die Benutzerzuweisung wurde nicht aufgelöst

Schritt 6: Einen Vertriebsmitarbeiter fünf Datensätze durchgängig testen lassen

Technische QA findet technische Fehler. Vertriebsmitarbeiter finden Usability-Fehler: die Felder, die im Importprotokoll korrekt aussehen, sich aber falsch anfühlen, wenn man versucht, einen Deal zu bearbeiten.

Wählen Sie einen Mitarbeiter, der die Quelldaten gut kennt. Geben Sie ihm die Datensatz-IDs von fünf Kontakten und bitten Sie ihn:

1. den Datensatz im neuen System zu finden
2. zu prüfen, ob die Informationen stimmen: Unternehmen, Titel, Telefon, E-Mail, Lifecycle-Stufe
3. die Aktivitätshistorie dieser Kontakte zu prüfen
4. zugehörige Deals zu öffnen und die Deal-Informationen zu prüfen
5. alles zu melden, was falsch aussieht oder fehlt

Geben Sie ihm keine QA-Checkliste. Seine ungeführte Reaktion auf die Datenqualität ist wertvoller als eine strukturierte Prüfung. Das Feedback, das Sie wollen, lautet „das sieht richtig aus" oder „wo ist die Deal-Stufe, die ich benutzt habe?". Das ist das Signal, das Ihnen sagt, ob die Migration dem Team an Tag eins Probleme bereiten wird.

Schritt 7: Jeden Fehler dokumentieren und vor der Umstellung beheben

Nach der QA haben Sie eine Liste von Fehlern. Jeder Fehler hat eine von zwei Ursachen:

1. Einen Fehler im Dokument zur Feldzuordnung
2. Einen Randfall in den Daten, den das Zuordnungsdokument nicht berücksichtigt hat

Beide müssen vor der Umstellung im Zuordnungsdokument korrigiert werden. Beheben Sie Fehler nicht, indem Sie Datensätze im Zielsystem manuell bearbeiten: Das flickt 3 Datensätze und lässt die Ursache für die übrigen 47.000 bestehen.

Für jeden Fehler gilt:

• Ermitteln Sie die Ursache: falsche Transformationsregel, falsche Typbehandlung, falsche Picklist-Zuordnung
• Aktualisieren Sie das Zuordnungsdokument
• Lassen Sie die betroffenen Testdatensätze erneut durch den korrigierten Prozess laufen
• Prüfen Sie, dass das Ergebnis korrekt ist

Erfordert die Behebung eines Fehlers einen erneuten vollständigen Testimport, tun Sie es. Ja, das dauert weitere 2–3 Stunden. Aber am Umstellungstag zu entdecken, dass Ihre Korrektur einen Folgefehler eingeführt hat, ist schlimmer.

Führen Sie ein Protokoll aller gefundenen Fehler und ihrer Behebung. Dieses Protokoll wird Teil Ihrer Migrationsdokumentation und ist nützlich, wenn nach der Umstellung ein Problem auftaucht, das beim Testen nicht aufgefallen ist. Die Forschung der MIT Sloan zu Data Governance betont, dass die Dokumentation von Fehlern in Testphasen den Unterschied ausmacht zwischen Organisationen, die aus Migrationen lernen, und solchen, die bei der nächsten dieselben Fehler wiederholen.

Freigabe-Checkliste vor der Terminierung der Umstellung

Terminieren Sie die Umstellung erst, wenn jeder Punkt dieser Liste erledigt ist:

Datenverifizierung:

• Die Datensatzanzahl im Testimport entspricht der erwarteten Anzahl mit einer Abweichung von höchstens 0.5 %
• Null ungelöste Fehler bei Feldtypen im Importprotokoll
• Null-Quote der Lifecycle-Stufe < 1 % der importierten Datensätze
• Alle Beziehungsfelder lösen sich korrekt auf (keine abgekoppelten Kontakte oder Deals)

Verifizierung der Berichte:

• Alle drei Schlüsselberichte stimmen mit den Anzahlen des Quellsystems mit einer Abweichung von höchstens 2 % überein
• Umsatz- und Währungssummen stimmen mit der Quelle mit einer Abweichung von höchstens 0.1 % überein
• Datumsbasierte Filter liefern die richtigen Datensatzmengen

Freigabe durch Stakeholder:

• QA durch Vertriebsmitarbeiter abgeschlossen: Mindestens ein Mitarbeiter hat 5+ Datensätze getestet und bestätigt, dass die Daten korrekt aussehen
• Die Vertriebsleitung hat die Schlüsselberichte gesehen und bestätigt, dass sie richtig aussehen
• IT/Admin hat den Benutzerzugriff und die Berechtigungen verifiziert

Prozessbereitschaft:

• Dokument zur Feldzuordnung finalisiert (alle Fehler aus dem Testimport korrigiert)
• Importreihenfolge dokumentiert
• Rollback-Plan dokumentiert
• Kommunikation zur Umstellung entworfen

Terminieren Sie die Umstellung nicht, bevor jedes Kästchen abgehakt ist. Die Freigabeliste ist keine Bürokratie: Sie ist der Kontrollpunkt, der „wir glauben, dass es funktioniert" von „wir haben verifiziert, dass es funktioniert" trennt. Ist sie abgehakt, gehen Sie direkt zur Checkliste für den Umstellungstag, um das Go-live-Fenster zu planen.

Häufige Fehler

Mit zu wenigen Datensätzen testen, um Randfälle aufzudecken. Ein Test mit 50 Datensätzen, alle sauber, besteht die QA und scheitert trotzdem am vollständigen Import, sobald er auf die 200 Datensätze mit HTML im Notizfeld trifft. Verwenden Sie 500+ Datensätze mit gezielten Randfällen.

Nur flache Kontaktfelder testen, nicht die Beziehungen. Die QA der Kontaktfelder ist der leichte Teil. Bei der QA der Beziehungen brechen Migrationen. Jede Verknüpfung von Deal zu Kontakt und jede von Kontakt zu Unternehmen muss ausdrücklich getestet und nicht aus Prüfungen auf Feldebene gefolgert werden.

Den QA-Schritt mit Vertriebsmitarbeitern überspringen. Technische Nutzer prüfen, ob Felder korrekt sind. Vertriebsmitarbeiter prüfen, ob die Daten brauchbar sind. Das sind unterschiedliche Maßstäbe. Eine Telefonnummer, die technisch gültig, aber in einem unbrauchbaren Format ist (keine Vorwahl, falsche Landesvorwahl), besteht die technische QA und fällt beim Test durch den Vertriebsmitarbeiter durch.

Fehler im Zielsystem statt im Zuordnungsdokument beheben. Das ist der häufigste Fehler. Sie finden 5 Datensätze mit leerer Lifecycle-Stufe, setzen sie im Zielsystem manuell auf „SQL" und machen weiter. Am Umstellungstag werden 500 Datensätze mit leeren Lifecycle-Stufen importiert. Beheben Sie die Ursache im Zuordnungsdokument.

Die Umstellung terminieren, bevor der Shadow-Import abgeschlossen ist. Der Druck der Führung, einen bestimmten Go-live-Termin zu halten, ist real. Doch die Umstellung vor dem Erreichen der Freigabekriterien zu terminieren, ist der Weg, auf dem Migrationen öffentlich scheitern, unter den Augen der Vertriebsleitung. Eine Woche Verzögerung beim Shadow-Import ist besser als ein Rollback der Umstellung. Die Kultur der Pipeline-Hygiene ist hier relevanter Kontext: Teams mit schwacher Pipeline-Disziplin unterschätzen oft, wie viele schlechte Daten beim Shadow-Test an die Oberfläche kommen.

Wie es weitergeht

Terminieren Sie den Shadow-Import mindestens 5 Werktage vor Ihrer geplanten Umstellung. Dieser Puffer gibt Ihnen Zeit, Fehler zu beheben, den Testimport bei Bedarf zu wiederholen und die Freigabe der Stakeholder ohne Hektik einzuholen. Und sobald Sie freigegeben haben, enthält CRM-Rollout und Adoption die Schritte für Schulung der Vertriebsmitarbeiter und Change Management, die aus einer sauberen Datenmigration ein System machen, das das Team tatsächlich nutzt.

Der Shadow-Import sollte die letzte Aktivität vor der Terminierung der Umstellung sein und nicht eine von mehreren parallelen Aufgaben, die gleichzeitig laufen. Schenken Sie ihm die Aufmerksamkeit, die er verlangt.

Ist die Freigabe-Checkliste vollständig, sind Sie bereit, die Umstellung zu terminieren und das Drehbuch für den Tag selbst vorzubereiten. Das behandelt der Leitfaden zum Umstellungstag.

Weiterführende Ressourcen

• Daten vor der Migration vorbereiten
• Felder zwischen alten und neuen Systemen zuordnen
• Datenbereinigung: Deduplizierung, Normalisierung, Anreicherung
• Checkliste für den Umstellungstag
• Design des CRM-Datenmodells für das Zielsystem