Das neue ERP-System ist ausgewählt, doch zum Altsystem existieren nur einzelne Excel-Listen, veraltete Feldbeschreibungen und das Wissen einiger langjähriger Anwender. Für die Projektleitung entsteht daraus eine heikle Frage: Lässt sich die Datenmigration seriös beginnen – oder muss zuerst das gesamte alte System dokumentiert werden?
Die kurze Antwort: Eine vollständige Altsystem-Dokumentation ist keine zwingende Voraussetzung. Benötigt werden jedoch ein autorisierter Zugang zu den relevanten Quelldaten, klare Anforderungen des Zielsystems und Fachpersonen, die die ermittelten Bedeutungen bestätigen können. Statt die gesamte Datenbank auf einmal verstehen zu wollen, sollte das Projekt ein repräsentatives Datenobjekt vom Ziel zurück zur Quelle untersuchen und daraus einen überprüfbaren Datenweg bauen.
Lückenhafte Dokumentation ist nicht dasselbe wie fehlende Daten
Wenn eine Feldbeschreibung fehlt, sagt das zunächst nur, dass die Bedeutung nicht sauber dokumentiert ist. Es sagt noch nicht, dass die benötigte Information im Altsystem fehlt. Sie kann unter einem anderen Namen gespeichert, auf mehrere Tabellen verteilt oder erst durch eine Beziehung zwischen Datensätzen erkennbar sein.
Diese Unterscheidung verändert den Projektstart. Die Aufgabe lautet nicht, aus unsicheren Dateinamen sofort Importdateien zu erzeugen. Zuerst muss geklärt werden, welche Information das Zielsystem benötigt und woran sie im Altsystem zuverlässig erkannt werden kann. Erst danach lässt sich entscheiden, ob die Daten vorhanden, ableitbar oder tatsächlich nicht verfügbar sind.
Auch die Aussage eines erfahrenen Anwenders bleibt dabei ein wichtiger Hinweis, aber noch kein technischer Nachweis. Anwender kennen Masken, Abläufe und Begriffe aus ihrem Tagesgeschäft. Die darunterliegenden Tabellen, Schlüssel und indirekten Verknüpfungen müssen sie dagegen nicht kennen. Genau diese beiden Perspektiven – fachliche Nutzung und technische Speicherung – müssen in der Datenmigration zusammengeführt werden.
Der Ausgangspunkt ist das Zielobjekt – nicht die gesamte Datenbank
Ein Altsystem mit mehreren tausend Tabellen vollständig zu analysieren, bevor die erste Migrationsfrage beantwortet wird, erzeugt viel Aufwand und wenig Orientierung. Wir beginnen deshalb mit einem priorisierten Datenobjekt, zum Beispiel dem Artikel-, Kunden- oder Lieferantenstamm. Es sollte wichtig genug sein, um echte Abhängigkeiten sichtbar zu machen, aber überschaubar genug, um den vollständigen Weg bis zu einer Testdatei zu durchlaufen.
Für dieses Objekt wird zuerst festgehalten, was im neuen ERP ankommen muss: benötigte Felder, Pflichtwerte, Beziehungen, zulässige Formate und fachliche Prüfkriterien. Anschließend wird rückwärts untersucht, aus welchen Tabellen, Feldern und Regeln diese Zielinformationen gewonnen werden können. So entsteht keine allgemeine Bestandsaufnahme, sondern eine Analyse mit einem klaren Ergebnis.
Welche Datenobjekte überhaupt in das neue System gehören, ist eine vorgelagerte Entscheidung. Der Beitrag „Datenmigration beim ERP-Wechsel: Welche Daten gehören ins neue System?“ zeigt, wie dieser Umfang abgegrenzt werden kann. Die Altsystemanalyse beantwortet danach die andere Frage: Wie lassen sich die ausgewählten Daten technisch und fachlich zuverlässig bereitstellen?
Vier Belegquellen ergeben gemeinsam ein belastbares Bild
Keine einzelne Quelle erklärt ein schlecht dokumentiertes Altsystem vollständig. Belastbar wird die Analyse erst, wenn technische Struktur, gespeicherte Werte, bisherige Nutzung und Zielanforderung zusammenpassen.
1. Datenbank-Metadaten zeigen die vorhandene Struktur
Metadaten sind hier die technischen Beschreibungen der Datenbank: Tabellen- und Feldnamen, Datentypen, Längen, Schlüssel, definierte Beziehungen und gegebenenfalls Kommentare. Sie zeigen, welche Strukturen vorhanden sind und welche Felder grundsätzlich miteinander verbunden sein könnten. Dabei gilt eine wichtige Grenze: Ein technischer Name oder eine deklarierte Beziehung beweist noch nicht die fachliche Bedeutung.
Der Zugriff sollte ausschließlich autorisiert, lesend und auf den vereinbarten Bereich begrenzt erfolgen. Ist ein direkter Datenbankzugriff nicht möglich oder vom Hersteller nicht vorgesehen, können freigegebene Exporte, Berichte, Schnittstellenbeschreibungen oder ein vorhandenes Data Dictionary dieselbe Analyse vorbereiten. Entscheidend ist nicht der Zugriffsweg, sondern die nachvollziehbare Herkunft der späteren Migrationsdaten.
2. Reale Wertemuster zeigen, wie Felder tatsächlich genutzt werden
Feldnamen können veraltet oder mehrdeutig sein. Deshalb werden ausgewählte Werte, Häufigkeiten, leere Einträge und Kombinationen untersucht. Ein Feld, das technisch wie ein Status aussieht, kann beispielsweise nur in bestimmten Geschäftsbereichen verwendet werden. Ein anderes Feld enthält vielleicht einen Schlüssel, der erst zusammen mit Mandant oder Werk eindeutig wird.
Solche Profile dienen nicht dazu, Unternehmensdaten unnötig zu kopieren. Sie sollen eine konkrete Hypothese prüfen: Welche Datensätze gehören zum Objekt, wodurch unterscheiden sie sich und welche Ausnahmen müssen später berücksichtigt werden?
3. Oberfläche und Prozess erklären den Nutzungskontext
Die bisherige ERP-Oberfläche bleibt trotz fehlender Dokumentation wertvoll. Wenn ein Keyuser zeigt, wo ein Wert angelegt, geändert und im Prozess verwendet wird, lässt sich die technische Spur gezielter verfolgen. Aus der Kombination von Bedienweg und Datenbankbefund entsteht eine fachlich plausible Erklärung, die anschließend ausdrücklich bestätigt werden kann.
4. Das Zielsystem entscheidet, welche Bedeutung gebraucht wird
Eine Quelltabelle ist nicht aus sich heraus migrationsrelevant. Erst das Zielobjekt legt fest, welche Inhalte, Beziehungen und Formate benötigt werden. Importvorlagen, Zieltabellen, Pflichtfelder und Validierungsregeln geben deshalb die Suchrichtung vor. Auf dieser Grundlage wird aus einer technischen Fundstelle eine konkrete Mapping- und Transformationsregel.
Verdeckte Beziehungen: Warum der gleiche Objektname nicht nötig ist
Besonders deutlich wird das bei zusammengesetzten Datenobjekten. Benötigt das neue ERP beispielsweise eine Stückliste, muss im Altsystem nicht zwingend eine Tabelle oder Maske mit dem Namen „Stückliste“ existieren. Vielleicht sind Artikel und Komponenten über Auftragspositionen, Varianten oder eine eigene Verknüpfungstabelle verbunden. Sind die benötigten Beziehungen zuverlässig vorhanden, kann daraus eine Zielstruktur aufgebaut werden.
Das ist jedoch keine Einladung zum Raten. Zunächst wird technisch nachvollzogen, welche Schlüssel die Datensätze verbinden und unter welchen Bedingungen die Beziehung gilt. Danach bestätigt der Fachbereich, ob diese Herleitung den bisherigen Geschäftsprozess tatsächlich abbildet. Erst wenn beides zusammenpasst, wird die Regel in einen reproduzierbaren Export oder eine Transformation übernommen.
Ein belastbares Datenmapping im ERP-Projekt dokumentiert deshalb nicht nur Quelle und Ziel. Es hält auch die fachliche Bedeutung, die Transformationsregel, das Prüfkriterium und noch offene Entscheidungen fest.
Drei Befunde entscheiden, wie das Projekt weitergehen kann
Nach der Analyse eines repräsentativen Datenobjekts sollte die Projektleitung nicht nur eine technische Beschreibung erhalten, sondern eine klare Entscheidungsvorlage.
| Befund | Was belegt ist | Sinnvoller nächster Schritt |
|---|---|---|
| Der Datenweg ist nachgewiesen | Quelle, Auswahl, Beziehungen, Transformation und Prüfkriterium sind nachvollziehbar. | Testexport erzeugen und das Objekt im Zielsystem prüfen. |
| Die technische Spur ist vorhanden, die Bedeutung aber offen | Relevante Tabellen und Werte sind gefunden, einzelne Regeln oder Ausnahmen brauchen eine Fachentscheidung. | Offene Fragen mit Beispieldatensätzen klären; noch keinen endgültigen Umfang oder Festpreis behaupten. |
| Eine notwendige Grundlage fehlt | Es gibt beispielsweise keinen autorisierten Datenzugang, keine Zieldefinition oder niemanden, der die fachliche Bedeutung bestätigen kann. | Den konkreten Blocker beseitigen, bevor weitere technische Umsetzung beauftragt wird. |
Diese Einteilung verhindert zwei Extreme: Das Projekt muss eine lückenhafte Dokumentation weder dramatisieren noch kleinreden. Es kann genau benennen, was bereits beweisbar ist, welche Entscheidung noch fehlt und welcher Aufwand als Nächstes sinnvoll ist.
Was eine externe Altsystemanalyse konkret liefern sollte
„Datenbank analysieren“ ist als Leistungsbeschreibung zu offen. Für ein klar abgegrenztes erstes Arbeitspaket sollten überprüfbare Ergebnisse vereinbart werden:
- ein technisches Quellenbild für das gewählte Datenobjekt mit relevanten Tabellen, Feldern, Schlüsseln und Beziehungen,
- eine dokumentierte Auswahlregel, welche Datensätze einbezogen oder ausgeschlossen werden,
- ein Mapping mit bestätigten Bedeutungen, Transformationsregeln und offenen Fachentscheidungen,
- ein reproduzierbarer, möglichst lesender Export- und Aufbereitungsweg,
- eine Testdatei im benötigten Zielformat sowie Prüfergebnisse und erkannte Ausnahmen,
- eine begründete Einschätzung, welche Erkenntnisse auf weitere Datenobjekte übertragbar sind und wo neue Analyse nötig bleibt.
Damit kauft das Unternehmen kein unbestimmtes Analyseversprechen, sondern einen ersten vollständigen Datenweg. Dieser Weg liefert zugleich eine bessere Grundlage für Aufwand, Termin und die nächsten Datenobjekte. Wie solche Ergebnisse und Lernschleifen im Angebot geregelt werden können, erläutert der Beitrag „ERP-Datenmigration beauftragen: Was ein belastbares Angebot konkret regeln muss“.
So bleibt der Einstieg leichtgewichtig
Für eine erste Einschätzung muss das Unternehmen keine vollständige technische Dokumentation nachbauen. Hilfreich sind stattdessen fünf konkrete Grundlagen: die Zielvorgaben für ein priorisiertes Datenobjekt, ein autorisierter Lese- oder Exportweg zum Altsystem, eine kleine Zahl repräsentativer Datensätze, ein erreichbarer fachlicher Ansprechpartner und ein vereinbartes Prüfergebnis im Zielsystem.
Wir würden auf dieser Basis nicht sofort die gesamte Migration schätzen. Zuerst führen wir das ausgewählte Objekt bis zu einem überprüfbaren Export oder Testlauf. Dadurch wird sichtbar, ob Tabellen und Beziehungen verständlich genug sind, welche fachlichen Entscheidungen fehlen und ob sich der technische Weg wiederholen lässt. Die frühe Analyse reduziert also nicht jede Unsicherheit, aber sie ersetzt diffuse Annahmen durch konkrete Befunde.
Die technische Analyse ersetzt nicht die fachliche Verantwortung
Auch eine sehr gründliche Datenbankanalyse kann nicht allein entscheiden, welche Bedeutung ein Feld im künftigen Geschäftsprozess haben soll. Diese Entscheidung bleibt beim Unternehmen und seinen Fachbereichen. Ebenso verantwortet der ERP-Partner die Anforderungen und Importwege des Zielsystems, sofern dies sein beauftragter Umfang ist.
Unsere Aufgabe als externer Datenmigrationsdienstleister kann dazwischen klar abgegrenzt werden: Wir machen die technische Herkunft sichtbar, bereiten belastbare Zuordnungen und Transformationen vor und führen die Ergebnisse so früh wie möglich in einen prüfbaren Datenlauf. So wird aus einem schlecht dokumentierten Altsystem kein blinder Risikoblock, sondern eine Reihe überprüfbarer Analyse- und Migrationsentscheidungen.