Umstiegstag: Die Checkliste, die Katastrophen verhindert

Von Victor Hoang · Aktualisiert am 8. April 2026

Der Umstiegstag ist nicht der Zeitpunkt für Improvisation. Jede CRM-Migration, die schlecht verlief, hatte dieselbe Ursache: kein schriftlicher Plan. Teams, die saubere Umstiege durchführen, arbeiten nach einer Checkliste, haben vor dem ersten Datensatz-Import einen Rollback-Auslöser definiert und kommunizieren dem Vertriebsteam in jeder Phase.

Laut Gartner-Forschung zur Datenqualität kostet schlechte Datenqualität Unternehmen durchschnittlich 12,9 Millionen US-Dollar pro Jahr. Diese Zahl spricht dafür, in die Vorbereitung zu investieren, statt nach einem gescheiterten Umstieg Notfallbereinigung zu betreiben. Hier ist, wie ein schlechter Umstieg aussieht: Ein 200-Personen-Unternehmen migrierte an einem Freitagsnachmittag von Salesforce zu einem neuen CRM. Der Import lief problemlos. Nach Stunde 6 waren die Vertriebsmitarbeiter aus beiden Systemen ausgesperrt, weil das Dateneinfrieren nicht ordentlich kommuniziert worden war. Drei fehlende Checklistenpunkte verursachten es: kein Dateneinfrierverfahren, keine vorab gesendete Mitarbeiterkommunikation, keine benannte verantwortliche Person für das Umstiegsfenster. Handelte es sich beim Quellsystem um Salesforce, zeigt der Vergleich Rework vs. Salesforce die konkreten Konfigurationsunterschiede, die im Ziel eingerichtet sein müssen, bevor Mitarbeiter sich zum ersten Mal anmelden.

Dieser Leitfaden ist der Plan, nach dem Sie vorgehen. Drucken Sie ihn aus. Lesen Sie ihn am Abend vorher. Weisen Sie jedem Punkt einen Verantwortlichen zu.

T-Minus 48 Stunden: Pre-Cutover-Checkliste

Pre-Cutover-Checkliste (10 Punkte)

• Letzter Shadow-Import-Durchlauf abgeschlossen. Die Shadow-Import-Freigabe-Checkliste ist vollständig abgehakt, keine offenen Fehler, keine ungelösten Feldzuordnungsprobleme. Wenn die Freigabe-Checkliste nicht erledigt ist, fahren Sie nicht fort.
• Sandbox-QA von Stakeholdern freigegeben. Die Vertriebsleitung hat bestätigt, dass Berichte korrekt aussehen, und mindestens ein Mitarbeiter hat seine Datensätze in der Sandbox überprüft.
• Mitarbeiterkommunikation gesendet. Die All-Hands-E-Mail oder Slack-Nachricht wurde an das Vertriebsteam gesendet, die den Umstiegszeitplan, das Dateneinfrierungsfenster und die Erwartungen am Go-live-Tag erklärt. (Vorlage am Ende dieses Leitfadens.)
• Rollback-Plan schriftlich dokumentiert. Die Rollback-Auslöserkriterien sind definiert, das Rollback-Verfahren ist schriftlich festgehalten, und die verantwortliche Person für die Rollback-Entscheidung ist benannt. (Siehe Stunde 4: die Go/No-Go-Entscheidung.)
• Dateneinfrierungsfenster kommuniziert und geplant. Mitarbeiter wissen genau, wann sie aufhören müssen, Daten in das Quellsystem einzugeben. Die Einfrierzeit steht im Kalender.
• Importsequenz-Dokument abgeschlossen. Die Reihenfolge der Operationen ist schriftlich festgehalten: Unternehmen → Kontakte → Deals → Aktivitäten → Benutzerdefinierte Objekte. Die Konfiguration des Importtools ist gespeichert und getestet.
• Feldzuordnungsdokument abgeschlossen. Keine offenen Punkte, alle Transformationsregeln dokumentiert, alle Picklist-Wertzuordnungen abgeschlossen.
• Ziel-CRM konfiguriert. Alle benutzerdefinierten Felder, Pipeline-Stufen, Lebenszyklus-Stufendefinitionen, Benutzerkonten und Berechtigungen sind in der Produktion eingerichtet (nicht nur in der Sandbox).
• Tages-Team zusammengestellt. Sie haben benannte Personen für: Import-Ausführender, QA-Verifizierer, mitarbeitergerichteter Support und Rollback-Entscheidungsträger. Dies sind nicht dieselben Personen.
• Backup des Quellsystems abgeschlossen. Vollständiger CSV-Export jedes Objekts, mit Zeitstempel und an einem zugänglichen Ort gespeichert (nicht nur auf dem Laptop der Person, die den Import durchführt).

