Zum Hauptinhalt springen
Blog

Wie bereitet man Daten für die Migration aus Excel oder einem alten CRM vor?

Vor dem Wechsel zu einem neuen CRM sollten alle Quellen gesichert, Regeln für Felder und Dubletten festgelegt und ein Testimport geprüft werden.
Zuletzt aktualisiert: 2026-10-30 14:00:00
Konzeptionelle Darstellung der Zuordnung und Prüfung von Tabellen- und CRM-Daten vor der Übernahme in ein Zielsystem.

Am Anfang steht eine unveränderte Kopie der Quelldaten und eine Liste aller Orte, an denen das Unternehmen Informationen speichert. Danach wird festgelegt, welche Daten übernommen werden, wie Kunden und Kontakte eindeutig erkannt werden, welche Felder einander entsprechen und wie Lücken oder Dubletten behandelt werden. Erst nach einem geprüften Testimport sollte der eigentliche Wechsel geplant werden.

Ein CSV-Export beweist weder Vollständigkeit noch Nutzbarkeit. Eine Kundenliste kann vorhanden sein, während Verknüpfungen zu Ansprechpartnern, Notizen, Dateien, Verlauf, Aufgaben oder Berechtigungen fehlen. Eine Migration ist daher mehr als das Verschieben von Tabellenzeilen.

Eine CSV-Datei ist nur eine Datenquelle

CSV wird häufig für den Austausch zwischen Tabellen und Systemen genutzt. Schon die Grundstruktur erfordert jedoch eine einheitliche Behandlung von Kopfzeilen, Trennzeichen, Zeilenenden sowie Werten mit Kommas oder Anführungszeichen. Programme können solche Dateien unterschiedlich erzeugen.

Wichtiger ist die fachliche Bedeutung. Das Feld `Kunde` kann einmal ein Unternehmen und an anderer Stelle eine Person meinen. `Status` kann für eine Verkaufsphase, einen Zahlungsstand oder einen aktiven Kontakt stehen. Ähnliche Feldnamen bedeuten nicht automatisch dasselbe.

Zusätzlich sind Daten außerhalb der Haupttabelle zu prüfen, zum Beispiel:

  • Ansprechpartner eines Unternehmens;
  • Notizen und Gesprächsverlauf;
  • Aufgaben, Termine und Erinnerungen;
  • Dokumente und Anhänge;
  • Bestellungen, Vorgänge oder Verkaufschancen;
  • Einwilligungen, Kontaktquellen und zuständige Mitarbeiter;
  • Werte in weiteren Tabellenblättern oder Dateien.

Soll das neue System diese Informationen nutzen, braucht jede Gruppe einen eigenen Übernahmeplan. Sichtbarkeit im alten CRM ist kein Beleg dafür, dass die Daten im Export enthalten sind.

1. Daten vor der Bereinigung sichern

Bewahren Sie den ursprünglichen Export oder die Sicherung so auf, dass niemand sie verändert. Notieren Sie Datum, Quellsystem, Umfang und verantwortliche Person. Bei mehreren Anwendungen oder Tabellen bleibt jede Quelle separat erhalten.

Bereinigen Sie niemals die einzige Kopie. Arbeiten Sie mit einer Arbeitsversion und protokollieren Sie Änderungen. So lassen sich Werte später mit dem Ursprung vergleichen und Entscheidungen nachvollziehen.

Klären Sie außerdem, ob Mitarbeiter das alte System weiter bearbeiten. Dauert die Vorbereitung mehrere Tage oder Wochen, ist der erste Export bald veraltet. Dann braucht der Plan einen letzten Export oder eine Übernahme der Änderungen, die seit der Testkopie entstanden sind.

Die Sicherungsmethode hängt vom System und den Berechtigungen ab. Ein Export aus dem Administrationsbereich enthält nicht zwangsläufig Datenbank, Dateien und vollständigen Verlauf. Der tatsächliche Umfang muss für die konkrete Lösung bestätigt werden.

2. Alle Quellen erfassen und verbindliche Werte festlegen

In vielen Unternehmen liegen Daten teils im CRM, teils in Tabellen und aktuelle Absprachen in E-Mails oder persönlichen Notizen. Benennen Sie diese Quellen, ihre Nutzer und die Person, die Widersprüche entscheidet.

