Digitalisierung & Integration: Systeme vernetzen und Prozesse automatisieren

3. Juli 2026 | Markus Grutzeck

Eine CRM-Datenmigration ist kein größerer CSV-Import, sondern ein Eingriff ins Nervensystem Ihres Vertriebs. Wenn Beziehungen, Historien oder Rechtekonzepte brechen, sehen Sie das nicht im Importprotokoll – sondern im Alltag, wenn Vertrieb und Service im neuen System nicht mehr arbeitsfähig sind. 
Gleichzeitig treffen gewachsene Datenbestände auf rechtliche Vorgaben: DSGVO-Löschrecht, handels- und steuerrechtliche Aufbewahrungspflichten, dazu Integrationen zu ERP, Marketing, Support und BI. Wer hier nur „Daten rüberschiebt“, riskiert nicht nur Frust im Team, sondern auch Compliance-Lücken.

Die Themen im Überblick:

1. Kurzfassung – darauf kommt es bei einer CRM-Datenmigration an
2. Wie läuft eine CRM-Datenmigration ab?
3. Die 7 typischen Phasen einer CRM-Datenmigration
4. Wie schwer ist Ihr Projekt wirklich? Die Komplexitätsklassen von CRM-Migrationen
5. Welche Datenrisiken gefährden den CRM-Import?
6. Welche CRM-Daten dürfen mitwandern?
7. Wie sichern Tests den CRM-Cutover?
8. Cutover und Rollback: Der Go-live darf kein Sprung ins kalte Wasser sein
9. Wer trägt die Ownership der CRM-Datenmigration?
10. Rollen und Verantwortlichkeiten in der CRM-Datenmigration
11. Typische Anti-Muster in Migrationsprojekten
12. Wie sieht Governance in der Migration aus?
13. Wie bleiben CRM-Schnittstellen migrationsfest?
14. Checkliste: 10 Fragen, die Sie vor der CRM-Datenmigration klären sollten
15. Fazit: Datenmigration als belastbarer CRM-Übergang
16. Häufig gestellte Fragen zur CRM-Datenmigration

 

1. Kurzfassung – darauf kommt es bei einer CRM Datenmigration an

• Beziehungen statt nur Felder denken: Firmen, Kontakte, Verkaufschancen und Aktivitäten müssen nach der Migration fachlich zusammengehören – sonst sind die Daten zwar da, aber nicht nutzbar.
• Nicht alle Daten dürfen mit: DSGVO-Löschrecht und Aufbewahrungsfristen verlangen getrennte Entscheidungen, welche Daten migriert, archiviert, gesperrt oder gelöscht werden.
• Frühe Testmigrationen einplanen: Staging, Validierung und klare Go-/No-Go-Kriterien senken das Cutover-Risiko deutlich.
• Ownership klären: IT, Fachbereich, Datenschutz und Geschäftsführung brauchen definierte Rollen und Freigaben, sonst „gehört“ am Ende niemandem das Ergebnis.
• Schnittstellen mitdenken: CRM, ERP, Marketing, Support und BI müssen direkt nach dem Go-live wieder konsistent sein – sonst zerfällt der saubere Datenbestand in wenigen Tagen.

 

2. Wie läuft eine CRM-Datenmigration ab?

Eine CRM-Datenmigration ist kein einmaliger „Export/Import“, sondern ein End-to-End-Projekt. Quellanalyse, Zielmodell, Mapping, Bereinigung, Testmigration, Validierung und Cutover greifen ineinander. Wer hier Abkürzungen nimmt, zahlt spätestens beim Go-live – oft mit Akzeptanzproblemen im Vertrieb. 
Die eigentliche Arbeit steckt nicht in der Feldzuordnung, sondern im Erhalt der Beziehungslogik. Konkret heißt das: 

• Eine Firma muss nach dem Umzug weiterhin ihre Kontakte, Verkaufschancen und Aktivitäten tragen.
• Aktivitäten, Historien, Anhänge und Berechtigungen müssen im neuen System fachlich noch dasselbe bedeuten wie vorher.

Über den Erfolg entscheidet deshalb ein Zielmodell, das diese Struktur sauber abbildet – weit stärker als jede einzelne Spalte. 

 

3. Die 7 typischen Phasen einer CRM-Datenmigration

In der Praxis hat sich eine Abfolge von Phasen bewährt, die aufeinander aufbauen:

1. Quellanalyse

