FEUSTO GmbHWebsite besuchen →
← Zurück zum Blog

CRM Data Migration: Der Fahrplan für den Systemwechsel

28. August 2026
CRM Data Migration: Der Fahrplan für den Systemwechsel

Eine erfolgreiche CRM Data Migration folgt einem geordneten Ablauf: Planen, Bereinigen, Mapping erstellen, Testen, Cutover, Hypercare. Wer diese Reihenfolge einhält, vermeidet die häufigsten Fehler beim CRM Systemwechsel, etwa doppelte Datensätze oder verlorene Beziehungen zwischen Kontakten und Deals. Klären Sie vorab, wer die Projektverantwortung trägt, und prüfen Sie frühzeitig, welche personenbezogenen Daten die DSGVO betrifft.

Kurz gesagt:

  • Bei der Datenbereinigung vor der Migration sollten Duplikate entfernt und veraltete Datensätze archiviert werden, um spätere Korrekturen zu vermeiden.
  • Das Feld‑ und Beziehungs‑Mapping muss in der richtigen Reihenfolge stattfinden, wobei Kontakte erst nach Firmen und Benutzer importiert werden.
  • Eine Testmigration mit mindestens 50 bis 500 Datensätzen ist essenziell, um Mapping-Fehler und Beziehungsprobleme vor dem Go‑Live zu erkennen.
  • Das Cutover sollte an einem deutlich außerhalb des Monatsendes liegenden Wochenende erfolgen, um Vertriebsaktivitäten nicht zu stören.
  • Organisatorische Faktoren wie unklare Verantwortlichkeiten und fehlende Akzeptanz im Team sind häufig der Grund für Scheitern einer CRM‑Migration, nicht technische Fehler.

Inhaltsverzeichnis

Was ist CRM‑Datenmigration und wie unterscheidet sie sich von einer Integration?

Bei der Datenmigration CRM übertragen Sie Datensätze vollständig von einem System in ein anderes, meist einmalig und mit einem klaren Enddatum. Eine Integration dagegen verbindet zwei Systeme dauerhaft, sodass Daten laufend zwischen ihnen fließen. Migration heißt: das alte System wird abgeschaltet, das neue übernimmt die Rolle als einzige Wahrheitsquelle.

Zur Migration gehört mehr als die reine CRM Datenübertragung von Kontaktdatensätzen. Berücksichtigen Sie:

  • Kernobjekte wie Firmen, Kontakte, Deals und Tickets
  • Beziehungen zwischen diesen Objekten, etwa welcher Kontakt zu welchem Deal gehört
  • Historie: E‑Mail‑Verläufe, Notizen, abgeschlossene Aktivitäten
  • Berechtigungen und Nutzerrollen
  • Abhängigkeiten zu bestehenden Workflows und Automatisierungen

Diese umfassende Sichtweise auf CRM‑Daten, Beziehungen, Historie und Berechtigungen beschreibt auch HubSpots Prozessübersicht zur CRM‑Datenmigration ausführlich. Das Ziel ist immer dasselbe: eine einzige verlässliche Datenquelle, die Ihr Team auch tatsächlich nutzt. Denn selbst die sauberste Migration bringt nichts, wenn die Mitarbeitenden am Ende doch wieder zur alten Excel‑Liste greifen.

Schritt‑für‑Schritt‑Plan: Phasen, Aktivitäten und Verantwortlichkeiten

Ein CRM Systemwechsel lässt sich in sechs Phasen gliedern. Jede Phase hat eigene Aufgaben und eigene Abnahmekriterien, bevor es weitergeht.

  1. Plan: Umfang festlegen, Datenquellen inventarisieren, Zeitrahmen und Budget grob schätzen.
  2. Bereinigen: Duplikate entfernen, veraltete Datensätze archivieren oder löschen, Felder standardisieren.
  3. Mapping: Felder und Beziehungen zwischen altem und neuem System zuordnen.
  4. Testen: Testmigration mit einer Stichprobe durchführen, Ergebnisse validieren.
  5. Cutover: Vollständige Migration am geplanten Stichtag, altes System auf Nur‑Lesen setzen.
  6. Hypercare: Intensive Betreuung der ersten Wochen nach dem Go‑Live.