2. Alle Quellen erfassen und verbindliche Werte festlegen
QuelleBeispielinhaltWird noch aktualisiert?Wer entscheidet bei Widersprüchen?
altes CRMUnternehmen, Kontakte, Vorgänge, Aufgaben und Verlaufja oder neinVerantwortlicher für Vertrieb oder Betreuung
Vertriebstabellezusätzliche Statuswerte, Telefonnummern und Kommentareja oder neinbenannter Datenverantwortlicher
BestellsystemBestellnummern, Werte und Bearbeitungsständeja oder neinVerantwortlicher für den Bestellprozess

Sind Werte in zwei Quellen verschieden, darf ein Importskript nicht stillschweigend wählen. Das Unternehmen braucht eine Regel, etwa dass das Bestellsystem für das letzte Bestelldatum gilt, während der zuständige Kundenbetreuer aus dem CRM übernommen wird.

3. Übernahme und Archiv trennen

Die Übernahme aller historischen Datensätze kann die Kosten erhöhen und das neue System unübersichtlich machen. Teilen Sie die Daten ein in:

  • aktive Datensätze für die tägliche Arbeit;
  • historische Daten, die als Nachweis verfügbar bleiben sollen;
  • ungeklärte Datensätze ohne eindeutigen Verantwortlichen, Status oder Zweck;
  • Dubletten, Testdaten und veraltete technische Einträge, die nicht automatisch kopiert werden sollten.

Archivierung bedeutet nicht, Daten ohne Entscheidung zu löschen. Es muss feststehen, wo sie verbleiben, wer Zugriff erhält und wie sie gefunden werden. Aufbewahrungsfristen und rechtliche Pflichten klärt die für die Daten verantwortliche Organisation.

4. Eine Feldzuordnung erstellen

Die Feldzuordnung beschreibt, wie jeder wichtige Quellwert im Zielsystem dargestellt wird.

4. Eine Feldzuordnung erstellen
QuellfeldBedeutungZielfeldUmwandlung oder RegelFehlender Wert
`company_name`Firmen- oder HandelsnameFirmennameLeerzeichen bereinigen, ursprüngliche Schreibweise behaltenzur Prüfung markieren
`salesperson`zuständige PersonBetreuermit freigegebener Benutzerliste abgleichenerst nach Entscheidung zuordnen
`stage`aktuelle VertriebsphasePipeline-Phaseüber ein abgestimmtes Wörterbuch übersetzenals unbekannt markieren

Die Zuordnung sollte Bedeutung, Format, Pflichtangaben, erlaubte Werte und den Umgang mit Lücken enthalten. Ebenso wichtig ist, wer die Regel freigibt. Ein Entwickler kann die Umwandlung umsetzen, sollte aber nicht selbst die fachliche Bedeutung widersprüchlicher Statuswerte bestimmen.

5. Identifikatoren und Beziehungen erhalten

Die Anzahl der Datensätze reicht als Nachweis nicht aus. Ein Unternehmen kann im neuen CRM vorhanden sein, während Kontakte, Notizen oder offene Vorgänge mit dem falschen Konto verknüpft sind.

Prüfen Sie stabile Identifikatoren. Namen, E-Mail-Adressen und Telefonnummern können sich ändern oder von mehreren Personen genutzt werden. Interne IDs sind oft besser, sofern sie eindeutig sind und zuverlässig exportiert werden.

Zu den wichtigen Beziehungen gehören:

  • Unternehmen und Ansprechpartner;
  • Kunde und Bestellungen oder Vorgänge;
  • Vorgang und Notizen oder Anhänge;
  • Datensatz und zuständiger Mitarbeiter;
  • Hauptunternehmen und Niederlassungen.

Vergibt das Zielsystem neue IDs, sollte eine Zuordnung von alten zu neuen Kennungen erhalten bleiben. Sie hilft bei der Fehlersuche und bei wiederholten Testimporten.

6. Regeln für Dubletten und Lücken festlegen

Eine Dublettenprüfung sollte mehrere Merkmale verwenden. Dasselbe Unternehmen kann unter Kurz- und Firmennamen vorkommen, während verschiedene Personen eine allgemeine Büroadresse teilen. Eine gleiche E-Mail-Adresse oder Telefonnummer ist ein Hinweis, aber nicht immer eine ausreichende Grundlage für automatisches Zusammenführen.