Wenn einer dieser 10 Punkte bei T-minus 48 Stunden unvollständig ist, verschieben Sie den Umstieg. Eine Verzögerung von einer Woche ist besser als ein fehlgeschlagener Go-live.

T-Minus 2 Stunden: Dateneinfrierung

Die Dateneinfrierung ist einer der am häufigsten falsch gehandhabten Teile einer Migration. Die meisten Teams kündigen sie zu spät an, setzen sie nicht durch und stellen am Ende fest, dass Quell- und Zielsystem während des Importfensters auseinanderdriften.

Warum sie wichtig ist: Wenn ein Mitarbeiter um 9:15 Uhr einen neuen Kontakt im Quell-CRM erstellt und Ihr Import von 9:00 bis 12:00 Uhr läuft, befindet sich dieser Kontakt nicht im Ziel. Der Mitarbeiter denkt, seine Daten seien verloren gegangen. Dieses Misstrauen gegenüber dem neuen System beginnt an Tag 1 und ist schwer rückgängig zu machen.

So erzwingen Sie die Einfrierung:

• Senden Sie 2 Stunden vor dem Einfrierungsfenster eine Slack/Teams-Nachricht mit der genauen Zeit: „Die Dateneingabe in [Quell-CRM] wird von 10:00 bis 14:00 Uhr heute gesperrt."
• Ändern Sie die Benutzerberechtigungen des Quell-CRM auf schreibgeschützt für alle Nicht-Admin-Benutzer während des Importfensters. Dies ist die einzige zuverlässige Durchsetzungsmethode.
• Für Salesforce: Profil-Einstellungen, Erstellen/Bearbeiten-Berechtigungen für alle Objekte außer für Admin-Benutzer entfernen. Die Salesforce-Data-Loader-Anleitung enthält die Schritte der Importsequenz, die nach Inkrafttreten der Einfrierung auszuführen sind.
• Für HubSpot: Es gibt keinen einzigen „Nur-Lesen-Modus", für die meisten Teams ist Kommunikation die Durchsetzungsmethode. Die nächstliegende Option ist, alle Nicht-Admin-Benutzer vorübergehend aus dem Konto zu entfernen. Die Importdokumentation von HubSpot behandelt den Importprozess nach der Einfrierung und zeigt, was das Import-Protokoll für die QA sichtbar macht.
• Für Pipedrive: Unter Einstellungen > Benutzer verwalten lassen sich Berechtigungen pro Benutzer einschränken. Der Pipedrive-Importleitfaden dokumentiert, was passiert, wenn während eines Importfensters doppelte Kontakte eintreffen, relevant, falls Datensätze die Einfrierung durchlaufen.

Was mit Deals zu tun ist, die während des Einfrierungsfensters eingehen: Das wird passieren. Ein Mitarbeiter erhält um 10:30 Uhr einen eingehenden Lead während der Einfrierung. Die Antwort: notieren, nicht in das Quellsystem eingeben, und nach dem Go-live direkt in das Ziel eingeben. Weisen Sie das Team vor Beginn der Einfrierung darauf hin.