• Welche Systeme und Datenquellen sind betroffen?
• Welche Datenklassen (Firmen, Kontakte, Leads, Aktivitäten, Opportunities und Tickets liegen vor?
• Wie steht es um Dubletten, Karteileichen, fehlende Pflichtangaben, uneinheitliche Werte?

2. Zielmodell definieren

• Wie sieht die gewünschte Struktur im neuen CRM aus (Entitäten, Beziehungen, Pflichtfelder, Berechtigungen)?
• Welche Felder entfallen, werden zusammengeführt oder neu eingeführt?
• Wie werden Historien, Aktivitäten und Anhänge abgebildet?

3. Mapping und Transformationsregeln festlegen

• Welche Quellfelder landen in welchen Zielfeldern?
• Welche Datentypen müssen konvertiert werden (z. B. Freitext → Auswahlliste)?
• Welche Transformationsregeln gelten (Normalisierung von Ländern, Branchen, Statuswerten etc.)?
• Wie wird mit fehlenden oder widersprüchlichen Werten umgegangen?

4. Datenbereinigung und Dublettenlogik

• Welche Datensätze werden vorab bereinigt, zusammengeführt oder verworfen?
• Wie wird mit systemübergreifenden Dublettengruppen umgegangen (mehrere Altsysteme)?
• Was wird archiviert statt aktiv migriert?

5. Testmigration in einer Staging-Umgebung

• Technische Prüfung: Laufen Exporte, Importe und Skripte stabil?
• Fachliche Prüfung: Bleiben Beziehungen und Historien korrekt?
• Sichtbarmachen von Sonderfällen, Customizing-Lücken und inkonsistenten Schlüsseln.

6. Validierung und Go-/No-Go-Kriterien

• Datenvollständigkeit: Wurden alle geplanten Datensätze übertragen (Abgleich mit Quelle)?
• Beziehungslogik: Keine verwaisten Firmen, Kontakte oder Aktivitäten.
• Fachliche Freigabe: Der Fachbereich bestätigt, dass die Daten für Vertrieb, Service und Marketing tragfähig sind.
• Dokumentierte Kriterien, wann ein Cutover freigegeben oder verschoben wird.

7. Cutover und Rollback-Plan

• Zeitlich abgestimmter Wechsel von Alt- auf Neusystem (inkl. Sperrphase für Altsystem).
• Begleitende Maßnahmen: Kommunikation, Schulung, Support.
• Technischer und fachlicher Rollback-Plan, falls kritische Fehler nach dem Go-live auftreten.

Auf klare Rollen und Ownership in diesen Phasen komme ich weiter unten noch ausführlich zurück – sie entscheiden maßgeblich, ob das Projekt steuerbar bleibt oder am Ende „niemand so richtig zuständig“ ist. 

 

4. Wie schwer ist Ihr Projekt wirklich? Die Komplexitätsklassen von CRM-Migration

Wie aufwendig eine CRM-Datenmigration wird, hängt nicht nur vom Datenvolumen ab, sondern vor allem von Struktur und Beziehungsgeflecht. Die von Microsoft verwendeten Komplexitätsklassen geben eine gute Orientierung:

Einfach:

• Datenvolumen: bis ca. 1 GB oder < 50.000 Datensätze
• Struktur: flache Tabellen ohne komplexe Beziehungen
• Beispiele: einfache Adresslisten, Lead-Tabellen ohne Historien
• Vorgehen: oft per Export/Import (z. B. CSV) plus Spotchecks lösbar

Mittel:

• Datenvolumen: ca. 1-5 GB oder 50.000-500.000 Datensätze
• Struktur: relationale Daten (z. B. Konten mit Kontakten, Chancen, Aktivitäten)
• Beispiele: gewachsene CRM-Datenbestände mit Standard-Objekten
• Vorgehen: ETL-Strecken, Staging-Datenbank, mehrere Testmigrationen, gezielte Bereinigung

Komplex:

• Datenvolumen: > 50 GB oder > 500.000 Datensätze
• Struktur: Custom Tables, Workflows, Skript-/API-Logik, mehrere Quellsysteme
• Beispiele: Kombination aus CRM, ERP, Ticket- und Marketing-System, lange Historien, individuelle Prozesse
• Vorgehen: Pilot-Migrationen, phasenweise Umstellung, umfangreiche Tests, eng abgestimmte Cutover-Stratgie

Aus dieser Einordnung folgt die zentrale Planungsentscheidung:
Umfang, Testtiefe und Cutover-Risiko müssen zur Komplexitätsklasse passen. 
Eine flache Adressliste und eine mehrquellige CRM-/ERP-Migration mit 15 Jahren Historie sind nicht „dasselbe in groß“. Sie erfordern andere Werkzeuge, andere Prüfungen und einen anderen Zeitplan.

Welche Analyse braucht das Quellsystem?

Bevor das erste Feld gemappt wird, braucht es eine saubere Bestandsaufnahme der Ausgangsdaten. Eine neue Plattform allein verbessert keine Datenqualität. Wenn Altlasten ungeprüft übernommen werden, sind sie im neuen CRM nur schöner verpackt. 
In der Quellanalyse klären Sie: 

1. Welche Systeme und Datenquellen betroffen sind

• Klassische CRM-Systeme
• ERP-Module mit Kunden- und Ansprechpartnerdaten
• Marketing-Tools (Newsletter, Events, Webformulare)
• Support-/Ticket-System
• Excel-Listen, Access-Datenbanken und andere "Schatten-CRMs"

2. Welche Datenklassen und Objekte vorliegen

• Firmen/Konten
• Kontakte/Personen
• Leads, Verkaufschancen, Angebote, Aufträge
• Aktivitäten (Anrufe, Termine, E-Mails, Notizen)
• Tickets/Servicefälle
• Anhänge und Dokumente
• Einwilligungen, Kampagnenzuordnungen, Workflows

3. Wie es um Qualität und Konsistenz steht

Typische Befunde aus der Praxis:

• Dubletten (systemintern und systemübergreifend)
• Karteileichen (veraltet oder nie genutzte Datensätze)
• fehlende Pflichtangaben (z. B. keine E-Mail, keine Branche)
• uneinheitliche Werte (z. B. "D", "DE", "Deutschland" im selben Feld)
• freie Texte für eigentlich strukturierte Informationen (z. B. Status, Segment, Region)

4. Welche fachlichen Sonderfälle existieren

• alte Sonderlösungen oder Felder, die niemand mehr nutzt, aber technisch noch da sind
• "historische" Prozesse, die mitgewachsen sind und heute keiner mehr vollständig überblickt
• individuelle Berechtigungen, die bestimmte Vorgänge oder Kunden schützen sollen

Wer parallel noch das passende Zielsystem sucht, sollte diese Analyse mitnutzen: Sie zeigt, welche Funktionalität das neue CRM wirklich braucht und wo ein herstellerneutraler Vorauswahl-Prozess hilft, statt sich zu früh auf einen Anbieter festzulegen.

 

5. Welche Datenrisiken gefährden den CRM-Import?

Die größten Risiken einer Migration sind selten spektakuläre Systemabstürze, sondern unsichtbare Bruchstellen: 

• Der Import läuft technisch "erfolgreich" durch.
• Aber Beziehungen, Bedeutungen oder Kontexte gehen unterwegs verloren
• Vertrieb und Service merken das erst im Alltag wenn sie die Informationen brauchen.

Die häufigsten Risikogruppen:

1. Pflichtfelder und Formatfehler – das Offensichtliche
2. Gebrochene Beziehungen – das Versteckte
3. Dubletten und inkonsistente Schlüssel – das Langfristige
4. Historien und Aktivitäten – das Kontextproblem

5.1 Wo brechen Pflichtfelder und Formate?

Diese Felder sehen Sie oft schon im Importprotokoll:

• Pflichtfelder ohne wert (z. B. Pflicht-E-Mail in Leads, aber leer im Quellsystem)
• ungültige Formate (z. B. Datum, Zahlen, IDs)
• unzulässige Werte bei Auswahllisten

Solche Brüche blockieren den Import sofort. Sie müssen entweder:

• vorab bereinigt werden (Datenpflege im Quellsystem oder Staging) oder
• regelbasiert ergänzt werden (Standardwerte, Konvertierungen, Normalisierungen).

Diese Risiken sind unangenehm, aber vergleichsweise gut beherrschbar, weil sie früh auffallen. 

5.2 Wo brechen Beziehungen und Beziehungslogik?

Wesentlich kritischer sind Brüche in der Beziehungsstruktur:

• Firmen ohne verknüpfte Kontakte
• Kontakte ohne Firma
• Verkaufschancen ohne Konto oder verantwortlichen Besitzer
• Aktivitäten ohne zugeordneten Kontakt oder Vorgang
• Tickets ohne Bezug zum Kunden

Technisch kann der Import trotzdem „erfolgreich“ sein – fachlich sind die Daten dann kaum nutzbar. 

Besonders anfällig sind:

• Aktivitäten und lange Historien (viele Einzeldatensätze mit Referenzen)
• Anhänge und Dokumente, die an Vorgänge oder Kontakte geknüpft sind
• Status-Verläufe und Workflows, die im Zielsystem anders funktionieren als in der Altumgebung

Studien zur Migrationsdatenqualität (u. a. Fraunhofer) zeigen: 
Solche mehrattributigen Qualitätsprobleme lassen sich nicht mit einfachen Plausibilitätschecks finden. Sie brauchen: 

• regelbasierte Prüfungen (z. B. "jede Aktivität braucht genau einen gültigen Kontakt")
• repräsentative Stichproben durch den Fachbereich (Vertrieb/Service)

5.3 Wo brechen Dubletten und Schlüssel?

Dubletten sind vor allem dort ein Risiko, wo Daten aus mehreren Altsystemen zusammenlaufen. Typische Fälle: 

• dieselbe Firma in zwei CRMs mit unterschiedlichen Kundennummern
• ein Kontakt in CRM, Newsletter-Tool und Service-System jeweils mit leicht abweichenden Schreibweisen
• unterschiedliche Schlüssel pro System (z. B. Kundennummer im ERP, Account-ID im CRM)

Praxisberichte zur Mehrsystemmigration zeigen:

• Systemübergreifende Dublettengruppen lassen sich im Ursprungssystem oft gar nicht mehr sauber bereinigen.
• Deshalb braucht die Migration eine eigene Dubletten- und Zusammenführungslogik im Staging-Bereich.
• Konfliktfälle (abweichende Adressen, Telefonnummern, Zuständigkeiten) lassen sich nicht rein automatisch entscheiden – hier braucht es fachliche Regeln oder explizite Entscheidungen.

Ohne diese Logik entstehen nach dem Import:

• doppelte Firmenkonten,
• fragmentierte Historien,
• unklare Zuständigkeiten im Vertrieb.

5.4 Welche Historien werden kritisch?

Historien sind vor allem dann kritisch, wenn ihr fachlicher Nutzen an erhaltenen Beziehungen hängt. Beispiele:

• Aktivitäten ohne zugeordneten Kontakt
• Tickets ohne Kundenbezug
• Verkaufschancen ohne verknüpften Status oder Pipeline
• E-Mail-Historien, die technisch da sind, aber keinem Vorgang zugeordnet sind

Solange der Kontext erhalten bleibt, sind Historien Gold wert – für Vertrieb, Service und Reporting. Reißt der Kontext, bleiben:

• Datensätze ohne Aussagekraft,
• Performance-Last ohne fachlichen Mehrwert.

Workflows und komplexe Strukturen erhöhen das Risiko zusätzlich:

• Im Zielsystem gibt es oft andere Statusmodelle, Prozesse und Trigger.
• Historische Daten müssen daher bewusst nachmodelliert oder an das neue Prozessmodell angepasst werden – nicht nur „mitgenommen“. 

 

6. Welche CRM-Daten dürfen mitwandern?

Nicht jeder Datensatz aus dem Altsystem gehört automatisch ins neue CRM. Die Migration ist immer auch eine Auswahlentscheidung zwischen: 

• Migrieren
• Archivieren
• Sperren
• Löschen

Dabei stehen sich zwei Welten gegenüber:

• Artikel 17 DSGVO: Recht auf Löschung personenbezogener Daten
• Handels- und steuerrechtliche Aufbewahrungspflichten: Unterlagen müssen für bestimmte Zeiträume zwingend aufbewahrt werden

Personenbezogene Daten dürfen Sie also weder pauschal vollständig übernehmen noch pauschal löschen.
Stattdessen brauchen Sie eine Entscheidungslogik pro Datenklasse.

6.1 Aufbewahrungsfristen als Rahmen

Dieser Beitrag ersetzt keine rechtliche Beratung im Einzelfall. Er gibt Orientierung für typische Migrationsentscheidungen, konkrete Bewertungen zu Lösch- und Aufbewahrungspflichten sollten Sie mit Ihrer Rechts- oder Datenschutzabteilung abstimmen.

Den rechtlichen Rahmen setzen vor allem:

• § 257 HGB
• § 147 AO

Sie staffeln die Aufbewahrungspflichten nach Art der Unterlagen. Die Frist beginnt jeweils mit dem Schluss des relevanten Kalenderjahres.

Typische Fristen im CRM-Kontext:

Für die Migrationsplanung bedeutet das:

• Aufbewahrungspflichtige Belege müssen verfügbar bleiben – aber nicht zwingend als aktive Objekte im neuen CRM. 
  Sie können z. B. rechtssicher archiviert oder gesperrt werden, während das operative CRM
• nur den wirklich benötigten Teil der Historie übernimmt.
• Reine „Altleads“ oder veraltete Kontakte ohne Beziehung zu aufbewahrungspflichtigen Vorgängen sind oft Löschkandidaten.

Wichtig: Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall. 
Konkrete Bewertungen zu Lösch- und Aufbewahrungspflichten sollten Sie mit Ihrer Rechts- oder Datenschutzabteilung abstimmen. 

6.2 Entscheidungslogik: Migrieren, Archivieren, Sperren, Löschen

Praxisbewährt ist es, Daten in Klassen zu denken und je Klasse eine klare Entscheidung zu treffen:

1. Operativ benötigte CRM-Daten

• z. B. aktive Kunden, Kontakte, aktuelle Leads, offene Chancen, laufende Tickets
• Ziel: migrieren, bereinigen, Beziehungen erhalten

2. Historische Vorgänge mit Aufbewahrungspflicht

• z. B. abgeschlossene Aufträge, relevante Korrespondenz zu Verträgen, Reklamationen
• Ziel: technisch verfügbar halten (Archiv / DMS / gesperrter Bereich), aber nicht zwingend als vollwertige Datensätze im neuen CRM führen

3. Altdaten ohne fachlichen Nutzen

• z. B. uralte, nie qualifizierte Leads, veraltete Kontakte ohne Bezug zu Vorgängen
• Ziel: nach Prüfung löschen oder nur in aggregierter/statistischer Form vorhalten

4. Daten mit offenen Löschansprüchen oder ohne gültige Einwilligung

• z. B. Newsletter-Empfänger ohne dokumentierte Einwilligung, Kontakte mit explizitem Löschwunsch
• Ziel: nicht ungeprüft migrieren, sondern mit Datenschutz/Legal klären: Löschung, Sperrung oder Pflichtaufbewahrung (falls z. B. Belege betroffen sind).

Damit die Migration rechtssicher und praxistauglich bleibt, braucht es:

• klare Regeln pro Datenklasse (z. B. „alle Kunden mit Umsatz in den letzten 10 Jahren werden migriert, alle anderen archiviert“)
• eine nachvollziehbare Dokumentation, warum welche Daten wohin gewandert sind oder eben nicht
• eine Abstimmung zwischen Fachbereich, Datenschutz, Legal und IT 

 

7. Wie sichern Tests den CRM-Cutover?

Eine CRM-Migration ist am Ende immer eine Go-/No-Go-Entscheidung: 
Wird wirklich umgeschaltet – oder bleibt das Altsystem noch eine Runde länger produktiv?

Damit diese Entscheidung nicht zur Bauchfrage wird, braucht es: 

• Testmigrationen,
• eine Staging-Umgebung,
• fachliche und technische Validierung,
• und klare Kriterien, wann ein Go-live verantwortbar ist.

7.1 Testmigration und Staging: Warum der "Probelauf" Pflicht ist

Eine Testmigration ist mehr als ein technischer Probelauf:

• Sie macht Sonderfälle sichtbar, die in der Theorie nicht auffallen.
• Sie zeigt, wo Customizing-Lücken im Zielsystem bestehen.
• Sie deckt inkonsistente Schlüssel, gebrochene Beziehungen und Dublettengruppen auf.

Gerade bei umfangreichen und komplexen Migrationen hat sich eine Staging-Datenbank bewährt: 

• Sie dient als Zwischenablage für bereinigte, transformierte und zusammengeführte Daten.
• Sie ermöglicht wiederholbare Testimporte ins Ziel-CRM.
• Sie senkt die Fehlerwahrscheinlichkeit, weil Bereinigung und Mapping dort prüfbar und dokumentierbar sind.

Daumenregel:

• einfache Migrationen (bis ca. 1 GB, flache Strukturen): oft ohne Staging lösbar, mit Export/Import und Spotchecks
• relationale Daten, mehrere Quellen, rechtlich sensible Bestände: Staging ist faktischer Standard, wenn Sie das Risiko im Griff behalten wollen. 

7.2 Was vor dem Go-live nachweisbar sein sollte

Vor dem produktiven Cutover sollten einige Punkte nicht nur vermutet, sondern belegt sein:

1. Datenvollständigkeit

• Alle geplanten Datensätze wurden übertragen.
• Abgleich gegen die Quelle (Stückzahlen, Summen, ggf. Stichproben)

2. Beziehungslogik

• Firmen, Kontakte, Verkaufschancen, Aktivitäten und Tickets sind korrekt verknüpft.
• Es existieren keine systematischen "Waisen" (z. B. Aktivitäten ohne Kontakt).
• Status- und Prozesslogik ist konsistent (Pipelines, Stadien, Verantwortliche).

3. Stichprobenqualität durch den Fachbereich

• Vertrieb, Service und ggf. Marketing prüfen repräsentative Datensätze.
• Sie bestätigen: "Damit können wir arbeiten" – nicht nur "damit kann das System starten".

4. Schnittstellenverhalten

• Angebundene Systeme (ERP, Marketing, Support, BI) empfangen und verarbeiten die migrierten Daten korrekt.
• Schlüsselübergaben, IDs und Änderungslogik funktionieren wie geplant.
• Es gibt keine "stillen" Fehler im Hintergrund, die erst Wochen später auffallen.

5. Dokumentierte Go-/No-Go-Kriterien

• Klar definiert, wann ein Go-live freigegeben wird: z. B. "max. x % tolerierter Fehler in Nicht-Kerndaten, 0 % in Kerndatenklassen"
• Ebenso klar definiert, wann kein Go-live erfolgt: z. B. systematische Brüche in Beziehungen, fehlerhafte Schnittstellen, fehlende Freigabe durch Fachbereich oder Datenschutz.

 

8. Cutover & Rollback: Der Go-live darf kein Sprung ins kalte Wasser sein

Ein sauberer Cutover besteht aus mehr als einem Termin im Kalender.

Elemente eines belastbaren Cutover-Plans:

1. Zeitlich abgestimmter Übergang

• klare Sperrphase für das Altsystem (ab wann keine Buchungen mehr)
• definierte Schritte: letzter Export → Migration/Import → Validierung → Freigabe → Öffnung des neuen Systems
• kommunikativ begleitet (Wer darf wann was erwarten?) 

2. Rollen & Freigaben

• IT bestätigt die technische Stabilität.
• Fachbereich (Vertrieb/Service) bestätigt die fachliche Nutzbarkeit.
• Datenschutz/Recht gibt grünes Licht zu den getroffenen Entscheidungen in Sachen Löschung, Sperrung, Archivierung.
• Projektleitung/Geschäftsverantwortung gibt die finale Go-/No-Go-Entscheidung.

3. Rollback-Plan

• Vorab definiert: Unter welchen Bedingungen wird zurückgerollt (z. B. kritische Fehler im Kernprozess)?
• Technisch vorbereitet: gesicherter Stand des Altsystems, definierte Wiederherstellungsschritte.
• Fachlich vorbereitet: Kommunikation an Anwender („Wir bleiben vorerst im Altsystem, weil\ldots“). 

Ein dokumentierter Rollback-Plan macht aus dem Go-live statt einer Mutprobe ein steuerbares Ereignis: 
Es ist vorab klar, wann man trotz hohem Aufwand lieber nicht umschaltet – und wie man im Zweifel wieder zurückkommt.

 

9. Wer trägt die Ownership der CRM-Datenmigration?

Ownership ist kein organisatorisches Detail am Rand, sondern ein eigenes Projektrisiko.

Wenn nicht klar ist, wer Entscheidungen trifft, Freigaben erteilt und für das Ergebnis einsteht, passiert Folgendes:

• Datenregeln bleiben vage („Das regeln wir dann im Projekt\ldots“).
• Konflikte (z. B. Dublettenzusammenführung, Löschung vs. Aufbewahrung) werden vertagt.
• Am Ende fühlt sich niemand wirklich verantwortlich – außer dem Projektleiter, der es dann „irgendwie“ entscheiden soll.

Auswertungen zur Datenpflege-Governance zeigen:

• In vielen Unternehmen gibt es keine Vollzeitrolle für Datenpflege.
• In rund einem Drittel ist die Zuständigkeit unklar.
• Nur eine Minderheit hat eine formale Regelung, wer welche Datenhoheit besitzt.

Genau hier entscheidet sich, ob Ihre Migration ein steuerbares Projekt wird – oder eine Sammlung von technischen Tätigkeiten ohne klare Verantwortung.

 

10. Rollen und Verantwortlichkeiten in der CRM-Datenmigration

In einer belastbaren Migrationsorganisation sind Rollen nicht abstrakt ("Fachbereich"), sondern konkret definiert:

Wichtig ist dabei nicht nur, dass diese Rollen benannt, sondern dass sie auch mit klaren Entscheidungsrechten ausgestattet werden. 

 

11. Typische Anti-Muster in Migrationsprojekten

In vielen Projekten sieht man immer wieder dieselben Muster:

"Die IT macht das schon"

• IT übernimmt Technik und fachliche Regeln – ohne Mandat vom Vertrieb.
• Folge: technisch saubere Migration, fachlich aber wenig Akzeptanz.

"Der Fachbereich soll halt prüfen"

• Vertrieb/Service bekommt am Ende ein fertiges System mit der Bitte um Abnahme.
• Ohne vorherige Einbindung bleiben wichtige fachliche Anforderungen unberücksichtigt.

"Datenschutz unterschreibt am Schluss"

• Datenschutz wird erst ganz am Ende eingebunden.
• Wenn dann rechtliche Bedenken auftauchen, sind zentrale Designentscheidungen kaum noch änderbar.

"Niemand entscheidet über Konfliktfälle"

• Bei Dubletten, widersprüchlichen Werten oder historisch gewachsenen Sonderlösungen wird die Entscheidung vertagt.
• In der Hektik kurz vor dem Go-live wird dann improvisiert – oft mit dauerhaften Nebenwirkungen.

 

12. Wie sieht gute Governance in der Migration aus?

Ein tragfähiges Governance-Setup für eine CRM-Datenmigration umfasst typischerweise:

1. Benannte Daten-Owner je Bereich

• z. B. „Stammdaten-Owner Firmen & Kontakte“, „Owner Opportunities“, „Owner Aktivitäten & Historien“
• Diese Rollen entscheiden bei Konflikten, nicht „die IT“. 

2. Gemeinsame Workshops zu Datenregeln

IT, Fachbereich, Datenschutz und ggf. Finance/Legal definieren gemeinsam:

• welche Datenklassen wie behandelt werden,
• welche Dublettenregeln gelten,
• was migriert, was archiviert, was gelöscht wird.

3. Dokumentierte Freigaben pro Phase

• Quellanalyse: „So ist der Ist-Zustand, so sind die Schmerzpunkte.“
• Zielmodell: „So soll das neue Datenmodell aussehen.“
• Mapping & Regeln: „So laufen Feldzuordnung und Transformation.“
• Testmigration: „Mit diesen Ergebnissen können wir in die nächste Runde gehen.“
• Cutover: „Unter diesen Bedingungen gehen wir produktiv.“

4. Ein klarer Sponsor auf Geschäftsleitungsebene

• Jemand, der Konflikte entscheiden kann, wenn Fachbereich, IT und Datenschutz unterschiedliche Prioritäten haben.
• Gerade bei Aufwänden für Datenbereinigung, Governance und Schulung ist diese Rückendeckung entscheidend. 

 

13. Wie bleiben CRM-Schnittstellen migrationsfest?

Die Integration ist das Folgerisiko nach der Datenübernahme – und gehört von Anfang an in die Migrationsplanung.
Ein sauber migrierter CRM-Bestand nützt wenig, wenn:

• das ERP am nächsten Tag mit veralteten Schlüsseln weiterarbeitet,
• Marketing- und Support-Systeme noch auf die alten IDs zeigen,
• BI-Auswertungen plötzlich andere Zahlen liefern als das operative System.

Wenn Schnittstellen erst nach der Migration „wieder geradegezogen“ werden sollen, ist das Risiko hoch, dass:

• Systeme zeitweise unterschiedliche Wahrheiten über denselben Kunden führen,
• Fehler unbemerkt bleiben und erst Wochen später auftauchen,
• das Vertrauen der Anwender in das neue CRM schnell wieder sinkt. 

13.1 Welche Systeme sollten frühzeitig mitgedacht werden?

Typischerweise hängen am CRM:

• ERP (Aufträge, Rechnungen, Debitoren, Materialstämme)
• Marketing-Automation (Newsletter, Kampagnen, Formulare, Lead-Scoring)
• Support-/Ticket-Systeme (Servicefälle, SLAs, Reparaturen)
• BI-/Reporting-Systeme (Data Warehouse, Reporting-Lösungen)
• ggf. Portale, Webshops oder Partner-Systeme

Für jedes dieser Systeme sollten Sie vor Projektstart klären:

1. Welche Daten fließen in welche Richtung?

• CRM → ERP (z. B. Stammdatenänderungen)
• ERP → CRM (z. B. Umsatz, Offene Posten)
• CRM ↔ Marketing (z. B. Leads, Kampagnenreaktionen)

2. Auf welchen Schlüsseln basiert die Kopplung?

• Kundennummer, Kontakt-ID, E-Mail, Kombinationen?
• Werden diese Schlüssel in der Migration verändert oder neu vergeben?

3. Welche Prozesse sind zeitkritisch?

• z. B. Angebot → Auftrag → Lieferung → Rechnung
• Supportfall → Ersatzteilbestellung → Rückmeldung an Kunde

Gerade diese end-to-end-Prozesse müssen direkt nach dem Go-live wieder funktionieren – ohne dass manuell nachgearbeitet werden muss.

13.2 Was macht eine "migrationsfeste" Schnittstelle aus?

Eine migrationsfeste Schnittstelle ist so konzipiert, dass sie:

• mit alten und neuen Schlüsseln umgehen kann oder einen klaren Migrationspfad hat,
• Änderungen nachvollziehbar protokolliert (Wer hat wann was geändert?),
• Fehler sichtbar macht, statt sie still zu verschlucken,
• und im Idealfall auch einen Rollback einzelner Datensätze erlaubt.

Dazu gehört:

• eine klare Datenflusslogik (welches System ist führend, welches konsumiert),
• definierte Fehler- und Konfliktregeln (z. B. bei abweichenden Adressen),
• und eine Monitoring-Möglichkeit, mit der Fachbereich oder IT erkennen können, wenn Daten zwischen den Systemen hängen bleiben.

13.3 Warum eine Integrationsplattform hilft

Sobald mehr als zwei Systeme dauerhaft synchron gehalten werden müssen, stößt die klassische „Punkt-zu-Punkt-Verkabelung“ schnell an Grenzen:

• Jede neue Verbindung ist ein eigenes Projekt.
• Änderungen an einem System ziehen unvorhersehbare Seiteneffekte nach sich.
• Transparenz und Fehlersuche werden aufwendig.

Hier helfen Integrationsplattformen, die:

• unterschiedliche Systeme (Cloud und On-Premises)
• über verschiedene Protokolle und Formate
• in einem zentralen, nachvollziehbaren Datenfluss verbinden.

In unserem Fall zeigt z. B. unsere Integrationsplattform Syncler einen Weg, wie:

• CRM, ERP, Marketing- und Support-Systeme technisch gekoppelt werden,
• Datenflüsse in Echtzeit oder in definierten Intervallen laufen,
• Änderungslogiken und Rollback-Mechanismen nachvollziehbar bleiben.

Wichtiger als die konkrete Technologie ist die Herangehensweise:

• Schnittstellen werden als Teil der Migration geplant,
• nicht erst danach „herangeflanscht“.
• Ziel ist ein dauerhaft konsistenter Datenbestand über alle Kernsysteme hinweg – nicht nur ein erfolgreicher einmaliger Import. 

 

 14. Checkliste: 10 Fragen, die Sie vor der CRM-Datenmigration klären sollten

Mit den folgenden Fragen können Sie sehr schnell einschätzen, wie gut Ihr Projekt vorbereitet ist:

1. Welche Systeme und Datenquellen sind wirklich betroffen?

• Haben Sie alle CRM-, ERP-, Marketing-, Support- und Schatten-CRMs (Excel, Access, \ldots) identifiziert?

2. Wie sieht das Zielmodell im neuen CRM aus?

• Sind Entitäten, Beziehungen, Pflichtfelder, Berechtigungen und Prozesse beschrieben – oder nur „wir ziehen das nach“?

3. Welche Datenklassen werden migriert, welche archiviert, welche gelöscht?

• Gibt es eine abgestimmte Logik zwischen Fachbereich, Datenschutz und Legal?

4. Wie werden Dubletten und systemübergreifende Schlüsselkonflikte behandelt?

• Gibt es Regeln und Werkzeuge zur Dublettenbereinigung – vor und/oder während der Migration (Staging)?

5. Welche Transformations- und Bereinigungsregeln gelten?

• Sind Feldzuordnungen, Datentypkonvertierungen und Standardisierungen (z. B. Länder, Branchen, Status) dokumentiert?

6. Ist mindestens eine Testmigration geplant – mit Staging-Umgebung bei Bedarf?

• Stehen Zeit und Budget für mehrere Testläufe und fachliche Prüfungen zur Verfügung?

7. Wer gibt welche Freigaben?

• Sind technische und fachliche Go-/No-Go-Kriterien definiert – inklusive Verantwortlicher für die Entscheidung?

8. Wie werden Schnittstellen im Projekt berücksichtigt?

• Gibt es ein Konzept, wie CRM, ERP, Marketing, Support und BI nach dem Cutover wieder konsistent gehalten werden?

9. Sind Rollen und Ownership klar geregelt?

• Wer entscheidet über Datenregeln, Löschung/Aufbewahrung, Dubletten, Historien und Grenzfälle?

10. Gibt es einen dokumentierten Cutover- und Rollback-Plan?

• Wissen alle Beteiligten, was passiert, wenn der Go-live verschoben oder zurückgenommen werden muss?

Je mehr dieser Fragen Sie heute klar beantworten können, desto geringer ist Ihr Risiko beim späteren Go-live. Mehr zur sinnvollen Vorbereitung auf eine CRM-Migration im Leitfaden.

 

15. Fazit: Datenmigration als belastbarer CRM-Übergang

Die Qualität der Migration entscheidet, ob Ihr neues CRM:

• vom Vertrieb als Arbeitsplattform akzeptiert wird,
• rechtlich auf sicheren Füßen steht,
• und dauerhaft anschlussfähig an ERP, Marketing, Support und BI bleibt.

Ablauf, Risikosteuerung, rechtliche Auswahl, Cutover-Absicherung, Ownership und Integration sind dabei keine getrennten Baustellen. Sie greifen in eine zentrale Entscheidung:

Was zieht in welcher Qualität um – und wer verantwortet das Ergebnis? 
Wer diese Fragen früh klärt, verhindert, dass ein technisch sauberer Import im Tagesgeschäft wieder zerfällt und das Vertrauen in das neue System gleich zum Start leidet. 

Wenn bei Ihnen eine CRM-Migration ansteht oder diskutiert wird, lohnt sich ein strukturierter Blick von außen.

In einem 30-minütigen Erstgespräch klären wir gemeinsam welche Systeme und Datenquellen bei Ihnen betroffen sind, wo in Ihrem Szenario die größten Migrationsrisiken liegen und welche Schritte Sie als Nächstes priorisieren sollten. 
Buchen Sie einfach ein unverbindliches Beratungsgespräch mit unserem CRM-Consultant Robert Krautmann. 

 

16. Häufig gestellte Fragen zur CRM-Datenmigration

Zum Schluss fassen wir einige typische Fragen aus Projekten zusammen:

Wann ist eine Testmigration im CRM-Projekt sinnvoll?

So früh wie möglich – spätestens, sobald ein erstes Mapping entsteht.

Eine Testmigration in einer Staging-Umgebung ist mehr als ein technischer Probelauf. Sie macht Sonderfälle und Customizing-Lücken sichtbar, zeigt inkonsistente Schlüssel, Dubletten und gebrochene Beziehungen und erlaubt es, Bereinigungsregeln an echten Daten zu testen.

Je früher die Fälle auftauchen, desto günstiger können Sie sie korrigieren, noch bevor der produktive Cutover ansteht.

Wie werden Dubletten aus mehreren Altsystemen bereinigt?

Über eine systemübergreifende Bereinigungslogik, meist in einem Staging-Bereich: 
Datensätze aus mehreren Systemen werden zusammengeführt, anhand definierter Regeln (z. B. Priorität bestimmter Quellen, „aktuellstes Änderungsdatum“, Feldprioritäten) abgeglichen, Konfliktfälle (widersprüchliche Werte) werden markiert und fachlich entschieden.

Rein im Ursprungssystem lassen sich solche Mehrfach-Dubletten oft nicht mehr sauber auflösen – deshalb ist eine eigenständige Bereinigungslogik in der Migration sinnvoll.

Sollten alte CRM-Historien vollständig übernommen werden?

Nicht automatisch. Entscheidend sind fachlicher Nutzen, Datenvolumen und Performance und rechtliche Vorgaben.

Bewährt hat sich operative, aktuelle Historien vollständig zu migrieren, ältere Vorgänge selektiv oder in reduzierter Form zu übernehmen, aufbewahrungspflichtige Unterlagen rechtssicher zu archivieren (DMS, Archivsystem), statt sie als vollwertige Datensätze im neuen CRM zu halten.

Was passiert mit Kontakten ohne aktuelle Einwilligung?

Kontakte ohne dokumentierte Einwilligung werden nicht ungeprüft übernommen. Es ist zu klären:

• ob ein Löschanspruch besteht (z. B. Widerruf, Art. 17 DSGVO),
• ob Aufbewahrungspflichten entgegenstehen (z. B. im Rahmen von Geschäftsbeziehungen),
• ob der Kontakt ggf. gesperrt oder nur in archivierten Vorgängen geführt werden darf.

Datenschutz, Löschanspruch, Aufbewahrung und die Frage nach Sperren/Archivieren sind getrennte Entscheidungen – idealerweise in enger Abstimmung mit Datenschutz/Legal.

Braucht eine kleine CRM-Datenmigration ein Staging-System?

Nicht immer. Als grobe Orientierung:

• einfache Migration (bis ca. 1 GB, < 50.000 Datensätze, flache Strukturen): oft mit Export/Import und manuellen Spotchecks lösbar
• komplexere Migration (mehrere Quellen, relationale Daten, rechtlich sensible Bestände, lange Historien): Hier senkt eine Staging-Datenbank die Fehlerwahrscheinlichkeit deutlich und erleichtert Bereinigung, Dublettenlogik und wiederholte Testläufe.

Wer gibt den finalen CRM-Cutover frei?

Die technische Importfähigkeit allein genügt nicht. Ein verantwortbarer Cutover braucht:

• IT – Freigabe für technische Stabilität und Schnittstellen
• Fachbereich – Freigabe, dass die Daten für Vertrieb/Service/Marketing tragfähig sind
• Datenschutz/Legal – Freigabe der getroffenen Datenentscheidungen
• Projektleitung/Geschäftsverantwortung – finale Go-/No-Go-Entscheidung

Fehlende Governance ist ein reales Risiko, wenn niemand klar zuständig ist – deshalb sollte die Cutover-Entscheidung an definierte Rollen und dokumentierte Kriterien gebunden sein.

Wie verhindert man gebrochene ERP-CRM-Schnittstellen?

Indem man Schnittstellen nicht nachträglich repariert, sondern von Beginn an in die Migration einbezieht:

• Schlüssellogik und führende Systeme werden vorab festgelegt.
• Mapping- und Transformationsregeln berücksichtigen die bestehenden Verknüpfungen.
• Testmigrationen schließen Integrationsszenarien ein (nicht nur das CRM isoliert).
• Eine Integrationsplattform oder klar definierte Schnittstellenlogik sorgt dafür, 
  dass CRM und ERP nach dem Go-live nicht mit unterschiedlichen Schlüsseln auseinanderlaufen.