Definieren Sie getrennte Regeln für:

  • sichere Dubletten, die automatisch zusammengeführt werden dürfen;
  • wahrscheinliche Dubletten zur manuellen Prüfung;
  • ähnliche Datensätze, die getrennt bleiben müssen;
  • fehlende Werte, die leer bleiben dürfen;
  • fehlende Werte, die den Import verhindern;
  • Widersprüche, über die ein Verantwortlicher entscheidet.

Fehlende Informationen dürfen bei der Migration nicht erfunden werden. Unbestätigte Werte bleiben leer oder werden nach einer freigegebenen Regel zur Prüfung markiert.

7. Einen Testimport mit repräsentativen Daten durchführen

Testen Sie nicht nur saubere Datensätze. Die Stichprobe sollte typische und schwierige Fälle enthalten: fehlende Felder, Sonderzeichen, lange Notizen, Dubletten, mehrere Kontakte pro Unternehmen, Anhänge und seltene Statuswerte.

Der Test muss wiederholbar sein. Halten Sie Quellversion, Einstellungen, Umwandlungsregeln und Ergebnis fest. Nach einem Fehler werden Regel oder Quelldaten korrigiert und der Import in einer kontrollierten Umgebung erneut ausgeführt. Handkorrekturen im Zielsystem verdecken sonst das eigentliche Problem.

8. Das Ergebnis auf mehreren Ebenen prüfen

Prüfen Sie nach dem Testimport:

  1. Gesamtzahlen je Datensatzart;
  2. Pflichtfelder und geschäftskritische Angaben;
  3. Beziehungen zwischen Datensätzen;
  4. Wörterbücher, Statuswerte und Betreuer;
  5. Datumswerte, Telefonnummern, E-Mails und Zeichencodierung;
  6. vereinbarte Notizen, Dateien und Verlaufsdaten;
  7. repräsentative Fälle der Prozessverantwortlichen;
  8. ob Nutzer mit den übernommenen Daten tatsächlich arbeiten können.

An der Abnahme müssen Personen beteiligt sein, die Daten und Prozess kennen. Ein Vertriebsmitarbeiter erkennt einen falschen Betreuer oder Vorgangsstatus oft schneller als der Entwickler des Importers.

9. Wechsel und Abbruchmöglichkeit planen

Nach einem erfolgreichen Test werden Zeitpunkt des letzten Exports, Einschränkungen für Änderungen im alten System und die Abnahmeberechtigten festgelegt. Der Plan sollte beantworten:

  • wann Bearbeitungen im alten CRM enden;
  • ob Änderungen seit dem Test separat übernommen werden;
  • wie viel Zeit für die Kontrolle vorgesehen ist;
  • wer den Start im neuen System freigibt;
  • was bei nicht erfüllten Abnahmekriterien geschieht;
  • wie lange und in welchem Umfang Quelle oder Archiv erreichbar bleiben.

Eine Migration ist nicht immer ohne Unterbrechung möglich. Das hängt von beiden Systemen, dem täglichen Änderungsvolumen und den Austauschmöglichkeiten ab. Eine konkrete Umschaltzeit sollte erst nach Prüfung des Falls zugesagt werden.

10. Was sollte vor dem Gespräch mit einem Anbieter vorbereitet werden?

Zu Beginn ist keine vollständige Datenbank nötig. Bereiten Sie vor:

  1. Liste der Systeme, Tabellen und zusätzlichen Quellen;
  2. Bedeutung der Daten im Arbeitsalltag;
  3. wichtige Felder, Statuswerte und Beziehungen;
  4. ungefähre Anzahl von Datensätzen, Dateien und Anhängen;
  5. Aufteilung in aktive und archivierte Daten;
  6. bekannte Probleme mit Lücken, Formaten und Dubletten;
  7. gewünschten Termin und akzeptable Arbeitseinschränkungen;
  8. eine Person, die Datenentscheidungen treffen darf;
  9. Abnahmekriterien für Test und endgültige Migration;
  10. eine anonyme oder synthetische Strukturprobe.

Senden Sie über ein erstes Kontaktformular keine Passwörter, Schlüssel, echten Kundendaten oder Datenbankkopien. Zunächst genügen Situationsbeschreibung und sichere Strukturprobe. Ein geschützter Übertragungsweg kann später vereinbart werden.

Wenn noch unklar ist, ob Standard-CRM, Integration oder eigenes System passt, nutzen Sie den CRM-Lösungsplaner. Er strukturiert Anforderungen, untersucht aber keine hochgeladenen Daten und erstellt keine Migrationsschätzung.