Das Einfrierungsfenster sollte mindestens 1 Stunde vor dem Import-Start liegen. Starten Sie den Import nicht in dem Moment, in dem die Einfrierung greift. Planen Sie eine Stunde Puffer ein, damit letzte Dateneingaben abgeschlossen und synchronisiert werden.

Stunden 1–3: Der Import-Lauf

Sie arbeiten nach dem Importsequenz-Dokument. Keine Improvisation.

Importsequenz

Führen Sie Importe in dieser genauen Reihenfolge durch. Jeder Schritt hängt für die Auflösung der Beziehungen vom vorherigen ab:

1. Unternehmen / Accounts, Keine Abhängigkeiten. Zuerst ausführen.
2. Kontakte, Abhängt von Unternehmen (für Unternehmensverbindung). Unternehmensanzahl überprüfen, bevor Sie fortfahren.
3. Deals / Opportunities, Abhängt von Kontakten (für Kontaktverbindung). Kontaktanzahl überprüfen, bevor Sie fortfahren.
4. Aktivitäten (Anrufe, E-Mails, Notizen, Aufgaben), Abhängt von Kontakten und Deals. Zuletzt ausführen.
5. Benutzerdefinierte Objekte, Falls zutreffend. Nach allen Standardobjekten ausführen.

Zwischen jedem Schritt:

• Import-Protokoll auf Fehler prüfen, bevor zum nächsten Objekt fortgefahren wird
• Datensatzanzahl notieren und mit erwartetem Wert vergleichen
• 3 Datensätze manuell überprüfen, um zu bestätigen, dass der letzte Import korrekt verlaufen ist

Was im Import-Protokoll zu beachten ist:

• Typkonvertierungsfehler (Textwert in einem Zahlenfeld)
• Pflichtfeld-Fehler (übersprungene Datensätze, weil ein Pflichtfeld leer war)
• Beziehungsauflösungsfehler (Kontakt importiert, aber Unternehmensverbindung fehlgeschlagen)
• Duplikaterkennung (hat das Ziel Deduplizierungsregeln, werden einige Datensätze möglicherweise blockiert)
• Rate-Limiting oder Timeout-Fehler (große Importe können API-Limits erreichen; bei Bedarf pausieren und fortsetzen)

Für große Datensätze (50.000+ Datensätze): Führen Sie den Import in Batches von 10.000–15.000 Datensätzen pro Batch durch. Das gibt Ihnen einen Wiederherstellungspunkt, falls der Import mittendrin fehlschlägt, und erleichtert die QA: Sie können jeden Batch prüfen, bevor Sie den nächsten starten. Bestätigen Sie vor dem Import-Lauf, dass Ihre Daten bereinigt und dedupliziert wurden: Schmutzige Daten in großem Umfang zu importieren verschärft Probleme exponentiell. Bei großen Migrationen, die RevOps begleitet, ist das RevOps-Reifegradmodell ein nützlicher Kontext, denn es hilft, realistische Erwartungen zu setzen, wie viel Nachbereinigung Teams unterschiedlicher Reife nach dem Umstieg typischerweise brauchen.

Starten Sie die QA erst, wenn der Import vollständig abgeschlossen ist. Es ist verlockend, schon während des Imports Datensätze zu prüfen. Warten Sie. Teildaten sind irreführend, und Sie verschwenden Zeit mit Problemen, die sich lösen, sobald die übrigen Daten importiert sind.

Stunden 3–4: Go-live QA

Dies ist Ihre letzte Überprüfung, bevor Sie den Schalter umlegen. Arbeiten Sie die 15 Prüfungen systematisch ab. Jede Prüfung hat ein Bestanden/Nicht-bestanden-Urteil.

Go-live QA-Checkliste (15 Prüfungen)

Datensatzanzahl-Prüfungen:

