Sie möchten Daten aus einem alten ERP-System exportieren und erhalten entweder ein schwer einschätzbares Angebot oder bereits mehrere Dateien. Trotzdem kann das neue ERP-Projekt damit noch nicht arbeiten. Die entscheidende Frage lautet deshalb nicht, ob überhaupt Daten geliefert wurden. Entscheidend ist, ob daraus ein migrationsfähiger Export entstanden ist: ein Datenbestand, der für ein klar benanntes Ziel vollständig, nachvollziehbar, wiederholbar und prüfbar bereitgestellt wird.
Ein großer Datenbankabzug kann technisch korrekt und dennoch für die Migration ungeeignet sein. Umgekehrt können sauber aufgebaute CSV-Dateien vollkommen ausreichen. Nicht das Dateiformat entscheidet, sondern der Weg vom benötigten Datensatz im neuen ERP-System bis zu den passenden Werten und Beziehungen im Altsystem.
Ein Datenabzug beantwortet eine andere Frage als ein Migrationsexport
Ein allgemeiner Datenabzug zeigt zunächst, welche Werte in ausgewählten Tabellen oder Dateien des Altsystems stehen. Das kann eine wichtige Grundlage sein. Für die Migration bleiben aber häufig vier Fragen offen: Welche Datensätze werden tatsächlich benötigt? Wie hängen die gelieferten Dateien zusammen? Welche Werte erwartet das neue System? Und lässt sich derselbe Export für die nächste Testmigration noch einmal unter denselben Regeln erzeugen?
Ein migrationsfähiger Export beantwortet diese Fragen für ein bestimmtes Zielobjekt. Mit Zielobjekt meinen wir hier die fachliche Einheit, die im neuen ERP-System befüllt werden soll, zum Beispiel einen Kunden, einen Lieferanten oder einen Artikel. Dadurch wird aus einer bloßen Dateilieferung ein belastbarer Teil des Migrationsprozesses.
Das ist auch der Grund, warum die Forderung „Bitte exportieren Sie alle Daten“ selten zu einem klaren Auftrag führt. „Alle Daten“ beschreibt weder den benötigten Umfang noch die Beziehungen oder Qualitätskriterien. Der alte ERP-Anbieter kann eine riesige Datenmenge liefern und den Auftrag formal erfüllen, während das Migrationsteam weiterhin nicht weiß, welche Werte in welche Zielfelder gehören.
Am Kundenstamm wird das Problem schnell sichtbar
Nehmen wir den Kundenstamm als Prüfobjekt. Je nach Altsystem können Name und Anschrift in einer zentralen Tabelle stehen, weitere Lieferadressen in einer zweiten, Zahlungsbedingungen in einer dritten und Vertriebszuordnungen in weiteren Tabellen. Eine Datei mit Kundennummer, Name und Anschrift sieht zunächst vollständig aus. Für die Migration kann sie trotzdem zu wenig enthalten.
Dann stellen sich etwa folgende Fragen: Ist die Kundennummer in allen Dateien derselbe verlässliche Schlüssel? Wie werden mehrere Adressen einem Kunden zugeordnet? Sind gesperrte oder nur historisch verwendete Kunden enthalten? Welche Zahlungskonditionen erwartet das Zielsystem als Code? Und ist klar, zu welchem Stichtag die Daten gezogen wurden?
Diese Fragen entstehen nicht, weil CSV ein ungeeignetes Format wäre. Sie entstehen, weil die fachlichen Zusammenhänge eines Kunden nicht automatisch mitgeliefert werden. Genau dafür braucht es eine zielgerichtete Analyse des alten ERP-Systems. Selbst bei lückenhafter Dokumentation lassen sich Tabellen, Felder und Beziehungen häufig aus Metadaten, vorhandenen Werten und wiederkehrenden Schlüsseln nachvollziehbar erschließen.
Sechs Fragen machen aus „Daten exportieren“ einen prüfbaren Auftrag
Bevor Sie einen Export beauftragen oder ein vorliegendes Angebot bewerten, sollte für ein ausgewähltes Zielobjekt geklärt sein, welches Ergebnis tatsächlich erwartet wird. Die folgenden sechs Fragen schaffen dafür einen belastbaren Rahmen:
| Zu klärende Frage | Erwartetes Ergebnis | Risiko ohne Klärung |
|---|---|---|
| 1. Welches Zielobjekt soll befüllt werden? | Benannte Datenobjekte und die dafür benötigten Informationen im neuen ERP-System | Es werden viele Werte geliefert, aber wichtige Zielfelder fehlen. |
| 2. Welche Datensätze gehören in den Umfang? | Nachvollziehbare Auswahlregeln, etwa nach Status, Zeitraum, Gesellschaft oder Werk | Historische, gesperrte oder irrelevante Datensätze werden ungeprüft übernommen – oder benötigte Datensätze fehlen. |
| 3. Wie hängen Tabellen und Dateien zusammen? | Eindeutige Schlüssel sowie dokumentierte Beziehungen zwischen Haupt- und Zusatzdaten | Adressen, Konditionen oder Zuordnungen lassen sich nicht sicher dem richtigen Stammsatz zuordnen. |
| 4. Was bedeuten Felder und Codes? | Feldbedeutungen, Datentypen, Einheiten und relevante Wertelisten | Ein technisch gültiger Wert wird fachlich falsch interpretiert. |
| 5. Wer übernimmt Auswahl und Transformation? | Klare Grenze zwischen Quellenauszug, fachlicher Zuordnung und Umwandlung in das Zielformat | Jede Seite erwartet, dass eine andere die fehlende Logik ergänzt. |
| 6. Wie wird der Export wiederholt und geprüft? | Gespeicherte Extraktionsregeln, Stichtag, Versionsstand und Kontrollsummen | Der nächste Testlauf liefert einen anderen Bestand, ohne dass die Abweichung erklärt werden kann. |
Wiederholbar bedeutet dabei nicht, dass jede Datei immer dieselbe Anzahl Zeilen haben muss. Zwischen zwei Testläufen können sich die Quelldaten verändern. Wiederholbar ist der Prozess dann, wenn dieselben definierten Auswahl- und Verknüpfungsregeln erneut angewendet werden und die Veränderungen nachvollzogen werden können.
Ein hoher Exportpreis ist nicht automatisch überzogen
Ein Angebot für den ERP-Datenexport kann überraschend hoch ausfallen. Daraus lässt sich allein noch nicht ableiten, ob der Preis angemessen ist. Hinter dem Wort „Export“ können sehr unterschiedliche Leistungen stehen: eine vorhandene Standardfunktion ausführen, historisch gewachsene Tabellen untersuchen, neue Abfragen entwickeln, Beziehungen dokumentieren, mehrere Testläufe begleiten oder die Daten bereits auf Anforderungen des neuen Systems vorbereiten.
Problematisch wird ein Angebot vor allem dann, wenn diese Ergebnisse nicht getrennt benannt sind. Eine Pauschale für „den Datenexport“ lässt sich weder fachlich prüfen noch sinnvoll mit einer anderen Vorgehensweise vergleichen. Fragen Sie deshalb nicht nur nach Stunden oder Dateianzahl, sondern nach den konkreten Arbeitsergebnissen:
- Für welche Datenobjekte wird geliefert?
- Sind Auswahlregeln, Schlüssel und Beziehungen Bestandteil der Leistung?
- Erhalten Sie zunächst einen prüfbaren Beispielbestand?
- Wie viele wiederholte Exporte für Tests und Go-live sind enthalten?
- Welche Dokumentation und welche Kontrollwerte werden übergeben?
- Wer klärt Abweichungen, wenn Zielanforderung und Quelldaten nicht zusammenpassen?
Erst mit diesen Angaben wird erkennbar, ob zwei Angebote dieselbe Leistung abdecken. Eine ausführlichere Einordnung dazu finden Sie in unserem Beitrag darüber, wie sich ein Angebot für eine ERP-Datenmigration prüfen lässt.
Drei Wege können zu einem brauchbaren Export führen
Welcher Weg sinnvoll ist, hängt vom Altsystem, den Zugriffsrechten und der Rollenverteilung im Projekt ab. Es gibt nicht nur eine richtige Variante.
1. Der bisherige ERP-Anbieter erstellt einen zielgerichteten Export
Dieser Weg kann sehr gut funktionieren, wenn der Anbieter das Altsystem und dessen kundenspezifische Nutzung kennt. Dafür muss er wissen, welche Zielobjekte und Informationen benötigt werden. Außerdem sollte vereinbart sein, ob er nur Quelldaten bereitstellt oder auch Auswahl, Verknüpfung und Aufbereitung übernimmt.
Der Vorteil liegt in der Systemkenntnis. Die Grenze zeigt sich dort, wo detailliertes Wissen über das neue ERP-System oder die dort erwarteten Importstrukturen erforderlich wird. Dieses Wissen muss dann vom Zielanbieter oder von einer verbindenden Migrationsrolle kommen.
2. Ein unabhängiger Spezialist liest die Datenbank kontrolliert aus
Bei einem zugänglichen Altsystem kann ein autorisierter, ausschließlich lesender Datenbankzugriff eine effiziente Alternative sein. Dabei werden keine Quelldaten verändert. Stattdessen lassen sich relevante Tabellen, Felder und Beziehungen untersuchen und anschließend gezielte SQL-Abfragen für die benötigten Datenobjekte entwickeln.
Das setzt voraus, dass der Zugriff technisch möglich, vertraglich erlaubt und sicher eingerichtet ist. Außerdem ersetzt der Datenbankzugriff keine fachliche Entscheidung. Der Fachbereich muss weiterhin festlegen und freigeben, welche Datensätze übernommen werden und wie mehrdeutige Werte behandelt werden.
3. Der Anbieter liefert Grunddaten und Metadaten, die Aufbereitung erfolgt getrennt
Wenn ein direkter Datenbankzugriff nicht möglich ist, kann der alte Anbieter wiederholbare Grundexporte bereitstellen. Zusätzlich werden die verfügbaren Feldbeschreibungen, Schlüssel und Beziehungen benötigt. Ein externer Migrationsspezialist verbindet diese Quellinformationen anschließend mit den Zielanforderungen und baut daraus die Transformations- und Prüflogik.
Diese Aufgabenteilung ist besonders dann sinnvoll, wenn der alte Anbieter seine eigene Datenstruktur gut kennt, aber nicht die Verantwortung für das neue Zielformat übernehmen soll. Die fachliche Zuordnung zwischen Quelle und Ziel wird im Datenmapping und in den Transformationsregeln festgehalten. So bleibt sichtbar, welcher Quellwert wie in das neue System gelangt.
CSV kann vollkommen ausreichen
Für einen guten Migrationsexport braucht es nicht automatisch ein zusätzliches Migrationstool. CSV-Dateien sind leicht zu prüfen, weiterzuverarbeiten und in viele Importwerkzeuge einzulesen. Sie sind dann geeignet, wenn jede Datei eine klare Bedeutung hat, die Schlüssel und Beziehungen erhalten bleiben und die Erzeugung der Dateien dokumentiert sowie wiederholbar ist.
Ungeeignet wird CSV erst durch einen unklaren Inhalt: wechselnde Spalten, manuell zusammenkopierte Bestände, nicht erklärte Codes oder verlorene Beziehungen. Dasselbe Problem kann allerdings auch in einer Datenbank oder einem spezialisierten Werkzeug auftreten. Das Werkzeug macht den Datenweg nicht automatisch richtig; die nachvollziehbare Logik tut es.
Beginnen Sie mit einem Prüfobjekt statt mit dem vollständigen Datenbestand
Die Qualität eines Exportwegs lässt sich am besten an einem repräsentativen Zielobjekt prüfen. Dafür wird zunächst festgelegt, welche Informationen das neue ERP-System für dieses Objekt braucht. Anschließend wird ein Beispielbestand aus dem Altsystem geliefert, mit seinen Zusatzdaten verbunden und bis in eine testbare Importdatei geführt.
Dieser kleine Durchlauf beantwortet früh die wichtigen Fragen: Reichen die Zugriffsrechte? Sind die Beziehungen erkennbar? Fehlen fachliche Informationen? Lässt sich die Extraktion erneut ausführen? Und können Quellbestand, aufbereitete Datei und Importergebnis miteinander abgeglichen werden?
Erst danach wird derselbe Weg auf weitere Datenobjekte übertragen. Dadurch wird nicht die gesamte Migration vorab im Detail geplant. Aber die Projektleitung erkennt, ob sie lediglich Dateien einkauft oder einen kontrollierten Datenweg erhält. Das macht Kosten, Verantwortlichkeiten und Risiken wesentlich besser vergleichbar.
Die entscheidende Leistung liegt zwischen Quelle und Ziel
Der bisherige ERP-Anbieter kennt sein System. Der neue ERP-Anbieter kennt das Ziel und seine Importmöglichkeiten. Trotzdem bleibt häufig eine Lücke zwischen beiden Seiten: Jemand muss die konkrete Datenstruktur des Unternehmens untersuchen, die Zielanforderungen damit verbinden, Transformationsregeln umsetzen und das Ergebnis über mehrere Testläufe prüfen.
Genau an dieser Schnittstelle unterstützen wir als externer Dienstleister. Je nach Ausgangslage arbeiten wir mit bereitgestellten Exporten oder mit einem autorisierten, lesenden Zugriff auf das Altsystem. Wir führen Quellanalyse, Mapping, technische Aufbereitung und Prüfschritte zu einem nachvollziehbaren Migrationsweg zusammen. Welche Daten fachlich übernommen werden und ob das Ergebnis freigegeben wird, entscheidet weiterhin das Unternehmen.
Damit lautet die wichtigste Frage vor der Beauftragung nicht: „Wie bekommen wir möglichst alle Daten aus dem alten ERP-System?“ Sie lautet: „Welcher vereinbarte Weg liefert die benötigten Daten für jedes Zielobjekt vollständig, wiederholbar und prüfbar?“ Sobald diese Frage beantwortet ist, lässt sich auch beurteilen, welcher Anbieter welche Leistung übernehmen sollte und ob der dafür genannte Preis zum tatsächlichen Ergebnis passt.