Im Altsystem sieht Kunde 4711 zunächst vollständig aus: Firmenname, Straße, Ort und Telefonnummer sind vorhanden. Im neuen ERP lässt sich der Datensatz sogar öffnen. Beim ersten Auftrag zeigt sich jedoch, was fehlt: Die Rechnung soll an die Zentrale gehen, geliefert wird an zwei Werke, der Ansprechpartner gehört nur zu einem Standort und für einen Vertriebsbereich gelten eigene Zahlungsbedingungen.
Den Kundenstamm zu migrieren bedeutet deshalb, je Kunde nicht nur eine Zeile zu übertragen, sondern Identität, Adressen, Ansprechpartner, Vertriebs- und Finanzdaten sowie ihre Beziehungen in der Zielstruktur wieder aufzubauen.
Erst wenn diese Teile zusammenpassen, kann der Kunde im neuen ERP tatsächlich verwendet werden – vom Angebot über Auftrag und Lieferung bis zu Rechnung und Zahlung.
Kundenstamm migrieren: Was gehört wirklich zu einem Kunden?
Der sichtbare Kundenbildschirm vermittelt leicht den Eindruck, es gebe einen einzigen Stammdatensatz. Technisch liegen die Informationen jedoch häufig auf mehreren Ebenen und in mehreren Tabellen. Das Zielsystem kann diese Ebenen zudem anders ordnen als das Altsystem.
Ein belastbarer Migrationsbestand kann unter anderem umfassen:
- die zentrale Identität mit Name, Rechtsform und Suchbegriffen,
- Rechnungs-, Liefer- und weitere Adressen samt Verwendungszweck,
- Ansprechpartner mit ihrer Zuordnung zum Unternehmen oder Standort,
- Vertriebsdaten für Organisationen, Bereiche oder Niederlassungen,
- Finanzdaten wie Zahlungsbedingungen, Mahnverfahren und Abstimmungslogik,
- Steuer- und Identifikationsnummern,
- Partnerrollen wie Auftraggeber, Warenempfänger oder Rechnungsempfänger,
- Sperren, Klassifikationen und Gültigkeiten,
- sowie die alte Kundennummer als nachvollziehbare Referenz.
Nicht jedes Unternehmen braucht jede dieser Ebenen. Entscheidend ist, welche Informationen die künftigen Geschäftsprozesse tatsächlich verwenden. Der Migrationsumfang wird daher vom Zielprozess her bestimmt und nicht von der Anzahl vorhandener Quellspalten.
Warum eine Kundenliste für die Migration meistens nicht genügt
Eine Excel-Liste mit einer Zeile pro Kunde kann für eine erste Übersicht hilfreich sein. Sie bildet aber nur Beziehungen ab, die sich ohne Verlust in genau diese Zeile drücken lassen. Sobald ein Kunde drei Lieferadressen oder mehrere Ansprechpartner besitzt, passt das Modell nicht mehr.
Dann entstehen typische Notlösungen: zusätzliche Spalten wie „Lieferadresse 2“, zusammengefügte Ansprechpartner in einem Textfeld oder mehrfach angelegte Kundenzeilen. Damit sieht die Datei vollständig aus, doch die fachliche Struktur geht verloren.
Das Problem wird beim Import sichtbar:
- Mehrere Adressen erzeugen versehentlich mehrere Kunden.
- Nur die erste Lieferadresse wird übernommen.
- Ansprechpartner landen als unstrukturierter Hinweis im Notizfeld.
- Zahlungsbedingungen gelten plötzlich für alle Organisationseinheiten gleich.
- Der Rechnungsempfänger kann nicht mehr vom Warenempfänger unterschieden werden.
Der Kundenstamm sollte deshalb als zusammenhängendes Datenobjekt mit mehreren untergeordneten Ebenen behandelt werden. Eine flache Datei kann weiterhin das Importformat sein. Sie darf aber nicht das fachliche Modell ersetzen.
Zuerst klären: Wer ist der Kunde im Zielsystem?
Bevor Tabellen und Felder zugeordnet werden, muss die Zielidentität feststehen. Manche Systeme führen einen Kunden direkt als Kundenkonto. Andere beginnen mit einem Geschäftspartner – also einem zentralen Datensatz für eine Firma oder Person – und ergänzen darauf die benötigten Kundenrollen.
Diese Unterscheidung beeinflusst mehrere Entscheidungen:
- Erhält eine rechtliche Einheit genau einen zentralen Datensatz?
- Werden Niederlassungen als eigene Kunden oder als Adressen geführt?
- Kann dasselbe Unternehmen zugleich Kunde und Lieferant sein?
- Werden Vertriebs- und Finanzrollen getrennt angelegt?
- Welche Nummer vergibt das Zielsystem, und wo bleibt die alte Kundennummer auffindbar?
Wer diese Fragen erst während des Imports beantwortet, vermischt technische Ladefehler mit offenen fachlichen Entscheidungen. Besser ist ein kleiner, bestätigter Zielprototyp: ein Kunde mit mehreren Adressen, einem Ansprechpartner, mindestens zwei Rollen und den benötigten Organisationsdaten. An ihm lässt sich früh erkennen, wie das Zielmodell wirklich funktioniert.
Welche Kunden sollen überhaupt migriert werden?
„Alle aktiven Kunden“ klingt eindeutig, ist es aber selten. Ein Aktivkennzeichen kann veraltet sein. Ein lange nicht bebuchter Kunde kann noch einen offenen Auftrag, einen Servicevertrag oder eine Gewährleistungsbeziehung besitzen. Umgekehrt kann ein formal aktiver Datensatz seit Jahren nicht mehr verwendet werden.
Ein belastbarer Scope kombiniert deshalb mehrere Kriterien:
- Geschäftsaktivität in einem vereinbarten Zeitraum,
- offene Aufträge, Forderungen, Reklamationen oder Servicefälle,
- künftige vertragliche oder operative Relevanz,
- Sperr-, Lösch- und Archivkennzeichen,
- rechtliche und interne Aufbewahrungsentscheidungen,
- sowie die bewusste Bestätigung durch Vertrieb und Finanzbereich.
Die fachlich Verantwortlichen entscheiden, welche Kunden im neuen System benötigt werden. Datenschutz- und Aufbewahrungsfragen gehören zu den dafür zuständigen Stellen im Unternehmen. Die Migration setzt diese bestätigten Regeln anschließend reproduzierbar um.
Wie ein belastbarer Umfang über mehrere Datenobjekte hinweg entsteht, zeigt der Beitrag Welche Daten beim ERP-Wechsel migriert werden sollten.
Rechnungs- und Lieferadressen brauchen ihren Verwendungszweck
Eine Adresse besteht nicht nur aus Straße, Postleitzahl und Ort. Für den Geschäftsprozess ist ebenso wichtig, wofür sie verwendet wird. Die gleiche Anschrift kann Standardadresse sein, während Rechnungen an eine andere Gesellschaft oder Lieferungen an mehrere Werke gehen.
Für jede Adresse sollte deshalb geklärt werden:
- Zu welcher Kundenidentität gehört sie?
- Ist sie Standard-, Liefer-, Rechnungs- oder Korrespondenzadresse?
- Für welche Organisation oder welchen Prozess gilt sie?
- Ist sie aktuell, künftig gültig oder abgelaufen?
- Welche alte Adressnummer verbindet sie mit Aufträgen und Belegen?
Ein häufiger Fehler besteht darin, dieselbe Firma wegen mehrerer Standorte mehrfach anzulegen. Das kann richtig sein, wenn tatsächlich getrennte rechtliche oder organisatorische Kundenkonten benötigt werden. Es darf aber nicht allein dadurch entstehen, dass das Importformat nur eine Adresse je Zeile zulässt.
Ansprechpartner sind eigene Datensätze – keine verlängerten Textfelder
Ein Ansprechpartner hat eine eigene Identität, Kommunikationsdaten und eine Beziehung zum Kunden. Diese Beziehung kann zusätzlich eine Funktion, einen Standort oder einen Gültigkeitszeitraum tragen. „Frau Müller, Einkauf, Werk Süd“ ist daher mehr als eine Textzeile am Kunden.
Bei der Migration werden mindestens drei Dinge getrennt:
- der Kundendatensatz,
- der Ansprechpartner mit Name und Kommunikationsdaten,
- die Zuordnung, die erklärt, für welchen Kunden, Standort oder Zweck die Person zuständig ist.
Das verhindert, dass ein Ansprechpartner mehrfach angelegt oder nach einem Stellenwechsel weiterhin dem falschen Standort zugeordnet wird. Gleichzeitig kann das Zielsystem intern neue IDs vergeben. Dann braucht die Migration eine Zuordnungstabelle von alter zu neuer ID, damit Beziehungen in einem späteren Ladeschritt korrekt hergestellt werden.
Vertriebsrollen und Organisationsdaten entscheiden über die Nutzbarkeit
Ein Kunde kann technisch vorhanden sein und trotzdem keinen Auftrag zulassen. Häufig fehlen dann nicht Name oder Adresse, sondern die organisatorischen Erweiterungen. Je nach Zielsystem gehören dazu beispielsweise Verkaufsorganisation, Vertriebsweg, Sparte, Niederlassung oder Mandant.
Auf dieser Ebene können weitere Regeln liegen:
- Auftrags-, Waren-, Rechnungs- und Zahlungsempfänger,
- Liefer- und Zahlungsbedingungen,
- Preis- oder Kundengruppen,
- Versand- und Toureninformationen,
- Sperren für Auftrag, Lieferung oder Faktura,
- sowie zuständige Vertriebsmitarbeiter.
Diese Werte dürfen nicht pauschal aus einem einzigen allgemeinen Kundenfeld abgeleitet werden. Sie werden je gültiger Organisationsebene gemappt. Fehlt im Altsystem eine klare Entsprechung, braucht es eine bestätigte Regel oder eine gezielte fachliche Ergänzung.
Finanzdaten dürfen nicht hinter Vertriebsdaten verschwinden
Auch der Finanzbereich nutzt den Kundenstamm. Zahlungsbedingungen, Mahnverfahren, Kontenzuordnungen, Steuermerkmale und gegebenenfalls Kreditinformationen bestimmen, wie Rechnungen und Zahlungseingänge verarbeitet werden.
Ein bequemer Standardwert kann hier besonders teuer werden. Werden beispielsweise alle Kunden auf dieselbe Zahlungsbedingung gesetzt, stimmen Fälligkeiten und Mahnläufe nach dem Go-live nicht mehr mit den vereinbarten Konditionen überein.
Für jedes relevante Finanzfeld ist daher festzuhalten:
- Aus welchem Quellwert stammt es?
- Auf welcher organisatorischen Ebene gilt es?
- Welche Zielwerte sind erlaubt?
- Wie werden alte Codes in neue Bedeutungen übersetzt?
- Wer bestätigt Ausnahmen und fehlende Werte?
Damit wird aus einer Feldzuordnung eine prüfbare fachliche Entscheidung. Ein Import, der technisch grün ist, kann diese Entscheidung nicht ersetzen.
Dubletten lassen sich nicht allein über gleiche Namen entscheiden
Zwei Kunden mit ähnlichem Namen können dieselbe Firma, zwei Standorte oder zwei rechtlich getrennte Einheiten sein. Umgekehrt können Schreibvarianten, frühere Namen oder unterschiedliche Nummern dieselbe Identität verdecken.
Vor dem Zusammenführen werden deshalb mehrere Merkmale betrachtet: Anschrift, Steuer- und Registerdaten, Kommunikationsdaten, Bankverbindung, organisatorische Nutzung und bestehende Belegbeziehungen. Anschließend bestätigt ein fachlich Verantwortlicher, ob tatsächlich eine Dublette vorliegt.
Wird zusammengeführt, braucht es eine eindeutige Zuordnung aller alten IDs zur neuen Ziel-ID. Sonst zeigen offene Aufträge, Rechnungen oder historische Nachweise später auf den falschen Kunden. Der gesonderte Beitrag Dubletten bei der ERP-Migration zusammenführen vertieft genau diese Beziehungssicherung.
Die Extraktion folgt dem Zielobjekt und nicht einer vermeintlichen Haupttabelle
Im Altsystem können Name und Standardanschrift in einer Tabelle liegen, Lieferadressen in einer zweiten, Ansprechpartner in einer dritten und Zahlungsbedingungen in weiteren organisationsbezogenen Tabellen. Ein Export der vermeintlichen Kunden-Haupttabelle liefert daher nur die Hülle.
Ein wiederholbarer Ablauf sieht anders aus:
- Die benötigten Zielstrukturen und Pflichtfelder werden je Ebene festgelegt.
- Für jedes Zielmerkmal wird die fachlich passende Quelle gesucht und belegt.
- Beziehungen zwischen Kunde, Adresse, Kontakt und Organisation werden über stabile Schlüssel verbunden.
- Codes, Formate und Vorgabewerte werden nach bestätigten Regeln transformiert.
- Die Zieltabellen oder Importdateien werden in der erforderlichen Reihenfolge erzeugt.
- Nach jedem Test werden Fehler und fachliche Rückmeldungen in dieselbe Logik zurückgeführt.
So lässt sich der Kundenbestand nach einer Korrektur erneut erzeugen, ohne wieder Zeilen manuell zu bearbeiten. Warum ein Datenexport mehr als eine Sammlung sichtbarer Felder sein muss, erläutert der Beitrag Daten aus einem alten ERP-System exportieren.
Die Ladefolge verhindert verwaiste Adressen und Kontakte
Untergeordnete Datensätze brauchen ihre übergeordnete Identität. Deshalb werden Kundenkern, Rollen, Organisationsebenen, Adressen, Ansprechpartner und weitere Beziehungen nicht in beliebiger Reihenfolge geladen.
Die konkrete Reihenfolge hängt vom Zielsystem ab. Häufig gilt jedoch:
- benötigte Referenz- und Organisationswerte bereitstellen,
- zentrale Kunden- oder Geschäftspartneridentität anlegen,
- Kundenrollen und Organisationsebenen ergänzen,
- Adressen samt Verwendungszweck zuordnen,
- Ansprechpartner und ihre Beziehungen aufbauen,
- anschließend offene Vorgänge mit den neuen Ziel-IDs verbinden.
Vergibt das Zielsystem IDs selbst, werden diese nach jedem Schritt zurückgelesen und in einer Zuordnungstabelle festgehalten. Diese Tabelle ist das Bindeglied für alle nachfolgenden Objekte.
So wird ein migrierter Kundenstamm geprüft
Eine erfolgreiche technische Verarbeitung ist nur der erste Nachweis. Die Prüfung sollte mehrere Ebenen verbinden:
- Umfang: Jeder freigegebene Quellkunde besitzt einen Zielkunden oder einen dokumentierten Ausschlussgrund.
- Vollständigkeit: Die erwartete Zahl an Adressen, Ansprechpartnern, Rollen und Organisationserweiterungen ist vorhanden.
- Beziehungen: Lieferadresse, Rechnungsempfänger, Kontakte und Partnerrollen zeigen auf die richtige Kundenidentität.
- Werte: Zahlungsbedingungen, Steuercodes, Sperren und Klassifikationen entsprechen den bestätigten Regeln.
- Prozess: Für ausgewählte Fälle funktionieren Angebot, Auftrag, Lieferung, Rechnung und Zahlung im Ziel.
Gesamtzahlen reichen dabei nicht aus. Zehn fehlende Lieferadressen können in einem Bestand mit zehntausend Kunden statistisch unauffällig sein und trotzdem einen wichtigen Standort blockieren. Deshalb werden zusätzlich kritische Fallgruppen geprüft: Kunden mit mehreren Adressen, mehreren Organisationen, abweichendem Rechnungsempfänger, mehreren Ansprechpartnern, Sperren, Sonderkonditionen und offenen Vorgängen.
Typische Fehlversuche beim Kundenstamm
- Eine Kundenliste als vollständigen Bestand behandeln: Adressen, Kontakte und Organisationsebenen fehlen.
- Jede Adresse als eigenen Kunden importieren: Eine rechtliche Identität wird unbeabsichtigt vervielfacht.
- Ansprechpartner in ein Notizfeld schreiben: Suche, Zuordnung und spätere Pflege funktionieren nicht strukturiert.
- Alle aktiven Kennzeichen ungeprüft übernehmen: veraltete Kunden kommen mit, operativ benötigte gesperrte Kunden fehlen.
- Fehlende Werte pauschal vorbelegen: Zahlungs- oder Vertriebslogik wird fachlich verändert.
- Alte Kundennummern verwerfen: Belege, Rückfragen und Übergangsprozesse verlieren ihre Referenz.
- Nur Importprotokolle prüfen: technisch geladene Kunden bleiben im Geschäftsprozess unbrauchbar.
Wer entscheidet – und wobei hilft externe Datenmigration?
Vertrieb und Kundenservice bestätigen Kundenumfang, Adressverwendung, Ansprechpartner und Vertriebsrollen. Der Finanzbereich verantwortet Zahlungs-, Steuer- und Mahninformationen. Datenschutz, Aufbewahrung und Löschung werden von den zuständigen internen Stellen entschieden. Das Zielsystemteam bestätigt Datenmodell, Pflichtfelder, Nummernlogik und Ladefolge.
Externe Datenmigrationsunterstützung kann die verteilten Quelldaten analysieren, Beziehungen belegen, das Mapping dokumentieren, wiederholbare Transformationen entwickeln und die Ergebnisse über Mengen-, Beziehungs- und Prozesstests nachweisen. Die fachlichen Entscheidungen bleiben sichtbar bei den dafür verantwortlichen Personen.
Ein Kunde ist erst migriert, wenn mit ihm gearbeitet werden kann
Ein gefülltes Namensfeld beweist noch keinen vollständigen Kundenstamm. Entscheidend ist, ob die richtige Identität mit den richtigen Adressen, Kontakten, Rollen und Konditionen verbunden ist – und ob die nachfolgenden Geschäftsprozesse diese Informationen korrekt verwenden.
Wenn Ihr Kundenstamm aus mehreren Tabellen, Standorten, Ansprechpartnern oder Organisationsebenen zusammengesetzt werden muss, können wir den tatsächlichen Migrationsbestand strukturiert ermitteln und daraus einen wiederholbaren, prüfbaren Zielaufbau entwickeln.