1. Gesamtanzahl Kontakte im Ziel = erwartete Anzahl (±0,5 %)
2. Gesamtanzahl Unternehmen im Ziel = erwartete Anzahl (±0,5 %)
3. Gesamtanzahl Deals im Ziel = erwartete Anzahl (±0,5 %)
4. Gesamtanzahl offene Deals im Ziel = Quell-Anzahl offener Deals

Feldgenauigkeit Stichproben (jeweils 10 Datensätze öffnen): 5. [ ] Kontakt-Lebenszyklus-Stufen zeigen gültige Werte (keine Nulls, keine nicht zugeordneten Werte) 6. [ ] Deal-Stufen werden korrekt den Ziel-Pipeline-Stufen zugeordnet 7. [ ] Deal-Beträge werden als Zahlen angezeigt (nicht als Text) 8. [ ] Datumsfelder (Abschlussdatum, Erstellungsdatum) werden im richtigen Format angezeigt

Beziehungsintegrität: 9. [ ] Zufällige Stichprobe von 10 Kontakten, alle haben korrekte Unternehmensverbindung 10. [ ] Zufällige Stichprobe von 10 Deals, alle haben mindestens eine Kontaktverbindung 11. [ ] Zufällige Stichprobe von 5 Deals, Deal-Eigentümer ist korrekt zugewiesen

Bericht-Überprüfung: 12. [ ] Pipeline-nach-Stufe-Bericht: Gesamtwert offener Deals stimmt mit Quellsystem innerhalb von 1 % überein 13. [ ] Kontakte nach Lebenszyklus-Stufe: Anzahl pro Stufe stimmt mit Quellsystem innerhalb von 2 % überein 14. [ ] In diesem Zeitraum erstellte Deals: Anzahl stimmt mit Quellsystem überein (unter Berücksichtigung des Einfrierungsfensters)

Systemfunktion: 15. [ ] Test des Erstellens eines neuen Kontakts im Ziel, grundlegende Workflows funktionieren korrekt, keine Fehler

QA-Bewertung:

• 15/15 Prüfungen bestanden: Weiter zur Go-live-Entscheidung
• 13–14/15 Prüfungen bestanden: Fehler bewerten, sind sie blockierend? Kleine Darstellungsprobleme sind etwas anderes als defekte Beziehungsfelder
• <13/15: Nicht live gehen. Fehler diagnostizieren, den Umfang der Auswirkungen bestimmen und die Rollback-Entscheidung treffen

Stunde 4: Die Go/No-Go-Entscheidung

Dies ist die Entscheidung, die geplante Umstiege von chaotischen trennt. Die Kriterien für den Go-live und für den Rollback müssen vor dem Start definiert sein und nicht während des QA-Fensters diskutiert werden.

Go-Kriterien (alle müssen zutreffen):

• QA-Checkliste-Score: 14/15 oder besser
• Keine blockierenden Probleme (alle offenen Deals haben die richtige Stufe, alle Kontakte eine gültige Lebenszyklus-Stufe)
• Berichtssummen innerhalb der Toleranz (Pipeline-Wert innerhalb von 1 %, Stufenanzahl innerhalb von 2 %)

Rollback-Auslöser (jeder einzelne ist ausreichend):

1. Datensatzanzahl weicht um mehr als 2 % ohne Erklärung ab (Datensätze gingen beim Import verloren)
2. Beziehungsfelder sind im großen Maßstab defekt (mehr als 5 % der Deals haben keine Kontaktverbindung)
3. Feldtyp-Korruption erkannt (Währungsfelder werden als Text importiert und beeinträchtigen Umsatzberichte)
4. Das Ziel-CRM selbst hat Performance-Probleme, die eine normale Nutzung verhindern

Wer entscheidet: Benennen Sie im Voraus eine Person. Keine Komitee-Entscheidung. Die benannte verantwortliche Person (DRI, Directly Responsible Individual) trifft die Entscheidung auf Grundlage der obigen Kriterien, ohne Konsens abzuwarten. Wenn alle entscheiden, entscheidet niemand schnell, und Verzögerungen verschärfen das Problem.

