Ein Datenmigrationstool kann für die ERP-Datenmigration ausreichen. Ist es tatsächlich vor allem ein Importtool, ersetzt es jedoch nicht automatisch die Arbeit, aus den Daten des Altsystems eine fachlich richtige, wiederholbar erzeugte und prüfbare Importdatei zu machen.
Genau diese Grenze wird nach einer Anbietervorführung leicht übersehen. Das neue ERP besitzt einen Datenmigrationsleitstand, eine Importmaske oder vorbereitete Excel- und CSV-Vorlagen. Eine Testdatei lässt sich hochladen. Fehler werden angezeigt. Damit scheint der technische Weg vorhanden zu sein.
Die entscheidende Frage taucht meist erst danach auf: Wer findet nun die richtigen Daten im alten System, führt zusammengehörige Informationen zusammen, ordnet sie der neuen Struktur zu und prüft nach dem Import, ob sie fachlich stimmen? Wenn dafür noch kein belastbarer Arbeitsweg existiert, ist nicht das Importtool das Problem. Es fehlt die Strecke bis zum Tool und vom technischen Import bis zum geprüften Ergebnis.
Reicht ein Importtool für die ERP-Datenmigration? Die kurze Antwort
Ja, ein Importtool kann als einziges Werkzeug auf der Zielseite völlig genügen. Das gilt besonders dann, wenn es vorbereitete Dateien zuverlässig prüft, simuliert und in das neue ERP lädt. Es reicht aber nur dann für das Gesamtvorhaben, wenn alle übrigen Aufgaben ebenfalls eindeutig gelöst sind:
- Die benötigten Quelldaten lassen sich vollständig und nachvollziehbar aus dem Altsystem bereitstellen.
- Für jedes benötigte Zielmerkmal ist geklärt, aus welchen alten Informationen es entsteht.
- Bereinigungen und Umwandlungen können bei jedem Testlauf nach denselben Regeln wiederholt werden.
- Die erzeugte Datei entspricht genau der aktuellen Importstruktur.
- Nach dem Laden werden Vollständigkeit, Werte und fachliche Verwendbarkeit geprüft.
Fehlt einer dieser Punkte, beantwortet das Importtool nur einen Teil der Datenmigration. Das ist kein Mangel des Werkzeugs. Ein Lastenaufzug ist schließlich auch dann gut, wenn er Güter zuverlässig ins richtige Stockwerk bringt. Er wählt aber nicht aus, welche Güter transportiert werden sollen, verpackt sie nicht passend und bestätigt nicht, ob am Ziel alles fachlich korrekt angekommen ist.
Der Import beginnt nicht im Importtool
Zwischen dem alten ERP-System und dem ersten erfolgreichen Upload liegen mehrere unterscheidbare Ergebnisse. Sie bilden eine Kette:
Quelldaten finden → Daten auswählen → Zielzuordnung entscheiden → Werte transformieren → Importdatei erzeugen → technisch laden → fachlich prüfen.
Die Zielzuordnung wird häufig als Mapping bezeichnet. Gemeint ist hier nicht nur eine Liste ähnlicher Feldnamen. Ein belastbares Mapping hält fest, welche Zielinformation benötigt wird, aus welchen Quellen sie entsteht und welche Umwandlung dafür gilt. Erst wenn diese Regel fachlich bestätigt und technisch wiederholbar umgesetzt ist, kann daraus eine verlässliche Importdatei entstehen.
Welche Teile dieser Kette ein konkretes Importtool unterstützt, hängt vom Produkt und seiner Einrichtung ab. Manche Werkzeuge übernehmen nur Dateien. Andere bieten zusätzliche Regeln, Staging-Bereiche oder Verbindungen zu bestimmten Quellsystemen. Deshalb sollte die Projektleitung nicht vom Namen „Datenmigrationstool“ auf den Leistungsumfang schließen, sondern jeden Übergang einzeln prüfen.
Auch die Herstellerdokumentation trennt diese Schritte. In den offiziellen Abläufen von SAP werden beispielsweise das Befüllen einer Vorlage mit Altdaten, die Bearbeitung offener Mappingaufgaben, Simulation, Fehlerkorrektur, Migration und anschließende Abstimmung mit der Quelle als eigene Tätigkeiten beschrieben. Bei SAP Business ByDesign wird ausdrücklich vorausgesetzt, dass der Kunde Daten aus seinen Altsystemen in die Migrationsvorlagen extrahiert. Das Werkzeug stellt damit einen kontrollierten Importweg bereit, nicht automatisch das Wissen über jede individuelle Quelle.
Ein Lieferantenstamm macht die Leistungsgrenze sichtbar
Nehmen wir ein vereinfachtes Beispiel. Das neue ERP erwartet für jeden Lieferanten eine eindeutige Nummer, Name und Anschrift, einen Status, Zahlungsbedingungen sowie gegebenenfalls mehrere Bankverbindungen. Die Importvorlage zeigt diese Zielspalten sauber an. Trotzdem liegt im Altsystem nicht zwangsläufig eine einzelne Tabelle mit genau dieser Struktur vor.
Die Anschrift kann auf mehrere Tabellen verteilt sein. Der Lieferantenstatus ergibt sich vielleicht erst aus einem Sperrkennzeichen und weiteren fachlichen Regeln. Zahlungsbedingungen werden im alten System mit internen Kürzeln gespeichert, während das neue ERP andere Codes verlangt. Bankverbindungen stehen in einer abhängigen Tabelle, in der zu einem Lieferanten mehrere Datensätze vorkommen können.
Das Importtool kann nun erkennen, dass ein Pflichtfeld leer ist oder ein übergebener Zielcode nicht existiert. Es weiß jedoch nicht von selbst:
- welche alten Lieferantensätze überhaupt in das neue System gehören,
- welche Tabellen und Beziehungen dafür ausgewertet werden müssen,
- welcher alte Zahlungsbedingungscode welchem neuen Code fachlich entspricht,
- wie gesperrte, doppelte oder unvollständige Lieferanten behandelt werden sollen,
- und ob nach dem Import alle freigegebenen Lieferanten samt Bankverbindungen vorhanden sind.
Das Beispiel ist bewusst vereinfacht; die tatsächlichen Strukturen unterscheiden sich je nach ERP-System. Es zeigt aber, warum eine erfolgreiche Testdatei mehr voraussetzt als das Ausfüllen sichtbarer Spalten. Jemand muss die gewachsene Quelllogik verstehen, fachliche Entscheidungen vorbereiten und daraus einen reproduzierbaren Datenstand erzeugen.
Was ein ERP-Importtool typischerweise gut leistet
Ein gutes Importtool ist für die Zielseite sehr wertvoll. Es kennt die unterstützten Migrationsobjekte, akzeptierten Dateistrukturen und technischen Pflichtfelder. Je nach Produkt kann es Zielwerte prüfen, Zuordnungsaufgaben bereitstellen, eine Beladung simulieren, fehlerhafte Datensätze protokollieren und den eigentlichen Import kontrolliert ausführen.
Gerade diese Nähe zum Zielsystem spricht dafür, das vorgesehene Standardwerkzeug für die Beladung zu verwenden. Unser Beitrag zum SAP Migration Cockpit erläutert diese Rolle für SAP ausführlicher.
Die Stärke des Importtools liegt also darin, vorbereitete Daten nach den Regeln des neuen Systems entgegenzunehmen. Die Grenze liegt dort, wo individuelle Quellsystemkenntnis, unternehmensspezifische Entscheidungen oder eine durchgängige Prüfung über Quelle, Datei und Zielsystem erforderlich werden.
Fünf Übergaben zeigen, welche Arbeit trotz Migrationstool bleibt
Statt nur nach einer Funktionsliste zu fragen, sollte die Projektleitung fünf konkrete Übergaben prüfen. An jeder Übergabe muss ein benanntes Ergebnis entstehen.
1. Vom Altsystem zu den benötigten Quelldaten
Kann das Unternehmen die benötigten Datenobjekte mit ihren Beziehungen gezielt bereitstellen? Ein pauschaler Datenbankexport oder eine Sammlung vorhandener Excel-Dateien ist noch keine belastbare Quelle. Benötigt werden abgegrenzte, erklärbare Datenbestände, die sich für spätere Testläufe erneut erzeugen lassen.
2. Von der Quelle zur fachlichen Zielzuordnung
Ist für jedes benötigte Zielfeld belegt, aus welcher Quelle es stammt und welche fachliche Regel gilt? Ähnliche Namen sind dafür kein ausreichender Nachweis. Entscheidend ist die Bedeutung: Ein altes Sperrkennzeichen kann beispielsweise eine andere Wirkung haben als der im neuen ERP vorgesehene Status.
3. Von der Entscheidung zur wiederholbaren Transformation
Transformation bedeutet hier die technische Umsetzung der beschlossenen Regel. Dazu gehören etwa Wertübersetzungen, Formatänderungen, Zusammenführungen, Auswahlbedingungen und berechnete Zielwerte. Werden diese Schritte bei jedem Testlauf manuell in Excel wiederholt, können unbemerkt unterschiedliche Versionen entstehen. Eine nachvollziehbare SQL-Abfrage oder ein vergleichbarer kontrollierter Prozess macht denselben Stand erneut erzeugbar.
4. Von der Transformation zur aktuellen Importdatei
Entspricht die Datei genau der gegenwärtigen Zielstruktur? Importvorlagen können sich während eines ERP-Projekts ändern. Deshalb müssen Mapping, Transformationslogik und Dateiversion zusammenpassen. Andernfalls wird ein technisch korrekter Datenstand in eine veraltete Vorlage geschrieben.
5. Vom erfolgreichen Upload zum fachlich richtigen Ergebnis
Ein grünes Importprotokoll bestätigt zunächst, dass das Zielsystem die Daten technisch annehmen konnte. Es beweist noch nicht, dass alle vorgesehenen Datensätze angekommen sind, Beziehungen erhalten blieben und die Daten im Geschäftsprozess richtig funktionieren. Dafür braucht es einen Vergleich zwischen Quelle, erzeugter Datei und Zielsystem sowie eine fachliche Prüfung durch die zuständigen Mitarbeiter.
Oracle beschreibt Datenmigration in seinem ERP-Projektleitfaden entsprechend als Folge aus Quellenuntersuchung, Zuordnung, Extraktion, Transformation, Laden, Vergleich von Quelle und Ziel sowie Tests. Die eigentliche Leistung besteht also in der verbundenen Strecke – nicht allein im letzten technischen Schritt.
So prüfen Sie das Importtool, bevor die Arbeit intern hängen bleibt
Eine allgemeine Frage wie „Kann das Tool Datenmigration?“ führt leicht zu einer allgemeinen Antwort. Aussagekräftiger ist ein Durchstich mit einem repräsentativen Datenobjekt. Dafür sollte die Projektleitung den ERP-Anbieter und das interne Team bitten, den Weg an einem konkreten Beispiel zu zeigen:
- Startpunkt benennen: Beginnt der gezeigte Ablauf mit einer fertigen Importdatei, einer Quelltabelle oder einer direkten Verbindung zum Altsystem?
- Quellarbeit sichtbar machen: Wer identifiziert die benötigten Tabellen, Felder, Beziehungen und Auswahlbedingungen?
- Entscheidungen zuordnen: Wer bereitet fachliche Mappingfragen vor, und wer muss sie im Unternehmen freigeben?
- Wiederholung testen: Wie wird nach einer Regeländerung eine neue vollständige Datei erzeugt, ohne die vorherigen Schritte manuell nachzubauen?
- Prüfnachweis verlangen: Wie wird nach dem Import belegt, dass Anzahl, Werte, Beziehungen und fachliche Nutzung stimmen?
Nach diesem Durchstich sollte nicht nur eine Produktfunktion bekannt sein. Es muss eine Liste konkreter Lieferergebnisse mit Verantwortlichen vorliegen: Quellabzug, Mappingstand, Transformationslogik, versionierte Importdatei, Importprotokoll und fachliche Freigabe.
Falls der ERP-Anbieter vor allem Zielstruktur, Vorlage und Import verantwortet, kann das vollkommen vertragsgerecht sein. Der Beitrag Reicht der ERP-Anbieter für die Datenmigration? hilft dabei, diese Leistungsgrenze separat zu klären.
Vier naheliegende Reaktionen – und wann sie trotzdem sinnvoll sind
Das Kundenteam wird im Importtool geschult. Eine Schulung ist richtig, wenn interne Mitarbeiter das Werkzeug langfristig bedienen sollen. Sie vermittelt jedoch nicht automatisch die Struktur des Altsystems, fachliche Zielregeln oder verfügbare Kapazität für wiederholte Datenläufe. Bedienkompetenz und Migrationsumsetzung sind zwei verschiedene Anforderungen.
Die Importvorlage wird gemeinsam in Excel befüllt. Für kleine, überschaubare Datenmengen oder einmalige manuelle Ergänzungen kann das der einfachste Weg sein. Bei mehreren Testläufen, zusammenzuführenden Tabellen und vielen Wertübersetzungen wird die manuelle Bearbeitung jedoch schwer reproduzierbar. Dann sollte zumindest die wiederkehrende Transformation automatisiert und dokumentiert werden.
Der ERP-Anbieter soll sämtliche offenen Arbeiten übernehmen. Das kann funktionieren, wenn diese Leistung vereinbart ist und der Anbieter ausreichend Quellsystemkenntnis sowie Kapazität besitzt. Bleibt sein Auftrag auf Zielsystem und Import begrenzt, löst die Erwartung allein die Lücke nicht. Dann braucht es einen ergänzenden Verantwortlichen für die Strecke vor dem Import.
Ein größeres zusätzliches Migrationstool wird beschafft. Ein solches Werkzeug kann bei vielen Quellen, zahlreichen Migrationswellen, umfangreicher Zusammenarbeit oder besonderen Nachweisanforderungen sinnvoll sein. Es sollte aber ein benanntes Problem lösen. Ein weiteres Tool entscheidet weder von selbst über den Migrationsumfang noch über die fachliche Bedeutung alter Werte. Mehr Funktionen ersetzen deshalb nicht automatisch fehlende Quellkenntnis, Entscheidungen oder Umsetzungskapazität.
Wann das Importtool tatsächlich ausreicht
Das bereitgestellte Importtool ist häufig genau die richtige Lösung, wenn das Projekt die übrige Strecke bewusst organisiert. Dafür müssen keine unnötigen Zusatzplattformen aufgebaut werden. Ein leichtgewichtiger Ablauf kann beispielsweise so aussehen:
- Die benötigten Daten werden gezielt und ausschließlich lesend aus dem Altsystem ermittelt und extrahiert.
- Mappingvorschläge verbinden Zielanforderungen mit belegten Quellfeldern und werden fachlich freigegeben.
- Die bestätigten Umwandlungen werden nachvollziehbar, etwa in SQL, umgesetzt.
- Aus demselben kontrollierten Stand entsteht für jeden Testlauf eine aktuelle Importdatei.
- Das Standardwerkzeug des Zielsystems übernimmt Prüfung, Simulation und Beladung.
- Technische Vergleiche und fachliche Tests bestätigen das Ergebnis.
Dieser Ansatz stellt nicht SQL gegen das Importtool. Beide erfüllen unterschiedliche Aufgaben: SQL oder ein vergleichbarer Transformationsprozess bereitet die individuellen Altdaten nachvollziehbar vor; das Importtool lädt sie über den vom ERP-System vorgesehenen Weg. Wann darüber hinaus eine zusätzliche Migrationsplattform sinnvoll ist, ordnet der Beitrag SAP-Migration ohne zusätzliches Tool ein.
Wann operative Unterstützung sinnvoll wird
Externe Unterstützung ist nicht schon deshalb erforderlich, weil ein Importtool Grenzen hat. Sie wird sinnvoll, wenn die intern verbleibenden Aufgaben wichtig, zeitkritisch und zugleich nicht ausreichend besetzt sind. Typische Hinweise sind:
- Die Importvorlage liegt vor, aber niemand kann die benötigten Quellinformationen zuverlässig zusammenstellen.
- Fachbereiche beantworten Einzelfragen, doch daraus entstehen keine dokumentierten und ausführbaren Regeln.
- Für jeden Testlauf werden Dateien erneut manuell aufgebaut.
- Importfehler werden einzeln korrigiert, ohne die Ursache im wiederholbaren Prozess zu beheben.
- Niemand kann Quelle, Exportdatei und Zielbestand durchgängig miteinander vergleichen.
Wir übernehmen in solchen Situationen nicht die fachlichen Entscheidungen des Unternehmens und ersetzen auch nicht die Zielsystemkompetenz des ERP-Partners. Wir können jedoch die Quellanalyse, belegte Mappingvorschläge, technische Transformationen, reproduzierbare Testdateien und Prüfungen als zusammenhängende operative Arbeit führen. Der Kunde entscheidet über Umfang, Regeln und Freigaben; der ERP-Anbieter verantwortet sein Zielsystem und den vereinbarten Importweg.
Wenn dagegen bereits ein gutes Konzept vorhanden ist, aber vor allem die Zeit zur Umsetzung fehlt, hilft die Einordnung Datenmigration: Beratung oder Umsetzung? bei der Wahl des passenden Leistungsumfangs.
Entscheidend ist nicht der Name des Tools, sondern die geschlossene Strecke
Ein Importtool kann die richtige und ausreichende Tür in das neue ERP-System sein. Es trägt die Daten jedoch nicht automatisch aus dem alten System bis zu dieser Tür und prüft nicht allein, ob sie im neuen Geschäftsprozess richtig angekommen sind.
Bevor die Projektleitung sich auf das Werkzeug verlässt, sollte sie deshalb einen repräsentativen Datenbestand vollständig verfolgen: von den belegten Quelldaten über Mapping und Transformation bis zur wiederholbaren Importdatei und fachlichen Prüfung. Sobald für jede Übergabe ein Ergebnis, ein Verantwortlicher und ausreichend Kapazität vorhanden sind, kann auch ein schlanker Standardweg sehr leistungsfähig sein.
Die bessere Frage lautet daher nicht nur: „Was kann unser Importtool?“ Sondern: „Wer schließt den Weg vor und nach dem Import?“