Die Datenmigration zwischen altem und neuem ERP-Anbieter gerät häufig an einer unscheinbaren Stelle ins Stocken: Der alte Anbieter erklärt, wo eine Information im Altsystem liegt. Der neue Anbieter nennt das benötigte Zielfeld und die zulässigen Werte. Beide Antworten können fachlich richtig sein. Trotzdem ist noch nicht entschieden, welcher alte Wert nach welcher Regel in welchen neuen Wert überführt werden soll.
Ein vereinfachter Abstimmungstermin kann deshalb so enden: „Das Sperrkennzeichen finden Sie im Kundenstamm“, sagt die alte Systemseite. „Wir benötigen im neuen ERP einen Kundenstatus mit den Ausprägungen aktiv, gesperrt oder inaktiv“, antwortet die neue Systemseite. Danach kennen alle Beteiligten Quelle und Ziel etwas besser – eine umsetzbare Regel gibt es aber weiterhin nicht.
Das Problem ist selten mangelnde Gesprächsbereitschaft. Zwischen der Beschreibung beider Systeme fehlt eine fachliche Entscheidung, die technisch umgesetzt und anschließend mit echten Daten geprüft werden kann. Genau diese Lücke muss die Projektleitung vor dem nächsten Termin sichtbar machen.
Datenmigration zwischen altem und neuem ERP-Anbieter: Warum zwei richtige Antworten nicht reichen
Der alte ERP-Anbieter kennt sein System. Er kann erläutern, in welchen Tabellen oder Exporten ein Kennzeichen vorkommt, welche Werte technisch gespeichert sind und welche Beziehungen bei einem Export berücksichtigt werden müssen. Der neue ERP-Anbieter kennt dagegen die Zielstruktur, Pflichtangaben, gültigen Codes und das Verhalten seines Importwegs.
Damit liegen zwei notwendige Systemantworten vor. Was noch fehlt, ist die Verbindung dazwischen:
| Vorliegende Information | Noch offene Frage |
|---|---|
| Das Altsystem führt ein Sperrkennzeichen, ein Datum der letzten Aktivität und verschiedene Kundengruppen. | Welche Kombination dieser Informationen bestimmt künftig den Kundenstatus? |
| Das neue ERP akzeptiert die Werte aktiv, gesperrt oder inaktiv. | Welche fachliche Bedeutung soll jeder Zielwert im Unternehmen haben? |
| Beide Anbieter können ihre jeweilige Systemlogik erklären. | Wer entscheidet über Grenzfälle, dokumentiert die Regel und prüft ihre Wirkung? |
Weder die alte noch die neue Systemseite sollte allein festlegen, ob beispielsweise ein seit drei Jahren nicht verwendeter, aber nicht gesperrter Kunde als „inaktiv“ gilt. Das ist eine fachliche Entscheidung des Unternehmens. Zugleich sollte der Fachbereich diese Entscheidung nicht aus einer unübersichtlichen Rohdatei heraus entwickeln müssen. Er braucht konkrete Fälle, verständliche Varianten und die Auswirkungen jeder Variante.
Erst danach entsteht eine Transformationsregel – also eine eindeutig wiederholbare Vorschrift, nach der die alten Informationen in den benötigten Zielwert umgewandelt werden. Ohne diese Regel bleibt die Abstimmung trotz richtiger Einzelaussagen technisch folgenlos.
Das eigentliche Problem liegt zwischen den Zuständigkeiten
In vielen ERP-Projekten ist grundsätzlich geklärt, wer das alte und wer das neue System betreut. Trotzdem fühlt sich niemand für den vollständigen Weg einer offenen Migrationsfrage verantwortlich. Der alte Anbieter liefert Wissen über die Quelle, aber nicht über den künftigen Prozess. Der neue Anbieter beschreibt sein Ziel, kennt aber die gewachsene Bedeutung der Altdaten nicht. Das Unternehmen besitzt das fachliche Wissen, hat jedoch oft weder die Zeit noch den technischen Überblick, beide Datenmodelle selbst miteinander zu verbinden.
Dadurch wird dieselbe Frage in mehreren Formen weitergereicht: als E-Mail an den alten Anbieter, als Spalte in einer Importvorlage, als Aufgabe für einen Key-User und später als Fehler im Testimport. Jede Übergabe enthält einen Teil der Wahrheit. Es fehlt jedoch ein gemeinsamer Arbeitsstand, in dem Quellbeleg, Zielanforderung, fachliche Entscheidung und technische Umsetzung zusammengehören.
Unser Beitrag über die Verantwortung bei der ERP-Datenmigration ordnet die Rollen im Gesamtprojekt ein. Hier geht es um den nächsten operativen Schritt: eine einzelne offene Frage so vorzubereiten, dass sie im Gespräch tatsächlich entschieden werden kann.
Was vor dem nächsten Anbietergespräch vorbereitet sein muss
Ein produktiver Termin beginnt nicht mit der allgemeinen Aufforderung, „das Mapping zu klären“. Mapping bezeichnet hier die nachvollziehbare Zuordnung der benötigten Zielinformationen zu ihren Quellen und den dafür notwendigen Umwandlungen. Für eine konkrete Mappingfrage sollten vor dem Gespräch sechs Dinge zusammengeführt werden:
- Die Zielanforderung: Welches Zielfeld oder welche Zielstruktur wird für welchen Geschäftsprozess benötigt? Welche Werte sind erlaubt, und wie wirken sie im neuen ERP?
- Die belegten Quellkandidaten: Welche alten Felder, Beziehungen oder Dateien könnten die Information liefern? Welche Werte und Kombinationen kommen in den vorhandenen Daten tatsächlich vor?
- Die heutige und die künftige Bedeutung: Was drücken die alten Kennzeichen im Arbeitsalltag aus, und welche Unterscheidung wird künftig benötigt?
- Ein konkreter Regelvorschlag: Wie könnten die Quellwerte in den Zielwert übersetzt werden? Bei Unsicherheit helfen zwei klar beschriebene Varianten mehr als eine offene Grundsatzfrage.
- Die genaue Entscheidung: Welche fachliche Frage muss beantwortet werden, wer darf sie verbindlich entscheiden und bis wann wird die Antwort für den nächsten Datenlauf gebraucht?
- Die spätere Prüfung: An welchen normalen Fällen und Ausnahmen lässt sich erkennen, ob die beschlossene Regel im Zielsystem richtig wirkt?
Diese Vorbereitung verändert den Charakter des Gesprächs. Statt zwei Systeme allgemein zu erläutern, prüfen die Beteiligten eine benannte Regel an sichtbaren Beispielen. Der Termin kann dann mit einer Entscheidung, einer gezielten Nachlieferung oder einer bewusst dokumentierten Restfrage enden. Alle drei Ergebnisse sind steuerbar; ein weiteres „Wir schauen noch einmal“ ist es nicht.
Wer liefert Fakten, wer entscheidet und wer setzt um?
Die Zuständigkeit richtet sich nicht danach, wer gerade die Besprechung organisiert. Sie folgt der Art der benötigten Antwort:
| Beteiligte Rolle | Beitrag zur offenen Migrationsfrage |
|---|---|
| Alter ERP-Anbieter oder Altsystemverantwortliche | Belegen Herkunft, technische Bedeutung, Beziehungen und mögliche Bereitstellung der Quelldaten. |
| Neuer ERP-Anbieter | Beschreibt Zielstruktur, Pflichtlogik, zulässige Werte, Importverhalten und fachliche Wirkung im neuen System. |
| Fachbereich des Unternehmens | Entscheidet, welche Bedeutung und Behandlung im künftigen Geschäftsprozess richtig ist, und prüft das Ergebnis. |
| ERP-Projektleitung | Sichert Entscheidung, Termin, Abhängigkeiten und den Bezug zum nächsten Teststand. |
| Datenmigrationsspezialist | Verbindet Quell- und Zielinformationen, bereitet Regelvarianten vor, dokumentiert die Entscheidung und setzt die freigegebene Regel wiederholbar um. |
Diese Aufteilung entlastet die Anbieter, ohne ihre Verantwortung zu verwischen. Der alte Anbieter muss nicht den neuen Prozess entwerfen. Der neue Anbieter muss nicht erraten, was ein historisches Quellkennzeichen bedeutet. Und die Projektleitung muss nicht selbst zwischen Datenbankstruktur, Importvorlage und fachlicher Sprache übersetzen.
Wenn noch unklar ist, welche Leistungen überhaupt im Auftrag des neuen ERP-Partners enthalten sind, hilft zunächst die Einordnung Reicht der ERP-Anbieter für die Datenmigration?. Eine bereits laufende Abstimmung zwischen beiden Systemseiten benötigt dagegen den hier beschriebenen verbindenden Arbeitsweg.
So wird aus der Besprechung ein umsetzbarer Migrationsstand
Ein Beschluss im Protokoll ist noch kein belastbarer Datenstand. Nach dem Termin muss die Entscheidung durchgängig in die Migrationsarbeit übernommen werden:
- Die Entscheidung wird präzise festgehalten. Nicht „Kundenstatus geklärt“, sondern die vollständige Regel einschließlich Ausnahmen, Gültigkeitsbereich und verantwortlicher Freigabe.
- Das Mapping wird aktualisiert. Zielinformation, Quellfelder, Wertübersetzung, offene Annahmen und Beispiele stehen an einer gemeinsamen Stelle. So bleibt nachvollziehbar, worauf die Regel beruht.
- Die Regel wird technisch umgesetzt. Aus der freigegebenen Beschreibung entsteht beispielsweise eine wiederholbare SQL-Transformation oder ein vergleichbarer kontrollierter Verarbeitungsschritt.
- Eine neue Datei wird erzeugt und geprüft. Normale Fälle, Grenzfälle und vereinbarte Ausnahmen müssen in den erwarteten Zielwert münden.
- Die Wirkung wird im Zielsystem bestätigt. Erst der Import und die fachliche Prüfung zeigen, ob die Regel nicht nur technisch korrekt berechnet wurde, sondern im neuen Prozess auch richtig funktioniert.
Genau deshalb reichen getrennte Gesprächsnotizen, Mappingtabellen und technische Aufgabenlisten nicht aus. Sie dürfen unterschiedliche Formate haben, müssen sich aber auf dieselbe Entscheidung und denselben Versionsstand beziehen. Andernfalls wird im nächsten Test möglicherweise noch die alte Regel verwendet, obwohl sich alle Beteiligten längst auf eine neue verständigt haben.
Wie fachliche Zuordnung, technische Regel und Prüfung zusammenhängen, beschreibt unser Beitrag über das Datenmapping im ERP-Projekt ausführlicher.
Am Kundenstatus wird die fehlende Verbindung sichtbar
Nehmen wir das vereinfachte Beispiel aus dem Einstieg. Das Zielsystem benötigt für jeden Kunden genau einen Status. Im Altsystem gibt es dafür nicht zwangsläufig ein gleichnamiges Feld. Stattdessen stehen dort möglicherweise ein Sperrkennzeichen, das Datum der letzten Aktivität und eine Kundengruppe. Die tatsächlichen Feldnamen, Werte und Zusammenhänge unterscheiden sich von System zu System; das Beispiel zeigt nur die Entscheidungslogik.
Der alte Anbieter kann nun erklären, wann das Sperrkennzeichen gesetzt wird und wo sich die letzte Aktivität technisch ermitteln lässt. Der neue Anbieter kann erläutern, welcher Zielstatus Bestellungen verhindert und welcher lediglich einen inaktiven Bestand kennzeichnet. Die offene Geschäftsfrage lautet jedoch: Soll ein lange nicht genutzter Kunde automatisch inaktiv werden? Welche Kundenarten sind davon ausgenommen? Hat eine manuelle Sperre immer Vorrang?
Der Datenmigrationsspezialist kann dafür die vorkommenden Kombinationen aus den Quelldaten auswerten und einen Regelvorschlag mit Fallzahlen und Beispielen vorbereiten. Der zuständige Fachbereich entscheidet anschließend über die gewünschte Bedeutung. Danach wird die Regel technisch umgesetzt und mit genau den Fällen geprüft, an denen ihre Wirkung sichtbar wird.
So wird aus drei zunächst getrennten Perspektiven ein gemeinsames Ergebnis:
Quellbeleg → Zielanforderung → fachliche Entscheidung → wiederholbare Transformation → geprüfter Zielwert.
Wenn die benötigte Quellinformation noch gar nicht zugänglich ist, beginnt die Arbeit einen Schritt früher. Der Beitrag Daten aus dem alten ERP-System exportieren zeigt, welche Fragen vor einer technischen Bereitstellung geklärt werden sollten.
Vier naheliegende Lösungen greifen zu kurz
Ein größeres Abstimmungsmeeting kann sinnvoll sein, wenn erstmals alle Perspektiven gesammelt werden müssen. Ohne eine vorbereitete Zielfrage, Quellbelege und Entscheidungsvarianten wächst jedoch vor allem die Zahl der Erklärungen. Mehr Beteiligte ersetzen keine entscheidungsfähige Vorlage.
Noch eine gemeinsame Tabelle hilft, wenn sie den verbindlichen Mappingstand führt. Entsteht dagegen neben der Importvorlage, dem Quellkatalog und den Aufgabenlisten nur eine weitere Datei, verteilt sich die Entscheidung auf noch mehr Orte. Entscheidend ist nicht das Format, sondern die eindeutige Verbindung zwischen Regel, Freigabe, Umsetzung und Test.
Der alte Anbieter erstellt den vollständigen Export kann ein guter Teilauftrag sein. Er löst aber nicht automatisch die Frage, welche Zielbedeutung die exportierten Informationen erhalten sollen. Ebenso wenig kann der neue Anbieter allein aus seiner Importvorlage ableiten, welche Kombination gewachsener Quelldaten fachlich richtig ist.
Die Projektleitung vermittelt selbst ist bei einzelnen Fragen durchaus praktikabel. Wird sie jedoch dauerhaft zur Übersetzerin zwischen Datenmodellen, Fachbereichen, Anbietern und technischen Aufgaben, fehlt ihr Zeit für Projektsteuerung und Entscheidungen. Spätestens dann ist nicht noch mehr Koordination, sondern operative Migrationsarbeit zwischen den Terminen erforderlich.
Wann ein unabhängiger Datenmigrationsspezialist die Lücke schließen kann
Eine zusätzliche verbindende Rolle ist besonders sinnvoll, wenn offene Fragen über mehrere Termine bestehen bleiben, die Anbieter jeweils auf ihre Systemgrenze verweisen oder aus einer fachlichen Antwort keine neue prüfbare Datei entsteht. Sie ersetzt weder den ERP-Partner noch die interne Entscheidung. Ihr Wert liegt darin, die notwendigen Beiträge so miteinander zu verbinden, dass daraus ein umsetzbarer und überprüfbarer Stand wird.
Wir beginnen dafür auf der Zielseite: Welche Information verlangt der neue Prozess, und welche Importstruktur muss bedient werden? Anschließend untersuchen wir die möglichen Quellen, bereiten belegte Mappingvorschläge und klar abgegrenzte Entscheidungsvarianten vor. Nach der fachlichen Freigabe setzen wir die Regel technisch um, erzeugen den nächsten Datenstand und machen das Ergebnis für Anbieter und Fachbereich prüfbar.
Die fachliche Entscheidung bleibt beim Unternehmen. Der neue ERP-Anbieter verantwortet sein Zielsystem und den vereinbarten Importweg. Der alte Anbieter oder die interne Systemseite liefert erforderliches Wissen und Zugänge zur Quelle. Wir übernehmen die operative Verbindung dazwischen – vom belegten Vorschlag bis zum wiederholbaren Test.
Auch die offiziellen Projektleitfäden der Hersteller beschreiben diese Verbindung als eigene Arbeit: SAP nennt die sorgfältige Zuordnung der Quellfelder zur Zielstruktur und klar definierte Datenverantwortung. Oracle ordnet das Datenmapping ausdrücklich als Brücke zwischen altem System und neuem ERP ein, bevor Daten übertragen und geprüft werden. In der Praxis muss jemand diese Brücke nicht nur benennen, sondern bis zur ausführbaren Regel bauen.
Ein gutes Anbietergespräch endet mit einer prüfbaren Regel
Wenn die Datenmigration zwischen altem und neuem ERP-Anbieter feststeckt, ist ein weiterer allgemeiner Abstimmungstermin selten die Lösung. Zuerst braucht die Projektleitung eine konkrete Zielfrage, belegte Quellkandidaten, die fachlich offenen Varianten, einen benannten Entscheider und einen vorgesehenen Test.
Dann können beide Anbieter genau das beitragen, was nur sie wissen. Das Unternehmen trifft die fachliche Entscheidung, ohne selbst Datenmodelle durchsuchen zu müssen. Und die beschlossene Regel fließt nachvollziehbar in Mapping, technische Umsetzung und den nächsten Datenlauf ein.
Ein gutes Anbietergespräch endet deshalb nicht nur mit Einigkeit, sondern mit einer prüfbaren Regel.