Der neue ERP-Anbieter wartet auf Importdateien, doch der bisherige Dienstleister antwortet nicht mehr. Vielleicht fehlt ihm die Kapazität, der frühere Ansprechpartner ist nicht mehr erreichbar oder die Zusammenarbeit ist nach einem Streit praktisch beendet. Dann beginnt die interne IT häufig selbst, Tabellen zu suchen und Daten zu exportieren. Das ist ein nachvollziehbarer erster Schritt. Damit daraus eine belastbare Migration wird, braucht das Unternehmen jedoch einen unabhängig ausführbaren Weg von einem autorisierten Zugriff auf das Altsystem bis zu wiederholbaren, geprüften Exporten.
Ein Datenexport ohne alten ERP-Anbieter ist grundsätzlich möglich, wenn das Unternehmen technisch und organisatorisch auf seine Altdaten zugreifen darf und kann. Ob dafür ein direkter Datenbankzugriff, eine wiederherstellbare Sicherung oder vorhandene Anwendungs- und Standardexporte ausreichen, hängt vom System ab. Der entscheidende Punkt ist deshalb nicht, möglichst schnell alle Tabellen zu kopieren. Zuerst muss geklärt werden, welcher Zugriff tatsächlich vorhanden ist und welche Informationen das neue ERP-System benötigt.
Wenn der Anbieter ausfällt, sind die Daten nicht automatisch verloren
Der bisherige ERP-Anbieter und das alte ERP-System sind zwei verschiedene Dinge. Der Dienstleister kann nicht mehr verfügbar sein, während die Anwendung, der Datenbankserver und regelmäßige Sicherungen weiterhin im Unternehmen betrieben werden. In dieser Lage fehlt zunächst Unterstützung und Systemwissen – nicht zwingend der technische Zugriff auf die Daten.
Anders sieht es bei einem vollständig durch den Anbieter betriebenen Cloud-System aus. Dort kann das Unternehmen zwar mit der Anwendung arbeiten, besitzt aber möglicherweise keinen unmittelbaren Zugriff auf Datenbank oder Sicherungen. Dann muss zuerst geklärt werden, welche vertraglich und technisch vorgesehenen Exportmöglichkeiten, Schnittstellen und Herausgabeverfahren bestehen. Ein Ausfall der Kommunikation ist keine Berechtigung, Zugriffsschutz zu umgehen.
Diese Unterscheidung verändert die nächsten Schritte. Bei vorhandenem, autorisiertem Zugriff kann eine unabhängige Quellanalyse beginnen. Fehlt der Zugriff vollständig, ist das Projekt noch nicht bei der Datenaufbereitung angekommen. Dann muss zunächst eine belastbare technische und gegebenenfalls vertragliche Zugangsgrundlage geschaffen werden.
Die erste Frage lautet nicht: Wer schreibt das SQL?
Bevor jemand Abfragen entwickelt, sollte die IT-Leitung den tatsächlich verfügbaren Ausgangsstand festhalten. Läuft die Anwendung noch? Auf welchem Server befindet sich die Datenbank? Gibt es aktuelle Sicherungen und lassen sie sich kontrolliert wiederherstellen? Welche Standardexporte kann die Anwendung erzeugen? Sind Datenmodell, Feldbeschreibungen oder frühere Schnittstellenunterlagen vorhanden?
Besonders hilfreich ist ein autorisierter, lesender Datenbankzugriff. Lesend bedeutet, dass Tabellen und Werte untersucht und abgefragt werden können, ohne Datensätze im Altsystem zu verändern. Für eine Migration sollte diese Analyse nach Möglichkeit nicht unkontrolliert auf der produktiven Datenbank stattfinden. Eine abgestimmte Arbeitskopie oder eine geeignete, abgesicherte Analyseumgebung verringert das Risiko, den laufenden Betrieb zu beeinträchtigen.
Erst wenn diese Grundlage geklärt ist, lässt sich seriös entscheiden, ob SQL der richtige Weg ist. Bei relational aufgebauten Altsystemen können SQL-Abfragen transparent und wiederholbar Tabellen verbinden, Werte umformen und Exportdateien erzeugen. Fehlt dagegen jeder Datenbankzugriff oder stellt das System Informationen nur über fest definierte Schnittstellen bereit, muss die Vorgehensweise daran angepasst werden.
Die ersten gefundenen Tabellen lösen noch nicht das Migrationsproblem
Ein interner Administrator findet häufig schnell eine Tabelle mit Artikeln, Kunden oder Lieferanten. Dieser Erfolg ist wichtig, weil er zeigt, dass die Daten grundsätzlich zugänglich sind. Gleichzeitig kann er den Umfang der restlichen Aufgabe verdecken.
Ein fachliches Datenobjekt besteht je nach Altsystem aus mehreren Tabellen. Schlüssel können nur indirekt zusammenpassen, bestimmte Bedeutungen ergeben sich erst aus Wertemustern und historisch gewachsene Feldverwendungen weichen möglicherweise von alten Beschreibungen ab. Außerdem kennt die interne IT zwar das Altsystem, aber nicht automatisch alle Pflichtfelder, Codes und Importregeln des neuen ERP-Systems.
Besonders deutlich wird das bei einer Stückliste. Das Zielsystem erwartet möglicherweise eine klar aufgebaute Struktur aus Artikel, Komponenten und Mengen. Im Altsystem existiert jedoch keine Tabelle mit dem Namen „Stückliste“. Trotzdem können die benötigten Beziehungen vorhanden sein, etwa über Komponenten, Auftragspositionen oder kundenspezifische Verknüpfungen. Wer nur nach einem gleichnamigen Objekt sucht, würde die Daten vorschnell für nicht vorhanden halten.
Deshalb beginnt eine unabhängige Analyse nicht mit der gesamten Datenbank, sondern mit einer konkreten Anforderung des Zielsystems. Wie sich auch bei lückenhafter Dokumentation Tabellen, Werte und verdeckte Beziehungen erschließen lassen, beschreiben wir ausführlicher im Beitrag Altes ERP-System ablösen: Datenmigration trotz lückenhafter Dokumentation.
Ein relevantes Zielobjekt zeigt, ob der unabhängige Weg funktioniert
Statt sofort sämtliche Altdaten zu exportieren, sollte das Projekt ein priorisiertes und ausreichend repräsentatives Zielobjekt vollständig bearbeiten. Dafür wird zunächst festgehalten, welche Informationen und Strukturen das neue ERP-System für dieses Objekt erwartet. Anschließend wird untersucht, in welchen Tabellen und Feldern diese Informationen im Altsystem liegen und wie ihre Beziehungen aufgebaut sind.
Aus dieser Analyse entsteht eine erste ausführbare Extraktion. Sie führt die benötigten Quellen zusammen, setzt eindeutig beschlossene Transformationen um und erzeugt eine Datei, die sich gegen Quelle und Zielanforderung prüfen lässt. Wird dieselbe Logik für den nächsten Testlauf erneut ausgeführt, ist außerdem erkennbar, welche Änderungen aus neuen Quelldaten und welche aus einer überarbeiteten Regel stammen.
Dieses eine Objekt beantwortet mehr als ein vollständiger Rohabzug. Es zeigt, ob der Zugriff ausreicht, ob Beziehungen nachvollzogen werden können, welche Mitwirkung der Fachbereiche benötigt wird und ob der neue ERP-Anbieter die Zielanforderungen konkret genug beschrieben hat. Erst danach lässt sich der Aufwand für weitere Objekte belastbarer einschätzen.
Vier Zugriffssituationen führen zu unterschiedlichen nächsten Schritten
Die Datenbank ist erreichbar und ein lesender Zugriff kann eingerichtet werden. Dann kann ein unabhängiger Spezialist das Schema, relevante Tabellen, Werte und Beziehungen untersuchen. Die Abfragen sollten pro Zielobjekt dokumentiert, versioniert und mit Kontrollwerten versehen werden. Dadurch entsteht kein einmaliger Notexport, sondern ein Prozess, der sich für Testmigrationen wiederholen lässt.
Es gibt eine Datenbanksicherung, aber keine geeignete Analyseumgebung. In diesem Fall muss zuerst geprüft werden, wie die Sicherung autorisiert und technisch sauber in einer getrennten Umgebung wiederhergestellt werden kann. Eine bloße Sicherungsdatei ist noch kein nutzbarer Export. Sie kann aber die entscheidende Grundlage sein, wenn Datenbanktyp, Version, Zugang und Wiederherstellung geklärt sind.
Es stehen nur Exporte aus der Anwendung zur Verfügung. Auch damit kann eine Migration beginnen. Zunächst wird geprüft, welche Objekte, Schlüssel und Zusatzinformationen die vorhandenen Funktionen liefern. Fehlen Beziehungen, können mehrere Standardexporte, Berichte oder Schnittstellendaten miteinander kombiniert werden. Für einzelne Objekte reicht das möglicherweise aus; bei komplexen Strukturen bleiben jedoch Grenzen, die früh sichtbar gemacht werden müssen.
Es gibt weder Datenbankzugriff noch Sicherung noch ausreichende Exportfunktion. Dann lässt sich die technische Migration nicht seriös beginnen. Das Unternehmen muss zuerst mit den zuständigen internen, vertraglichen und gegebenenfalls rechtlichen Stellen klären, wie ein erlaubter Datenzugang hergestellt werden kann. Kein Datenmigrationsdienstleister kann fehlende Berechtigungen durch einen technischen Umweg ersetzen.
Warten und selbst exportieren können sinnvoll sein – aber nur bis zu einer klaren Grenze
Auf eine Antwort des alten Anbieters zu warten ist vernünftig, wenn ein verbindlicher Rückmeldetermin besteht und dieser noch zum Projektplan passt. Unbegrenztes Warten wird dagegen selbst zum Projektrisiko. Die Datenmigration verliert Zeit, obwohl möglicherweise längst ein unabhängiger Zugriff vorbereitet werden könnte.
Auch ein vollständiger Datenbankabzug kann sinnvoll sein, etwa um einen aktuellen technischen Bestand zu sichern oder eine spätere Analyse zu ermöglichen. Er beantwortet aber noch nicht, welche Daten ins neue System gehören und wie die Tabellen zusammenhängen. Für diese Bewertung gelten anschließend dieselben Anforderungen wie bei jedem anderen migrationsfähigen Export aus einem alten ERP-System.
Der interne Administrator wiederum ist häufig die wichtigste Person, um Server, Sicherungen, Benutzerzugänge und Besonderheiten des Altsystems zu verstehen. Daraus folgt nicht, dass er zusätzlich sämtliche Quellanalysen, Mappings, Transformationen und Testexporte neben dem Tagesgeschäft umsetzen sollte. Seine Kenntnis sollte gezielt genutzt werden, ohne aus der Notsituation eine dauerhafte Alleinverantwortung zu machen.
Eine manuelle Neuanlage kann für wenige Datensätze oder tatsächlich fehlende Informationen wirtschaftlich sein. Sie sollte aber erst entschieden werden, nachdem geprüft wurde, ob die benötigten Werte und Beziehungen in anderer Form im Altsystem vorhanden sind. Sonst entsteht vermeidbarer Aufwand, während verwertbare Informationen ungenutzt bleiben.
Was eine unabhängige Quellanalyse konkret liefern sollte
Eine externe Unterstützung ist in dieser Situation nur dann entlastend, wenn sie nicht bei einer Bestandsaufnahme und neuen Aufgabenliste endet. Für ein priorisiertes Zielobjekt sollten konkrete, weiterverwendbare Ergebnisse entstehen:
- ein dokumentierter und freigegebener Zugriffsweg auf die relevanten Quelldaten,
- die identifizierten Tabellen, Felder, Schlüssel und Beziehungen,
- eine nachvollziehbare Zuordnung zu den Anforderungen des Zielsystems,
- wiederholbare Extraktions- und Transformationslogik, beispielsweise als versionierte SQL-Abfragen,
- ein prüfbarer Export für den nächsten Testlauf sowie Kontrollwerte für Vollständigkeit und Zuordnung,
- sichtbare offene Fachentscheidungen, die der zuständige Fachbereich treffen und freigeben muss.
Damit bleibt die Aufgabenteilung sauber. Der Kunde autorisiert den Zugriff, entscheidet über den Migrationsumfang und verantwortet die fachliche Abnahme. Der neue ERP-Anbieter beschreibt Zielstruktur und Importbedingungen. Wir können dazwischen die Quellstruktur analysieren, Beziehungen rekonstruieren, Exporte und Transformationen technisch umsetzen und die Ergebnisse für Tests nachvollziehbar vorbereiten.
Die interne IT bleibt beteiligt, aber nicht allein
Ohne die interne IT funktioniert der unabhängige Weg selten. Sie kennt die Infrastruktur, kann Sicherungen und Zugänge einordnen und weiß, welche Teile des Altsystems noch produktiv benötigt werden. Auch langjährige Anwender bleiben wichtig, weil sie erklären können, wie Felder und Prozesse tatsächlich verwendet wurden.
Diese Mitwirkung unterscheidet sich jedoch von vollständiger operativer Verantwortung. Die internen Beteiligten sollten konkrete Zugänge, Bedeutungen und Fachentscheidungen liefern. Die zeitintensive technische Suche, Zusammenführung, Transformation und Wiederholung kann ein externer Datenmigrationsspezialist übernehmen. Genau diese Unterscheidung zwischen Orientierung und tatsächlicher Umsetzung erläutert der Beitrag Datenmigration: Beratung oder Umsetzung.
Für die Projektleitung entsteht damit eine realistische Alternative zum Stillstand. Sie muss nicht behaupten, dass der alte Anbieter sicher nicht mehr helfen wird. Sie kann parallel einen unabhängigen Weg vorbereiten und anhand eines ersten Zielobjekts prüfen, ob dieser Weg technisch und fachlich trägt.
Die nächste Entscheidung ist kleiner als die gesamte Migration
Wenn der alte ERP-Anbieter nicht reagiert, muss das Unternehmen nicht sofort jede Tabelle verstehen und die vollständige Migration neu planen. Zuerst reicht eine klarere Entscheidung: Können wir einen autorisierten Zugriff auf die Quelldaten herstellen und ein relevantes Zielobjekt damit vollständig bis zu einem prüfbaren Export führen?
Ist das möglich, kann die Datenmigration unabhängig weiterarbeiten und den Weg schrittweise auf weitere Objekte übertragen. Ist es nicht möglich, wird wenigstens der tatsächliche Engpass sichtbar: Dann fehlen nicht SQL-Kenntnisse oder eine weitere Exportvorlage, sondern zunächst Zugang, Sicherung oder eine vereinbarte technische Bereitstellung. Diese Klarheit verhindert, dass die interne IT wochenlang im Altsystem sucht, während das eigentliche Zugangsproblem ungelöst bleibt.