Legen Sie vorab eine RACI‑Matrix an. Wer ist Responsible für die Datenbereinigung? Wer ist Accountable für das finale Go‑Live? IT‑Leitung, Vertriebsleitung und ein externer Migrationsverantwortlicher übernehmen dabei oft unterschiedliche Rollen, und ohne diese Klarheit verzögert sich fast jedes Projekt in der Cutover‑Phase. Vor jedem Phasenübergang braucht es eine Go/No‑Go‑Freigabe durch die verantwortliche Person, nicht nur ein stilles Durchwinken im Team‑Chat.

Die Dauer hängt stark von der Komplexität ab. Ein einfacher Wechsel mit wenigen Datensätzen und wenigen Automatisierungen dauert in der Regel wenige Wochen. Mittelkomplexe Projekte mit mehreren Integrationen und größeren Datenmengen benötigen längere Zeit, und komplexe Migrationen mit mehreren Abteilungen, individuellen Workflows und umfangreicher Historie sollten mehrere Monate eingeplant werden.

Profi-Tipp: Blockieren Sie das Cutover‑Wochenende nicht am Monatsende. Vertriebsteams schließen dann oft noch offene Deals ab, und ein Systemwechsel mitten in dieser Phase sorgt garantiert für Frust.

Datenbereinigung: Was vor der Migration passieren muss

Bereinigung vor der Migration ist deutlich günstiger als Nacharbeit danach, weil fehlerhafte Daten sich sonst im neuen System vervielfachen und jede spätere Korrektur mehr Zeit kostet. Teilen Sie jeden Datensatz in eine von drei Kategorien ein: löschen, archivieren oder migrieren.

  • Löschen: Testdatensätze, offensichtliche Duplikate, Kontakte ohne jede Aktivität seit Jahren.
  • Archivieren: Datensätze mit rechtlicher Aufbewahrungspflicht, aber ohne aktuellen geschäftlichen Nutzen.
  • Migrieren: Alles, was aktiv genutzt wird oder für laufende Geschäftsprozesse relevant ist.

Nicht jeder personenbezogene Datensatz darf pauschal übernommen werden. Handels‑ und steuerrechtliche Aufbewahrungsfristen sowie das Recht auf Löschung setzen hier Grenzen, wie Sellmores Leitfaden zur CRM‑Datenmigration betont. Nutzen Sie die Migration als Anlass für DSGVO‑bewusste Kundendatenpflege statt alten Ballast einfach mitzuschleppen.

Für Duplikate hat sich ein dreistufiges Vorgehen bewährt: Starten Sie mit der sichersten Regel, meist der exakten E‑Mail‑Adresse. Danach folgt Domain‑basiertes Matching für Firmenkontakte. Erst zuletzt kommt unscharfes Matching (Fuzzy Matching) für ähnliche Namen zum Einsatz, weil es die höchste Fehlerquote hat. Dokumentieren Sie jede Regel in einem Data Dictionary, damit spätere Nachfragen nicht im Nichts enden.

Profi-Tipp: Markieren Sie jeden importierten Datensatz mit einem Herkunftsfeld wie „migration_source“. So lässt sich später jederzeit nachvollziehen, welche Daten aus der alten Tabelle stammen und welche neu angelegt wurden.

Feld‑ und Beziehungs‑Mapping: Reihenfolge entscheidet über Erfolg

Ein Mapping‑Spreadsheet ist das wichtigste Arbeitsdokument der gesamten CRM Datenübertragung. Es listet für jedes Feld im alten System das passende Zielfeld im neuen System, den Datentyp und eventuelle Transformationsregeln.

Die Reihenfolge des Imports folgt immer der Eltern‑Kind‑Logik. Zuerst Benutzer, dann Firmen beziehungsweise Accounts, danach Kontakte, anschließend Deals und zuletzt Aktivitäten. Wer diese Sequenz umdreht, produziert verwaiste Datensätze, die auf ein Elternobjekt verweisen, das noch gar nicht existiert.

  • Legen Sie für jedes benutzerdefinierte Feld fest, ob es im Zielsystem eine Entsprechung hat oder neu angelegt werden muss.
  • Definieren Sie Konvertierungsregeln für abweichende Formate, etwa unterschiedliche Datumsformate oder Dropdown‑Werte.
  • Prüfen Sie Pflichtfelder im Zielsystem, die im alten System optional waren.