So kommunizieren Sie die Entscheidung:

• Go: Senden Sie sofort die Go-live-Nachricht (Vorlage unten)
• No-go/Rollback: Senden Sie sofort die Rollback-Nachricht und folgen Sie dann dem Rollback-Verfahren

Verzögern Sie die Kommunikation nicht, während Sie ein Problem „prüfen“. Senden Sie zuerst die Statusnachricht und untersuchen Sie danach.

Stunden 4–5: Rollback-Verfahren

Wenn Sie einen Rollback auslösen, scheitern Sie nicht. Sie führen den Plan aus. Ein Rollback ist besser, als mit beschädigten Daten live zu gehen.

Rollback-Verfahren:

1. Rollback-Kommunikation sofort an das Vertriebsteam senden: „Wir haben ein Problem während der QA identifiziert und kehren vorübergehend zu [Quell-CRM] zurück. Sie können die Arbeit in [Quell-CRM] wieder aufnehmen, keine Daten sind verloren gegangen. Das neue Go-live-Datum teilen wir innerhalb von 24 Stunden mit."

2. Vollständigen Zugang zum Quell-CRM wiederherstellen (Dateneinfrierungs-Berechtigungen rückgängig machen).

3. Den Ziel-CRM-Import bereinigen. Die meisten CRMs erlauben eine Bulk-Löschung für Daten, die während eines bestimmten Fensters importiert wurden, oder ein „Zurücksetzen auf leer“. Tun Sie dies, bevor das Team im Ziel irgendwelche Änderungen vornimmt. Für den erneuten Import brauchen Sie einen sauberen Neustart.

4. Die geleistete Arbeit bewahren. Export-Protokolle, Fehlerprotokolle und QA-Notizen exportieren. Sie bilden die Grundlage für die Behebung der Ursache.

5. Für den nächsten Geschäftstag ein Nachgespräch planen. Was ist fehlgeschlagen? Was muss im Zuordnungsdokument geändert werden? Wie lange dauert die Korrektur? Setzen Sie einen realistischen Zeitplan für die Wiederholung.

Rollback-Zeitrahmen: Ziel ist es, den Rollback und die Wiederherstellung des Quell-CRM-Zugangs innerhalb von 90 Minuten nach der Entscheidung abzuschließen. Je länger Mitarbeiter in der Schwebe bleiben, desto mehr Misstrauen entsteht.

Neuterminierung: Fügen Sie mindestens 5 Werktage zum neuen Umstiegsdatum hinzu. So haben Sie Zeit, die Ursache zu beheben, einen weiteren Shadow-Import zur Verifizierung der Korrektur durchzuführen und die Freigabe der Stakeholder einzuholen, bevor Sie es erneut versuchen. Wer die Wiederholung überstürzt, scheitert zweimal.

Stunde 5: Go-live Kommunikation

Besteht die QA und haben Sie sich für den Go-live entschieden, kommunizieren Sie sofort.

Go-live Kommunikationsvorlage

Slack / Teams (zuerst senden):

[Name], Team, [CRM-Name] ist live. Sie können das neue System jetzt verwenden.

Kurze Hinweise:

• Ihre Daten befinden sich ab heute in [CRM-Name]
• Falls Sie etwas suchen und nicht finden, posten Sie in #crm-support, wir helfen
• [Quell-CRM] ist im schreibgeschützten Modus und bleibt 30 Tage lang zugänglich als historische Referenz

Ansprechpartner für Tag-1-Fragen: [Name], schreiben Sie direkt an die Person oder in #crm-support

E-Mail (innerhalb von 30 Minuten nach Go-live senden):

Betreff: [CRM-Name] ist live, was Sie wissen müssen

Die Migration ist abgeschlossen. Ab sofort ist [CRM-Name] das System der Aufzeichnung für alle Vertriebsaktivitäten.

