Im alten ERP-System sehen Sie mehrere tausend Tabellen. Einige Namen wirken vertraut, andere bestehen nur aus Abkürzungen. Eine Kundennummer taucht an vielen Stellen auf, doch niemand kann sicher sagen, welche Tabelle den Kundenstamm enthält und welche lediglich Aufträge, Adressen oder historische Zustände speichert. Wer jetzt einfach alle ähnlich benannten Tabellen exportiert, erhält viele Daten – aber noch kein belastbares Migrationsobjekt.
Um in einer ERP-Datenbank die richtigen Tabellen für eine Datenmigration zu finden, sollten Sie nicht bei Tabellennamen beginnen. Ausgangspunkt ist das fachliche Objekt, das im neuen System gebraucht wird. Danach werden reale Beispieldatensätze, Datenbank-Metadaten und Beziehungen zusammengeführt. Erst wenn sich die gefundene Struktur mit bekannten Fällen aus dem Altsystem erklären lässt, ist daraus ein belastbarer Export ableitbar.
ERP-Datenbank: Tabellen finden heißt ein Geschäftsobjekt rekonstruieren
Ein Geschäftsobjekt ist hier zum Beispiel ein Kunde, Lieferant, Artikel oder eine Stückliste. In der Oberfläche erscheint ein Kunde häufig als ein zusammenhängender Datensatz. In der Datenbank kann er jedoch auf mehrere Tabellen verteilt sein: allgemeine Stammdaten, Adressen, Ansprechpartner, Zahlungsbedingungen, Sperrkennzeichen und kundenspezifische Zusatzfelder.
Die Aufgabe lautet deshalb nicht: „Welche Tabelle heißt Kunde?“ Die bessere Frage ist: „Aus welchen Tabellen und Beziehungen entsteht der vollständige Kundendatensatz, den das Zielsystem erwartet?“ Dieser Wechsel der Blickrichtung verhindert, dass eine scheinbar passende Haupttabelle vorschnell zum vollständigen Export erklärt wird.
1. Zuerst die Zielstruktur des Datenobjekts festlegen
Bevor jemand die Datenbank durchsucht, sollte klar sein, welche Informationen das neue ERP-System für das betreffende Objekt verlangt. Dafür eignen sich die Importvorlage, die Feldbeschreibung des Zielsystems und ein fachlich verständlicher Beispieldatensatz.
Beim Lieferanten könnten unter anderem Name, Anschrift, Steuerdaten, Zahlungsbedingungen, Bankverbindung und Einkaufsorganisation benötigt werden. Diese Liste ist noch kein fertiges Mapping. Sie bildet aber einen Suchrahmen: Für jedes benötigte Zielmerkmal muss später entweder eine belastbare Quelle, eine fachlich freigegebene Ableitung oder eine bewusst zu schließende Lücke vorhanden sein.
Ohne diesen Rahmen wird eine Datenbankanalyse schnell zu einer Inventur ohne Entscheidung. Man kennt anschließend mehr Tabellen, weiß aber weiterhin nicht, welche davon für die Migration relevant sind.
2. Die Datenbank nur lesend inventarisieren
Der erste technische Schritt ist eine Metadatenübersicht. Metadaten beschreiben die Struktur der Datenbank: Tabellen, Spalten, Datentypen, Schlüssel, Ansichten und hinterlegte Beziehungen. Dabei werden noch keine Geschäftsdaten verändert.
Bei einer SQL-Server-Datenbank lassen sich solche Informationen über die Systemkataloge auslesen. Sie zeigen beispielsweise, welche Tabellen und Spalten vorhanden sind und welche Fremdschlüssel hinterlegt wurden. Ein Fremdschlüssel ist eine technische Verbindung, über die ein Datensatz auf einen anderen verweist. Für andere Datenbanksysteme gibt es vergleichbare Kataloge.
Die Inventur sollte mindestens erfassen:
- Tabellen- und Spaltennamen samt Datentypen,
- Primärschlüssel und eindeutige Indizes,
- hinterlegte Fremdschlüssel und Ansichten,
- ungefähre Datensatzmengen,
- Spalten mit auffälligen Namensmustern wie Kunden-, Artikel- oder Adressnummern.
Diese Informationen liefern Kandidaten, aber noch keinen Beweis. Gerade ältere oder individuell entwickelte ERP-Systeme bilden Beziehungen nicht immer als technische Fremdschlüssel ab. Dann muss die fachliche Verbindung zusätzlich aus Datenmustern und bekannten Geschäftsfällen abgeleitet werden.
3. Einen bekannten Datensatz als Anker verwenden
Eine der schnellsten Möglichkeiten, eine unbekannte ERP-Datenbank zu verstehen, ist ein fachlich bekannter Anker. Das kann ein Lieferant mit zwei Anschriften, ein Artikel mit einer besonderen Mengeneinheit oder eine Stückliste mit mehreren Ebenen sein. Der Fachbereich kennt diesen Fall aus der Oberfläche und kann sagen, was daran sichtbar sein muss.
Nun wird geprüft, wo seine eindeutigen Merkmale in der Datenbank vorkommen. Eine Lieferantennummer allein kann zu viele Treffer liefern. Aussagekräftiger ist eine Kombination aus Nummer, Name, Postleitzahl und einem besonderen Status. So lässt sich meist eine Haupttabelle eingrenzen. Von dort führen Schlüsselwerte zu Adress-, Kontakt- oder Organisationstabellen.
Der Anker erfüllt zwei Aufgaben. Er macht die technische Suche schneller und verbindet sie mit fachlicher Bedeutung. Eine Tabelle ist nicht deshalb richtig, weil ihr Name plausibel klingt, sondern weil sie einen bekannten Geschäftsfall vollständig und widerspruchsfrei erklären kann.
4. Beziehungen belegen – nicht nur gleichnamige Spalten verbinden
In gewachsenen Datenbanken heißen zwei Spalten manchmal gleich, obwohl sie unterschiedliche Bedeutungen haben. Umgekehrt können dieselben fachlichen Schlüssel völlig verschieden benannt sein. Ein Join – also die Verbindung zweier Tabellen in einer Abfrage – darf deshalb nicht allein auf ähnliche Spaltennamen gestützt werden.
Eine belastbare Beziehung ergibt sich aus mehreren Hinweisen:
- einem hinterlegten Fremdschlüssel oder einer dokumentierten Beziehung,
- passenden Datentypen und Wertebereichen,
- einer plausiblen Anzahl zugeordneter Datensätze,
- bekannten Beispielen aus der ERP-Oberfläche,
- und einem fachlich verständlichen Ergebnis nach der Verknüpfung.
Besonders wichtig ist die Anzahl der Treffer. Wenn ein Lieferant zwei Anschriften und drei Ansprechpartner besitzt, entstehen bei einer unbedachten Verbindung sechs Ergebniszeilen. Das ist mathematisch korrekt, aber als Lieferantenexport möglicherweise falsch. Deshalb muss vor jedem Join geklärt werden, ob die Beziehung eins zu eins, eins zu mehreren oder mehrfach zu mehreren ist und welche Zielstruktur daraus entstehen soll.
5. Hauptdaten, Ergänzungen und Historie auseinanderhalten
Hat das Team mehrere passende Tabellen gefunden, folgt die fachliche Einordnung. Nicht jede Tabelle mit einer Kundennummer gehört in den Kundenstamm. Einige enthalten aktuelle Stammdaten, andere verweisen auf Aufträge, Belege, Protokolle oder alte Änderungsstände.
Für jedes Tabellenfeld sollte deshalb geklärt werden:
- Beschreibt es den aktuellen Zustand des Datenobjekts?
- Ist es eine abhängige Ergänzung wie Adresse, Bankverbindung oder Text?
- Handelt es sich um einen Code, dessen Bedeutung in einer weiteren Tabelle steht?
- Gehört es zu einem offenen Vorgang statt zum Stamm?
- Ist es nur ein historischer oder technischer Protokolleintrag?
Diese Unterscheidung entscheidet über den späteren Umfang der ERP-Datenmigration. Wer Historie, aktuelle Stammdaten und offene Bewegungen vermischt, erzeugt zwar eine große Datei, aber keine klare Entscheidungsgrundlage.
6. Aus den Fundstellen ein prüfbares Quellmodell bauen
Das Ergebnis der Analyse sollte nicht in einzelnen SQL-Abfragen oder persönlichen Notizen verschwinden. Pro Datenobjekt braucht es ein kleines Quellmodell. Darin werden die verwendeten Tabellen, Schlüssel, Filter und Beziehungen so beschrieben, dass eine zweite Person den Weg nachvollziehen kann.
Für einen Lieferanten könnte die Struktur beispielsweise lauten: Haupttabelle über interne Lieferanten-ID, aktuelle Anschrift über Adressreferenz, Zahlungsbedingungen über einen Code und Ansprechpartner über eine eigene Zuordnungstabelle. Zusätzlich wird sichtbar festgehalten, welche Kandidatentabellen geprüft und bewusst ausgeschlossen wurden.
Dieses Modell ist die technische Grundlage für das spätere Datenmapping im ERP-Projekt. Das Mapping beantwortet dann, wie die gefundenen Quellinformationen in die Felder und Regeln des neuen Systems überführt werden.
7. Mit Mengen, Stichproben und Gegenbeispielen prüfen
Ein plausibler Beispieldatensatz reicht noch nicht. Die gefundene Tabellenstruktur muss auch für andere Ausprägungen funktionieren. Dazu gehören ein einfacher Standardfall, ein Datensatz mit mehreren abhängigen Einträgen, ein gesperrter oder inaktiver Fall und ein bewusst schwieriger Sonderfall.
Zusätzlich helfen drei quantitative Prüfungen:
- Ausgangsmenge: Wie viele fachlich relevante Datensätze zeigt das Altsystem oder eine bekannte Auswertung?
- Verknüpfungsmenge: Entstehen durch die Tabellenbeziehungen unerwartete Vervielfachungen oder Lücken?
- Ergebnismenge: Wie viele Datensätze erfüllt der endgültige Auswahlfilter, und lassen sich Abweichungen erklären?
Ein Gegenbeispiel ist dabei oft wertvoller als ein weiterer Normalfall. Wenn die vermeintliche Kundenstruktur bei einem Kunden mit zwei Rechnungsanschriften auseinanderfällt, wurde eine wichtige Beziehung noch nicht verstanden.
Warum typische Abkürzungen nicht funktionieren
Alle Tabellen vollständig exportieren
Ein vollständiger Datenbankabzug kann zur Sicherung sinnvoll sein. Er beantwortet aber nicht, welche Tabellen ein fachliches Objekt bilden, welche Stände aktuell sind oder wie Beziehungen im Zielsystem dargestellt werden müssen. Die eigentliche Analyse wird nur verschoben.
Nur nach verständlichen Tabellennamen suchen
Gerade ältere ERP-Systeme nutzen Abkürzungen, technische Namen oder individuell gewachsene Bezeichnungen. Relevante Daten können zudem in Erweiterungstabellen liegen. Namenssuche ist ein Einstieg, kein Beleg.
Eine einmalige Excel-Datei manuell zusammensetzen
Damit kann ein erster Eindruck entstehen. Sobald der nächste Testlauf neue Daten enthält oder sich eine Regel ändert, beginnt die Arbeit jedoch von vorn. Eine belastbare Lösung beschreibt Beziehungen und Auswahlregeln reproduzierbar, damit derselbe Datenweg erneut ausgeführt werden kann.
Direkt in der Produktivdatenbank arbeiten
Für die Analyse und Extraktion genügt lesender Zugriff. Schreibende Änderungen an einer ERP-Produktivdatenbank gehören nicht zu diesem Vorgehen. Sie erhöhen das Risiko für Datenkonsistenz, Supportfähigkeit und laufende Prozesse, ohne die Migration fachlich besser zu machen.
Woran Sie erkennen, dass die richtigen ERP-Tabellen gefunden sind
Die Analyse ist nicht abgeschlossen, sobald eine Abfrage Daten liefert. Ein belastbares Ergebnis erfüllt mehrere Bedingungen:
- Das fachliche Datenobjekt ist aus Sicht des Zielsystems beschrieben.
- Jedes benötigte Merkmal besitzt eine belegte Quelle oder eine sichtbare Lücke.
- Tabellenbeziehungen sind technisch und anhand realer Fälle geprüft.
- Mehrfachbeziehungen führen nicht unbemerkt zu doppelten Datensätzen.
- Filter für aktive, offene oder auszuschließende Daten sind fachlich bestätigt.
- Die Abfrage lässt sich beim nächsten Testlauf reproduzierbar ausführen.
Erst danach sollte daraus der migrationsfähige Export aus dem alten ERP-System entstehen. So bleibt der Export nicht nur technisch lesbar, sondern bildet tatsächlich das Datenobjekt ab, das im neuen System arbeitsfähig werden soll.
Wann externe Unterstützung sinnvoll wird
Externe Unterstützung ist besonders hilfreich, wenn die Datenbank umfangreich oder schlecht dokumentiert ist, der frühere ERP-Anbieter nicht mehr verfügbar ist oder intern zwar Datenbankzugriff, aber keine Zeit für die systematische Rekonstruktion vorhanden ist.
Die fachlichen Entscheidungen bleiben trotzdem beim Unternehmen: Welche Datensätze werden benötigt? Welche Sonderfälle sind richtig? Welche Ergebnisse dürfen freigegeben werden? Operativ kann ein Datenmigrationsspezialist die Metadaten inventarisieren, Tabellenbeziehungen prüfen, ein Quellmodell erstellen und daraus wiederholbare SQL-Exporte vorbereiten. Dadurch wird aus einer unbekannten Datenbank Schritt für Schritt eine nachvollziehbare Migrationsquelle – ohne die Produktivdaten zu verändern und ohne das Projekt mit einem vollständigen Datenbankdump allein zu lassen.