Diese technischen Grundsätze zu Mapping und Transformationsregeln behandelt auch Microsofts Leitfaden zur Datenmigration in Dataverse im Detail, auch wenn er sich primär an technische Teams richtet. Für KMU reicht oft eine einfache Tabelle mit vier Spalten: Quellfeld, Zielfeld, Datentyp, Transformationsregel.

Testmigrationen und Validierungskriterien vor dem Go‑Live

Eine Testmigration mit einer kleinen, repräsentativen Stichprobe, etwa 50 bis 500 Datensätze, deckt die meisten Mapping‑Fehler auf, bevor sie im großen Maßstab Schaden anrichten. Wiederholen Sie den Testlauf, bis keine neuen Fehler mehr auftreten.

  1. Vergleichen Sie die Datensatzanzahl zwischen Quelle und Ziel exakt.
  2. Prüfen Sie die Beziehungsintegrität: Sind alle Kind‑Objekte korrekt mit ihren Eltern verknüpft?
  3. Kontrollieren Sie Owner‑Zuordnungen und Berechtigungen stichprobenhaft.
  4. Lassen Sie den Vertrieb selbst einige Datensätze fachlich gegenprüfen.

Setzen Sie sich vorab eine Toleranzgrenze, etwa eine Beziehungsintegrität von über 98 %, wie sie im ECOSIRE‑Playbook zur CRM‑Migration als praktikabler Richtwert genannt wird. Liegt der Wert darunter, folgt kein Cutover, sondern eine weitere Testrunde. Eine Sandbox‑ oder Staging‑Umgebung erlaubt beliebig viele Wiederholungen, ohne das Livesystem zu gefährden. Legen Sie außerdem klare Rollback‑Trigger fest, etwa eine Fehlerquote über einem festen Schwellenwert, bei der die Migration sofort gestoppt und die letzte funktionierende Version wiederhergestellt wird.

Cutover und Hypercare: Die ersten 30 Tage nach dem Wechsel

Am Cutover‑Tag setzen Sie das alte System auf Nur‑Lesen, führen die finale Delta‑Migration der zwischenzeitlich neu entstandenen Datensätze durch und informieren alle Nutzer über den genauen Zeitpunkt der Umstellung.

  • Kommunizieren Sie das Cutover‑Fenster mindestens eine Woche vorher an alle betroffenen Teams.
  • Planen Sie tägliche Health‑Checks für die ersten zwei Wochen nach dem Go‑Live.
  • Definieren Sie eine Fehler‑SLA: kritische Fehler binnen 24 Stunden, kleinere binnen einer Woche.
  • Erstellen Sie einen kurzen täglichen Report an die Projektverantwortlichen während der Hypercare‑Phase.

Bei jedem gemeldeten Fehler stellt sich dieselbe Frage: Patch oder Rollback? Kleine Feldfehler lassen sich in der Regel patchen. Fehlt aber eine ganze Kategorie von Beziehungen oder sind Berechtigungen systematisch falsch gesetzt, ist ein Rollback auf die letzte stabile Version oft die schnellere Lösung als tagelanges Nachbessern.

Profi-Tipp: Reservieren Sie in den ersten beiden Wochen nach dem Cutover feste Sprechzeiten für Rückfragen der Nutzer. Das fängt viele kleine Probleme ab, bevor sie sich zu größeren Frustpunkten aufbauen.

Kompakte Checkliste und Beispielzeitplan für den Systemwechsel

Vor dem finalen Go‑Live helfen wenige klare Fragen mehr als jede ausführliche Dokumentation.

  1. Ist die Testmigration ohne kritische Fehler durchgelaufen?
  2. Liegen alle Validierungswerte über der festgelegten Toleranzgrenze?
  3. Wurden alle Nutzer über das Cutover‑Fenster informiert?
  4. Steht ein Rollback‑Plan mit klaren Auslösekriterien bereit?