Was Sie heute tun müssen:

• Melden Sie sich bei [CRM-Name] unter [URL] mit Ihren Anmeldedaten an
• Überprüfen Sie, ob Ihre offenen Deals die richtige Stufe und den richtigen Betrag anzeigen
• Wenn etwas falsch aussieht, wenden Sie sich an [Name], korrigieren Sie es nicht selbst

Schreibgeschützter Zugang zu [Quell-CRM]: [Quell-CRM] ist weiterhin als schreibgeschütztes Archiv bis [Datum 30 Tage ab jetzt] zugänglich. Nutzen Sie es als Referenz für historische Aktivitäten. Geben Sie keine neuen Daten in [Quell-CRM] ein.

Tag-1-Support: [Name] ist heute und morgen für Fragen verfügbar. Slack: #crm-support. E-Mail: [Adresse].

Vielen Dank für Ihre Geduld während der Migration.

Senden Sie beide Nachrichten innerhalb von 5 Minuten nach der Go-live-Entscheidung. Warten Sie nicht auf eine abschließende Prüfung. Die Schnelligkeit der Kommunikation verhindert die Verwirrung „Ist das System nun live oder nicht?“.

Tage 1–3: Post-Cutover-Überwachung

Der Go-live ist nicht das Ende, sondern der Beginn der Stabilisierungsphase. Häufige Tag-1-Fehler treten auf, sobald Mitarbeiter das System auf Weisen nutzen, die die QA nicht abgedeckt hat.

Tägliche Überwachungs-Checkliste (Tage 1–3)

Tag 1 (innerhalb von 2 Stunden nach Go-live):

• 20 Datensätze aus der aktiven Pipeline eines Mitarbeiters stichprobenartig prüfen: Sind Stufen, Kontakte und Beträge korrekt?
• #crm-support-Kanal auf gemeldete Probleme prüfen, innerhalb von 15 Minuten triagieren und reagieren
• Neue Datensätze, die nach Go-live erstellt wurden, werden korrekt gespeichert (Prüfung der grundlegenden CRM-Funktion)

Tag 1 (Ende des Tages):

• Anzahl gemeldeter Probleme, nach Datenqualität, Feldzuordnung oder Benutzerfehler kategorisieren
• Gibt es Probleme, die eine Korrektur erfordern (keine Schulung)? Ursache identifizieren und zur Behebung festhalten
• Status-Update an Vertriebsleitung: X Probleme gemeldet, Y gelöst, Z in Bearbeitung

Tage 2–3:

• Tägliche Überprüfung des Problemprotokolls, wiederholen sich dieselben Probleme? Wiederkehrende Probleme deuten auf einen systematischen Zuordnungsfehler hin, nicht auf einen Einzelfall
• Überprüfen, ob deal-stufenbasierte Automatisierung korrekt ausgelöst wird (neue Deals, die Stufen durchlaufen, sollten die richtigen Sequenzen auslösen)
• Berichtsgenauigkeit prüfen: Stimmt der Pipeline-Bericht mit dem überein, was Mitarbeiter in ihren Pipelines angeben?

Häufige Tag-1-Fehler und Korrekturen:

Die 48-Stunden-Regel: Die meisten Tag-1-Probleme zeigen sich innerhalb von 48 Stunden. Wenn Sie bis Tag 3 nichts von einem Problem gehört haben, hören Sie wahrscheinlich auch nichts mehr. Überwachen Sie aktiv drei Tage lang und wechseln Sie dann zu einem wöchentlichen Abstimmungsrhythmus.

Häufige Fallstricke

Keine definierten Rollback-Kriterien. Ohne vorab definierte Kriterien wird die Rollback-Entscheidung zu einer Komitee-Debatte während einer Krise. Das Team streitet 45 Minuten darüber, ob 3 % verwaiste Deals „schlimm genug“ für einen Rollback sind, während die Mitarbeiter warten. Definieren Sie die Kriterien, bevor Sie starten.