Was zeigen frühere Projekte von Domin Software?

Im historischen Projekt HUB.ITM.PL entwickelten wir ein System, das Daten aus verschiedenen Buchhaltungsprogrammen las und in das von Subiekt GT und Subiekt nexo verwendete Format EDI++ überführte. Dadurch musste ein Buchhaltungsbüro weniger Rechnungen manuell erfassen. Das Projekt ist nicht mehr produktiv, weil sich Formate und Austauschbedingungen geändert haben. Es belegt Erfahrung mit der Zuordnung mehrerer Quellen, verspricht aber keine Kompatibilität mit heutigen Programmversionen.

Bei HUB-2-API importierte das System eine große Produktliste aus einer Tabelle und nutzte sie für eBay.de-Angebote, Bestellungen und eine API für drei Kunden in Frankreich. Es ging um Produkt- und Bestelldaten, nicht um Kundenmigration aus einem alten CRM. Der Fall zeigt dennoch, warum Quellstruktur und Zielregeln vor der Automatisierung bekannt sein müssen.

In beiden Projekten waren Bedeutung und Kontrolle der Daten wichtiger als das Dateiformat.

Häufige Fragen

Reicht ein Excel- oder CSV-Export für die Migration?

Meistens nicht. Grundfelder können enthalten sein, Beziehungen, Notizen, Verlauf, Anhänge, Wörterbücher und Identifikatoren müssen jedoch separat geprüft werden.

Müssen alle Daten aus dem alten CRM übernommen werden?

Nicht immer. Einige Informationen können in einem vereinbarten Archiv bleiben, während aktive Daten in das neue System wechseln. Daten- und Prozessverantwortliche sollten das freigeben.

Wie erkennt man doppelte Kunden und Kontakte?

Zuerst wird festgelegt, welche Merkmale eine sichere Dublette belegen und wie der Verlauf erhalten bleibt. Ähnliche Namen, eine gemeinsame E-Mail-Adresse oder Telefonnummer reichen nicht immer für automatisches Zusammenführen.

Was geschieht mit fehlenden oder widersprüchlichen Werten?

Für jedes wichtige Feld wird eine Regel benötigt. Der Wert kann zur Prüfung markiert, leer gelassen oder über ein freigegebenes Wörterbuch zugeordnet werden. Das System darf keine Informationen erfinden.

Lassen sich Notizen, Verlauf und Anhänge erhalten?

Manchmal. Das hängt von Export, API, Dateistruktur und Importmöglichkeiten des Zielsystems ab. Die Machbarkeit muss vor der Umfangsentscheidung geprüft werden.

Wie prüft man einen Testimport?

Vergleichen Sie Datensatzmengen, Schlüsselfelder, Beziehungen und Wörterbücher. Prüfen Sie repräsentative Fälle und ob Nutzer ihren Arbeitsprozess mit den Daten durchführen können.

Ist eine Migration ohne Betriebsunterbrechung möglich?

Das lässt sich ohne Prüfung beider Systeme nicht garantieren. Manchmal reichen kurze Änderungssperre und letzter Export, in anderen Fällen sind Übergangsphase oder zusätzliche Integration nötig.

Wie lässt sich eine Probe sicher für die Schätzung übermitteln?

Beginnen Sie mit einer Strukturbeschreibung und synthetischen oder anonymisierten Daten. Senden Sie keine Passwörter, Schlüssel, vollständige Datenbank oder echten Kundendaten über ein gewöhnliches Formular.

Den nächsten Schritt wählen

Wenn Sie die Lösung noch auswählen, nutzen Sie den CRM-Lösungsplaner. Er hilft bei der Entscheidung zwischen Standard-CRM, Integration, Zusatzmodul und eigenem System.

Ist der Prozess bereits bekannt und wird eine passende Lösung benötigt, sehen Sie sich individuelle CRM- und ERP-Systeme an. Umfang und Preis der Migration setzen eine Prüfung von Quellen, Beziehungen, Datenmenge und Zielsystem voraus.

Sollen altes und neues System parallel laufen oder regelmäßig Daten austauschen, nutzen Sie den Systemintegrationsplaner und prüfen Sie unser Angebot für Systemintegrationen und APIs. Einmalige Migration und dauerhafte Integration sind unterschiedliche Projekte.

Quellen