Budget und Zeitaufwand hängen vor allem von drei Faktoren ab: Datenvolumen, Anzahl der Integrationen und Grad der individuellen Anpassungen im alten System. Je mehr Automatisierungen und Sonderfelder Sie über Jahre angesammelt haben, desto mehr Zeit fließt in die Bereinigungsphase.

Nutzen Sie diese Einordnung als groben Rahmen für Ihr eigenes Budgetgespräch, nicht als exakte Vorhersage.

Erfahrungswerte aus der Praxis integrierter Plattformen

Funnel-tunnel bündelt Kontaktverwaltung, Terminbuchung und Automatisierung in einer Oberfläche, was Mapping‑Arbeit bei einem CRM Systemwechsel spürbar reduziert: Statt Daten zwischen fünf Insellösungen abzugleichen, entfällt ein großer Teil der Schnittstellenprüfung von vornherein. Für Automatisierungsworkflows nach der Migration zeigt sich das besonders deutlich, wenn bisher separate E‑Mail‑Tools und Terminkalender zusammengeführt werden müssen.

Hand, die einen mechanischen Timer auf dem Schreibtisch einstellt

Warum viele Migrationsprojekte trotz guter Planung scheitern

Die meisten Ratgeber zur CRM Data Migration konzentrieren sich auf Technik: Mapping‑Tabellen, Feldtypen, Importreihenfolgen. Das ist wichtig, aber es ist nicht der Grund, warum Projekte kippen. Zwischen 30 % und 50 % der Migrationen scheitern nicht an fehlerhaften Datensätzen, sondern an organisatorischen Faktoren: fehlende Akzeptanz im Team, unklare Verantwortung, ein Cutover‑Termin, der niemandem richtig kommuniziert wurde.

Warum viele Migrationsprojekte trotz guter Planung scheitern — overview diagram

Die unterschätzte Wahrheit: Technische Sorgfalt allein rettet kein Projekt, wenn die Vertriebsleitung nicht von Anfang an eingebunden ist. Wer Fachbereiche erst in der Testphase einbezieht, sammelt genau dort die Kritik ein, die eigentlich in die Planungsphase gehört hätte. Das kostet Wochen.

Was ich Unternehmen deshalb rate: Behandeln Sie die Migration als Change‑Projekt mit technischer Komponente, nicht umgekehrt. Setzen Sie lieber eine Woche mehr für Kommunikation und Schulung an als für ein weiteres Testlauf‑Detail. Und seien Sie ehrlich mit der Komplexitätseinschätzung. Ein KMU mit zehn Jahren gewachsenen Sonderfeldern braucht keine zwei Wochen für den Wechsel, egal was der Projektplan verspricht.

— Thomas

Nach der Migration: Warum sich Funnel-tunnel für KMU lohnt

Nach dem Cutover beginnt die eigentliche Arbeit: Daten pflegen, Teams schulen, Prozesse an das neue System anpassen. Genau hier zeigt sich der Unterschied zwischen einer Insellösung und einer integrierten Plattform. Funnel-tunnel bringt Kontaktverwaltung, Terminbuchung, E‑Mail‑Marketing und Automatisierung in einem System zusammen, sodass Sie nach der Migration nicht sofort die nächste Schnittstelle bauen müssen.

Funnel-tunnel

Für einfache bis mittelkomplexe Migrationen, wie sie die meisten KMU durchführen, deckt die Plattform die zentralen Anforderungen bereits ab: Kontaktmanagement, Pipeline‑Tracking und Automatisierungsregeln lassen sich ohne separates Integrationsprojekt einrichten. Bei sehr spezialisierten Anforderungen, etwa branchenspezifischen Compliance‑Workflows mit mehreren externen Systemen, bleibt ein dediziertes CRM‑Projekt mit individueller Integration sinnvoller. Für den klassischen KMU‑Fall lohnt sich aber der direkte Wechsel.

Wer die Migration nicht selbst durchführen möchte, kann sie über den Funnel-tunnel Done4You‑Service komplett auslagern. Wer erst einmal die Plattform selbst kennenlernen will, startet am besten direkt über die Funnel-tunnel Startseite mit einer Testregistrierung.

Quellen

Empfehlung