Keine Dateneinfrierung. So weichen Quell- und Ziel voneinander ab. Ein Mitarbeiter legt um 10:45 Uhr während des Import-Laufs einen Deal an. Er ist im Quellsystem, aber nicht im Ziel. Der Mitarbeiter denkt, die Migration habe seine Arbeit verloren. Das ist ein Problem für Moral und Vertrauen, das sich vollständig vermeiden lässt.

Unzureichende Go-live QA. Den Import abzuschließen und innerhalb von 30 Minuten live zu gehen überspringt die QA, die defekte Währungsfelder und verwaiste Deal-Datensätze erkennt. Das 90-minütige QA-Fenster ist es wert.

Keine benannte verantwortliche Person für Tag-1-Support. Den Mitarbeitern zu sagen, sie sollen „jemanden fragen" ist kein Support-Plan. Die Forschung der Harvard Business Review zu Change Management und organisatorischer Verantwortlichkeit zeigt, dass benannte Verantwortlichkeit zu den stärksten Prädiktoren für erfolgreiche Technologiewechsel gehört. Eine benannte Person, sichtbar in der Kommunikation, die direkt angeschrieben werden kann. Diese Person klärt Fragen vor Ort oder eskaliert sie. Sie schiebt nichts auf. Der Leitfaden zu CRM-Rollout und Akzeptanz enthält einen strukturierten Onboarding-Plan für Tag eins und zwei, lesenswert, bevor Sie die Go-live-Kommunikation schreiben.

Freitagsnachmittag-Umstiege. Dieses Thema kommt ständig auf. Der Wikipedia-Eintrag zur Datenmigration hält fest, dass Timing und Rollback-Planung zu den am häufigsten genannten Fehlerfaktoren bei Unternehmensmigrationen gehören, und die Freitagsplanung ist ein wiederkehrendes Thema. Es gibt den Druck, am Freitag umzustellen, damit Mitarbeiter das Wochenende zur „Eingewöhnung“ haben. Tatsächlich treten die Probleme am Freitagnachmittag auf, das Migrationsteam ist ins Wochenende gegangen, und die Mitarbeiter verbringen den Montag mit ungelösten Datenproblemen. Planen Sie Umstiege für Dienstag oder Mittwoch morgen. Das Team ist frisch, Support ist verfügbar, und Probleme werden noch am selben Werktag gelöst. Für die Kontinuität der Pipeline hilft es, vor der Umstiegswoche Pipeline-Hygiene-Kultur zu lesen: Der Beitrag erklärt, was Mitarbeiter am ersten Tag sehen müssen, um das Vertrauen in die Daten des neuen Systems zu behalten.

Was als Nächstes zu tun ist

Planen Sie den Umstieg für einen Dienstag- oder Mittwochmorgen, nicht für einen Freitag. Senden Sie die T-minus-48-Stunden-Pre-Cutover-Checkliste heute an Ihren Migrationsverantwortlichen und bestätigen Sie, dass alle 10 Punkte Fertigstellungsdaten haben.

Wenn Ihr Shadow-Import noch nicht freigegeben ist, planen Sie den Umstieg gar nicht erst. Die Freigabe des Shadow-Imports ist die Voraussetzung für alles in diesem Leitfaden. Und sobald sich der Staub gelegt hat, nutzen Sie den Artikel zum Lead-Datenmanagement als Grundlage für die laufenden Datenqualitätspraktiken, die verhindern, dass bei der nächsten Migration dieselbe Bereinigungsarbeit nötig wird.

Weitere Ressourcen

• Migration mit einem Shadow-Import testen
• Daten vor der Migration vorbereiten
• Felder zwischen alten und neuen Systemen zuordnen
• CRM-Rollout und Akzeptanz nach dem Go-live
• Rework vs. Salesforce: Unterschiede bei der Migration